Internet Gateway and NAT Gateway

1Two Directions, Two Gateways

What makes a subnet "public" is only its route table having a route to an IGW (02-vpc_subnets_route_tables §3).

2The Standard Layout

VPC 10.0.0.0/16                                         IGW
┌───────────────────────── AZ a ─────────┐ ┌──────── AZ b ─────────┐ ▲
│ public 10.0.0.0/24   [ALB node] [NAT-a]│ │ public 10.0.1.0/24 [NAT-b]│ │  0.0.0.0/0 → igw
│ private 10.0.10.0/24 [app] [app]       │ │ private 10.0.11.0/24 [app]│   0.0.0.0/0 → nat-a (AZ a) / nat-b (AZ b)
│ data 10.0.20.0/24    [RDS primary]     │ │ data 10.0.21.0/24 [standby]│  no internet route at all
└────────────────────────────────────────┘ └──────────────────────────┘

• Public subnets: load balancers, NAT gateways (and almost nothing else).
• Private app subnets: route 0.0.0.0/0 to the NAT in the same AZ — if one AZ fails, the others keep outbound access, and you avoid cross-AZ data charges.
• Data subnets: no route to the internet at all.

3How NAT Works Here

An app instance 10.0.10.25 calls api.stripe.com:

10.0.10.25:51514 → (route 0.0.0.0/0 → nat-a) → NAT rewrites source to its Elastic IP 3.120.4.9:40123
→ IGW → internet → reply to 3.120.4.9:40123 → NAT looks up its translation table → 10.0.10.25:51514

The whole private fleet appears to the internet as the NAT's Elastic IP — useful for partner allow-lists ("allow our egress IP") — and nobody on the internet can initiate a connection to the private instances.

4Costs and Alternatives

NAT gateway data processing charges add up fast when private workloads pull lots of data from AWS services:

• Gateway VPC endpoints for S3 and DynamoDB are free and route that traffic privately — always add them.
• Interface VPC endpoints (PrivateLink) for ECR, CloudWatch Logs, SSM, Secrets Manager, STS, SQS… keep traffic off the NAT (hourly + per-GB, but often cheaper than NAT for heavy users, and no internet path at all).
• IPv6: public IPv6 addresses + an egress-only internet gateway give outbound-only behaviour without NAT.
• Dev/test: one NAT for all AZs (accepting the AZ dependency) to save cost.

5Elastic IPs and Public IPs

• Auto-assigned public IPv4 addresses change on stop/start; Elastic IPs are static and can be moved between resources. AWS charges for every public IPv4 address (in use or idle).
• Only resources that genuinely need to be reachable (load balancers, NAT gateways) should have public IPs.

Under the HoodWhy an IGW Isn't a Box▾

An internet gateway isn't a device sitting in your VPC that traffic queues through — it's a logical attachment to AWS's horizontally scaled edge, so it has no bandwidth limit and no availability-zone failure mode. It performs 1:1 NAT between an instance's private IP and its public IPv4 address: instances never see their public IP on their own interface (ip addr shows only 10.0.x.x); the mapping is applied by the VPC's virtual routing at the edge. A NAT gateway, by contrast, is a managed many-to-one (port address translation) service deployed into one subnet: each gateway supports up to ~55,000 simultaneous connections per destination (IP, port, protocol) per assigned IP — exceeded when thousands of workers hammer the same API endpoint, surfacing as ErrorPortAllocation; adding secondary IPs to the NAT or spreading destinations fixes it.

⚠️ Common Pitfalls

1. One NAT for all AZs in production — an AZ outage cuts outbound access everywhere, plus cross-AZ charges.
2. Putting app servers in public subnets "to reach the internet".
3. No S3/DynamoDB gateway endpoints — paying NAT processing for internal AWS traffic.
4. Expecting inbound connections through a NAT — impossible by design.
5. Data tier with a route to the internet.
6. NAT port exhaustion for high-concurrency calls to one destination.

📋 Quick Reference

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: aws_internet_gateway_and_nat_gateway_theory.md · generated by tools/build_lessons.py