Route tables, internet and NAT gateways

A subnet is "public" or "private" because of one thing: its routing. Route tables decide where traffic goes, and two special gateways — the internet gateway and the NAT gateway — decide who can reach the internet and who cannot. Understanding these makes the public/private distinction concrete, and the NAT gateway in particular is a common source of both connectivity bugs and surprise costs. This lesson is route tables, internet and NAT gateways.

Route tables: where traffic goes

A route table is a set of rules that decides, for each destination, where to send traffic. Every subnet is associated with a route table, and that is what makes a subnet public or private. A route table has entries mapping a destination CIDR to a target:

Destination        Target
10.0.0.0/16        local           # traffic within the VPC stays local
0.0.0.0/0          igw-xxxx        # everything else goes to the internet gateway  <- makes this subnet PUBLIC

• The local route (for the VPC's own CIDR) is always present — it lets everything in the VPC talk to everything else in the VPC.
• The default route 0.0.0.0/0 ("everywhere else") is the interesting one. Where it points decides internet access: point it at an internet gateway and the subnet is public; point it at a NAT gateway and the subnet is private-with-outbound; omit it and the subnet has no internet access at all.

So "public subnet" literally means "its route table sends 0.0.0.0/0 to an internet gateway." Routing is the mechanism behind the whole public/private design.

The internet gateway: two-way internet

An internet gateway (IGW) is what connects your VPC to the internet. It is attached to the VPC (one per VPC), and a subnet becomes public by routing 0.0.0.0/0 to it. Resources in a public subnet that also have a public IP can then be reached from the internet and reach out to it — two-way connectivity.

You put in public subnets only what must be internet-facing: the load balancer (which receives user traffic) and the NAT gateway (below). Your application servers do not go here — they sit in private subnets and are reached through the load balancer, never directly. The IGW is the front door; you keep it in front of as little as possible.

The NAT gateway: outbound-only for private subnets

Here is the piece that puzzles newcomers. Your application servers are in private subnets with no route to the internet gateway — so they cannot be reached from the internet (good, that is the point). But they still need to reach out: to download OS updates, call external APIs, pull container images. How does a server with no internet route reach the internet?

The NAT gateway (Network Address Translation). It lives in a public subnet, and private subnets route their 0.0.0.0/0 to it. When a private server sends traffic to the internet, it goes to the NAT gateway, which forwards it out through the internet gateway using its own public IP, and routes the response back. The result: private servers can initiate outbound connections, but nothing on the internet can initiate a connection to them. Outbound works; inbound is impossible. That asymmetry is exactly what you want for application servers — they can fetch what they need, but are unreachable from outside.

The routing picture:

Public subnet  route table:  0.0.0.0/0 -> internet gateway   (LB and NAT live here)
Private subnet route table:  0.0.0.0/0 -> NAT gateway         (apps live here; outbound only)

NAT gateways cost money — a real gotcha

The NAT gateway is a frequent source of surprise cost, and worth flagging as the cost-conscious course it is:

• It has an hourly charge and a per-GB data-processing charge. Every byte your private servers send to the internet through it costs money, on top of the hourly fee. High outbound traffic (large downloads, chatty external API calls) through NAT can run to real money.
• Per-AZ NAT gateways multiply the cost. For high availability you often run one NAT gateway per AZ (so an AZ failure does not cut off that AZ's private subnets) — but that is N NAT gateways, each with its hourly charge. There is a genuine trade-off between resilience (one per AZ) and cost (one shared).
• VPC endpoints avoid NAT for AWS services (the next lesson) — traffic to S3, ECR, etc. can bypass the NAT gateway entirely, which both improves security and removes that NAT data-processing cost. This is a common, worthwhile optimisation.

So while the NAT gateway is essential for private-subnet outbound access, it is also something to watch on the bill: right-size how many you run, and use VPC endpoints to keep AWS-service traffic off it. A cost-aware network design considers NAT data charges deliberately rather than discovering them on the invoice.

Check your work

Route tables decide where traffic goes; each subnet has one, and it is what makes a subnet public or private. Entries map a destination CIDR to a target: the local route (VPC CIDR) always exists; the default 0.0.0.0/0 decides internet access — to an IGW (public), to a NAT gateway (private-outbound), or absent (no internet).

Internet gateway (IGW): connects the VPC to the internet (one per VPC); a subnet is public by routing 0.0.0.0/0 to it, and public-IP resources there get two-way internet. Put only the load balancer and NAT here, not app servers.

NAT gateway: lives in a public subnet; private subnets route 0.0.0.0/0 to it so private servers get outbound-only internet (initiate connections out; nothing can initiate in) — for updates, APIs, image pulls. The asymmetry is exactly right for app servers.

NAT cost (gotcha): hourly charge plus per-GB data processing — high outbound traffic costs real money; one-per-AZ (resilient) multiplies it; VPC endpoints keep AWS-service traffic off NAT (security + cost win). Watch NAT on the bill; right-size and use endpoints.

Practice

1. Explain how a route table makes a subnet public or private, using the 0.0.0.0/0 entry.
2. Explain what an internet gateway does and what belongs in a public subnet.
3. Explain how a private server with no internet route still reaches out, via a NAT gateway, and why inbound is impossible.
4. Draw the route tables for a public and a private subnet and explain each entry.
5. Explain the two ways a NAT gateway costs money and the resilience-vs-cost trade-off of one-per-AZ.
6. Explain how VPC endpoints reduce both NAT cost and exposure for AWS-service traffic.

Official documentation

• AWS — Route tables — How routing decides subnet reachability.
• AWS — Internet gateways — Connecting a VPC to the internet.
• AWS — NAT gateways — Outbound internet for private subnets, and its pricing.

Next: security groups and NACLs.