VPC in practice: building a real network from scratch

This lesson assumes the concepts from the Cloud Computing domain's networking basics lesson — VPCs, public vs private subnets, security groups, NAT gateways — and goes straight to actually building one. A real VPC for a typical web application needs, at minimum: the VPC itself, subnets spread across multiple AZs, an internet gateway, route tables, and a NAT gateway — six distinct resources wired together correctly, not just one.

map_public_ip_on_launch = true on the public subnet is what actually makes it "public" in practice — combined with the internet gateway and route table below, not a property of the subnet alone.

This is the part that's easy to get subtly wrong: creating an internet gateway and attaching it to the VPC does nothing by itself — a subnet is only "public" once its route table has an explicit route sending 0.0.0.0/0 traffic to that gateway, and that route table is associated with the subnet. All three pieces (gateway, route, association) have to be correct together; a subnet with map_public_ip_on_launch = true but no route to an internet gateway is a subnet whose resources have public IPs that still can't actually reach the internet — a genuinely common, confusing first mistake.

The NAT gateway itself lives in a public subnet (it needs its own route to the internet gateway), while the private subnet's route table points at the NAT gateway rather than the internet gateway directly — this asymmetry (private subnets route through NAT, which routes through the IGW) is exactly what gives private-subnet resources outbound-only internet access.

VPC peering connects two VPCs (in the same or different AWS accounts) so resources in each can communicate using private IP addresses, as if they were on the same network — commonly used to connect a shared-services VPC to multiple application VPCs, or to connect environments that need to talk to each other without routing through the public internet.

A peering connection alone doesn't route any traffic — like the internet gateway above, each VPC's route tables need explicit routes pointing traffic destined for the peer's CIDR range at the peering connection, on both sides, or traffic silently doesn't flow in one or both directions.

The fastest real check that a VPC is wired correctly: launch one EC2 instance in the public subnet (should get a public IP and reach the internet directly) and one in the private subnet (should have no public IP, but should still be able to reach the internet outbound via the NAT gateway — verifiable with curl to any external URL from inside the instance, and separately confirm it's genuinely unreachable from outside). A VPC that "looks right" in a diagram but hasn't been verified this way is exactly how the missing-route mistake above goes unnoticed until it matters.