The VPC Context: Public vs Private Subnets

A subnet's 'public' or 'private' designation isn't a special AWS setting — it's purely determined by its route table. A subnet is public if its route table has a route sending 0.0.0.0/0 (all internet-bound traffic) to an Internet Gateway (a VPC component providing direct two-way internet connectivity). A subnet is private if it has no such route — instances there simply cannot reach the internet directly, and the internet cannot reach them directly, regardless of what Security Group rules say, because the traffic has no path to travel at the network layer at all.

Instances in a private subnet that still need outbound internet access (e.g. to download OS updates or call an external API) route through a NAT Gateway, which lives in a public subnet, has its own Elastic IP, and allows outbound-initiated traffic from the private subnet while still blocking any inbound-initiated connection from the internet — the private instance can call out, but nothing outside can call in.

This is why the standard production pattern places load balancers and NAT Gateways in public subnets, and application servers plus databases in private subnets: even a completely permissive Security Group on a private-subnet instance still can't be reached directly from the internet, because there's no route for that traffic to arrive by. Defense in depth means a mistake at one layer (an overly broad Security Group rule) doesn't automatically become an exposure, because the routing layer independently blocks it too.