NAT Gateway: Your VPC's Outbound-Only Internet Door
A NAT Gateway is a one-way door for your private cloud resources. It lets instances in private subnets initiate outbound traffic to the internet—like for updates or API calls—but blocks unsolicited inbound connections.
WHY IT EXISTS: In a secure cloud architecture, you keep sensitive resources like databases in private subnets, inaccessible from the internet. But these resources often need to download patches or connect to third-party APIs. A NAT Gateway solves this by providing outbound internet access without compromising their private, secure status.
THE MENTAL MODEL: Think of a NAT Gateway as the security-conscious receptionist for an office building with no public access. Employees (private instances) can go out through the front door to run errands (fetch updates from the internet). When they return, the receptionist knows they were expected. However, a stranger (unsolicited inbound traffic) walking up to the door will be turned away because they don't have an appointment (an established connection).
HOW IT WORKS: A NAT (Network Address Translation) Gateway is a managed service you place in a public subnet. You then configure the route table for your private subnets to direct all internet-bound traffic (destination 0.0.0.0/0) to the NAT Gateway. When a private instance sends a request, the gateway replaces the instance's private source IP with its own public IP and forwards it. When the response returns, the gateway translates the address back and sends it to the private instance. This process is stateful; it only allows responses to connections it initiated.
WHEN TO USE IT: Use a NAT Gateway whenever resources in a private subnet need to initiate connections to the internet. This is essential for backend servers fetching data from external APIs, worker nodes downloading tasks, or any instance needing to access OS update repositories or public container registries. It is a core component for building secure, multi-tiered applications.
WHEN NOT TO USE IT: Do not use a NAT Gateway if you need to accept inbound traffic from the internet. For that, you need a resource in a public subnet with a public IP, typically behind an Internet Gateway. Also, if a resource has no need to access the internet at all, you don't need a NAT Gateway; for maximum security, use VPC Endpoints for access to AWS services instead.
ONE CANONICAL EXAMPLE: A web application has its application servers and database in private subnets for security. The application servers need to call a third-party payment API. To enable this, you place a NAT Gateway in a public subnet and update the private subnet's route table to send internet-bound traffic to the NAT Gateway. The app server can now securely call the payment API without being exposed to the internet.
Read the original → docs.aws.amazon.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.