AWS VPC NAT Gateway
Use a NAT Gateway to let private subnets reach the internet for updates and APIs while keeping them unreachable from inbound internet traffic.
A NAT Gateway solves a common networking need: private instances must download packages, reach external APIs, or contact AWS public endpoints, but they should not accept inbound internet traffic. By placing a NAT Gateway in a public subnet and routing private subnet default traffic through it, AWS lets those private workloads initiate outbound connections while remaining non-addressable from the internet.
Placement matters. The NAT Gateway itself belongs in a public subnet with an Elastic IP and a route to an Internet Gateway. Private subnets then use route tables that send 0.0.0.0/0 to the NAT Gateway. If you place the NAT Gateway in a private subnet, it cannot do its job because it lacks a usable public path.
| Option | Trade-off |
|---|---|
| NAT Gateway | Managed, highly available within an AZ, but costs more |
| NAT Instance | More control and sometimes cheaper, but you manage it |
Cost is the main reason teams hesitate. NAT Gateways charge hourly plus data processing fees, and those costs can add up in multi-AZ environments or chatty systems. If most traffic is going to AWS services such as S3 or DynamoDB, VPC endpoints may reduce both cost and exposure by keeping traffic inside AWS rather than pushing it through NAT.
NAT Instance is the older self-managed alternative. It can be cheaper in low-volume labs, but you must patch, scale, and harden it yourself. For production, the managed NAT Gateway is usually worth the simplicity unless cost analysis clearly says otherwise.
Pair this lesson with AWS VPC so the gateway fits into the larger subnet and routing design.
aws ec2 create-nat-gateway --subnet-id subnet-public123 --allocation-id eipalloc-1234567890abcdef0
aws ec2 create-route --route-table-id rtb-private123 --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-1234567890abcdef0
Operational note
When network troubleshooting gets confusing, reduce the problem to layers: subnet placement, route table association, security group rules, and the presence of the correct gateway or endpoint. AWS networking becomes much easier to reason about when you verify those four items in order instead of changing everything at once. Shared standards like this make future environments easier to launch, review, and support.
Purpose of NAT
Why do private subnets commonly use a NAT Gateway?
Placement
Where is a NAT Gateway normally deployed?