AWS VPC networking basics: subnets, routes and the four ways out

A VPC is a private IP range you control inside an AWS region, carved into subnets that each live in one availability zone. That much is easy. The part that causes trouble is routing, because AWS does not have a checkbox marked public.

What actually makes a subnet public

A subnet is public if, and only if, its route table has a default route pointing at an internet gateway. That is the whole definition. A subnet named public-1a with no such route is private, and a subnet named db-private with that route is exposed.

So the first thing to check when an instance cannot reach the internet, or when something reachable should not be, is the route table associated with its subnet.

The four ways out

Internet gateway. A horizontally scaled, free component attached to the VPC. Instances in subnets routed through it need a public IPv4 address or an Elastic IP to be reachable, and AWS bills hourly for every public IPv4 address you hold.

NAT gateway. Lets instances in private subnets initiate outbound connections while remaining unreachable from outside. It is a managed service billed per hour and per gigabyte processed, and it is one of the most common unexpected line items on a first invoice. One per availability zone if you want zone resilience, which multiplies the cost.

Egress only internet gateway. The IPv6 equivalent of a NAT gateway, and free. If your workload can speak IPv6 to its dependencies, this removes the NAT bill entirely.

VPC endpoints. Private connections to AWS services. Gateway endpoints for S3 and DynamoDB are free and simply add routes. Interface endpoints, built on PrivateLink, cost per hour and per gigabyte but are typically cheaper than routing the same traffic through a NAT gateway, and they keep it off the public internet.

Subnet layout that ages well

A layout that works for most applications, in at least two availability zones:

• Public subnets. Load balancers, NAT gateways, bastion hosts if you still use them. Small ranges are fine.
• Private application subnets. Everything that serves traffic. No default route to an internet gateway.
• Private data subnets. Databases and caches, with security groups that only accept traffic from the application tier.

Size the CIDR generously. A /16 for the VPC and /20 per subnet leaves room to grow. Expanding a VPC later is possible but adding a secondary CIDR block is a change nobody enjoys making under pressure.

Security groups and network ACLs

Security groups attach to network interfaces. They are stateful, so a permitted outbound request gets its reply back automatically, and they only express allow rules. This is where almost all of your access control belongs.

Network ACLs attach to subnets, are stateless and evaluate numbered rules in order, so you must permit return traffic explicitly on ephemeral ports. They can deny, which makes them useful for blunt blocks, but they are easy to get subtly wrong. Most well run accounts leave them at the default and do the work in security groups.

A pattern worth adopting: reference security groups from other security groups rather than IP ranges. Allowing the database group to accept traffic from the application group survives every instance replacement without edits.

Connecting VPCs and networks

• VPC peering. One to one, non transitive, free within an availability zone and charged for cross zone traffic. Fine for two or three VPCs.
• Transit Gateway. A hub for many VPCs and on premises connections. Charged per attachment per hour plus data processed. Worth it once peering becomes a mesh.
• Site to site VPN and Direct Connect. For linking a physical network. VPN is quick and encrypted over the internet; Direct Connect is a dedicated circuit with predictable latency and a lead time measured in weeks.

Where the default limits bite

Several VPC objects have per region quotas that are low enough to hit during a build out: five VPCs, five Elastic IP addresses, and route table entry limits among them. All are adjustable, and all are easier to raise before you need them. The process is the same as for compute, described in AWS vCPU quotas explained.

If outbound mail is part of the plan, note that AWS throttles port 25 on EC2 by default and requires a request to lift it. That policy and its equivalents elsewhere are covered in outbound port 25 on cloud servers.