NAT: Gateways vs. Instances

The Problem with Private Subnets

You put your database servers in a Private Subnet so attackers on the internet cannot reach them directly. Good security practice.

But your application server in that private subnet needs to download a security patch from the internet, or call an external API. How can it reach out if it has no direct path to the internet?

The Solution: Network Address Translation (NAT)

NAT (Network Address Translation) solves this by acting as a proxy for outbound traffic. The private resource never gets a public IP — instead, a NAT device in a public subnet borrows its own public IP to make requests on the private resource's behalf.

Here's the flow, step by step:

1. Your private server (10.0.3.5) sends a request to 8.8.8.8 (Google DNS).
2. The request hits the private subnet's route table, which sends 0.0.0.0/0 traffic to the NAT device.
3. The NAT device replaces the source IP (10.0.3.5) with its own public IP and forwards the request.
4. Google DNS replies to the NAT device's public IP.
5. The NAT device translates the destination back to 10.0.3.5 and delivers the reply.

The internet never sees your private server's IP address. Inbound connections initiated from the internet cannot reach the private server through NAT — NAT only facilitates outbound-initiated connections.

NAT Gateway vs. NAT Instance

NAT Gateway (Managed Service):
The cloud provider runs and manages this for you. It scales automatically, is highly available within an Availability Zone, and requires zero maintenance. You pay an hourly fee plus a per-GB data processing charge. Use this for all production workloads.

One important nuance: a NAT Gateway is Availability Zone-specific. If you have private subnets in three AZs, best practice is to deploy one NAT Gateway per AZ and route each AZ's private subnets to their local NAT Gateway. This prevents a single AZ failure from cutting off internet access for all private subnets.

NAT Instance (DIY):
An older approach where you launch a standard Linux EC2 instance, enable IP forwarding, and configure it to act as a router. It's cheaper at very low traffic volumes, but it's a single point of failure, requires manual patching, and you must manage scaling yourself. Avoid this in production unless cost constraints are extreme and you fully understand the trade-offs.