Tech Matchups: Public vs Private Subnets

Overview

Public Subnets have direct internet access via an Internet Gateway, hosting resources like web servers that serve external traffic.

Private Subnets lack direct internet access, using a NAT Gateway for outbound traffic, ideal for secure resources like databases.

Both structure VPCs: Public for external access, Private for internal security.

Section 1 - Connectivity and Access

Public Subnets route to an Internet Gateway—e.g., an EC2 instance (10.0.0.10) with a public IP serves HTTP traffic. Requires route table entry:

Private Subnets route to a NAT Gateway in a public subnet—e.g., a DB instance (10.0.1.10) fetches updates but blocks inbound traffic. Route table entry:

Scenario: Public Subnet hosts a web server; Private Subnet hosts a backend API.

Section 2 - Security and Best Practices

Public Subnets require tight Security Groups and NACLs—e.g., allow TCP 80/443 only. Use Elastic IPs for consistent addressing.

Private Subnets are inherently secure, blocking inbound traffic. Use Security Groups for outbound control—e.g., allow TCP 443 to 0.0.0.0/0 for updates.

Best practices: Public Subnets for load balancers or bastion hosts; Private Subnets for databases or app servers. Use multi-AZ for resilience.

Scenario: Public Subnet uses ALB with WAF; Private Subnet restricts DB access to app servers.

Section 3 - Cost and Resource Placement

Public Subnets incur data transfer costs via Internet Gateway—e.g., $0.09/GB outbound in us-east-1. Elastic IPs cost $0.005/hour if unattached.

Private Subnets add NAT Gateway costs—e.g., $0.045/hour + $0.045/GB. Example: 1TB/month costs ~$136.80.

Place public-facing resources (ALB, web servers) in Public Subnets; place sensitive resources (RDS, Lambda) in Private Subnets.

Scenario: Public Subnet for cost-free IGW traffic; Private Subnet for secure but costlier NAT traffic.

Section 4 - Use Case Scenarios

Public Subnets suit customer-facing apps—e.g., an e-commerce site’s ALB and web servers handling global traffic.

Private Subnets fit internal or sensitive apps—e.g., a payment processor or employee portal with no public access.

Scenario: Public Subnet for a blog’s frontend; Private Subnet for its CMS database.

Section 5 - Comparison Table

Public Subnets for external access, Private Subnets for security. Use both for balanced VPCs.

Conclusion

Public and Private Subnets structure VPCs for accessibility and security. Public Subnets enable direct internet access for customer-facing resources, ideal for web servers or load balancers. Private Subnets protect sensitive resources with outbound-only access, perfect for databases or internal apps.

Weigh access (direct vs. outbound), security (open vs. blocked), and cost (data vs. NAT). Use Public Subnets for public apps, Private Subnets for secure workloads—or combine: Public for frontends, Private for backends.