AWS NAT Gateway Explained: Private Subnets, Cost & Setup

Simple explanation

Think of a NAT Gateway like a shared office reception desk. Everyone in the building (your private EC2 instances) can make outbound calls through the desk, but the outside world only ever sees the desk’s number. Calls come back to the desk, which knows who made each call and transfers the response to the right person. Your individual employees are never listed in the public directory.

The critical point: your EC2 instance does not get a public IP address. The NAT Gateway holds the Elastic IP. The internet sees the NAT Gateway’s address for every outbound connection from your private subnet. Your instance remains unreachable from the internet. It can only initiate connections outward, not receive them.

This is different from an instance in a public subnet, which has its own Elastic IP and can be reached directly. Private subnet instances trade direct internet reachability for a smaller attack surface, and use the NAT Gateway as their outbound proxy. See Default vs Custom VPCs for how VPC design decisions flow into subnet choices.

How it works: traffic flow

When an EC2 instance in a private subnet makes an outbound request, here is the exact path the traffic takes:

1. The EC2 instance sends a packet to an external IP (for example, a package repository or third-party API).
2. The private subnet’s route table has a 0.0.0.0/0 route pointing to the NAT Gateway.
3. The NAT Gateway receives the packet, replaces the source IP (the EC2 private IP) with its own Elastic IP, logs the connection mapping, and forwards the packet toward the Internet Gateway.
4. The Internet Gateway routes the packet to the internet.
5. The response returns to the Internet Gateway, is delivered to the NAT Gateway, which translates the destination back to the originating EC2 instance’s private IP and forwards it into the VPC.

Private EC2 (10.0.2.5)
     |
     | route: 0.0.0.0/0 -> nat-xxxxxxxx
     v
NAT Gateway  (public subnet, Elastic IP: 54.x.x.x)
     |
     | route: 0.0.0.0/0 -> igw-xxxxxxxx
     v
Internet Gateway
     |
     v
Internet

The public subnet’s route table points 0.0.0.0/0 at the Internet Gateway. That is what makes a subnet “public.” The NAT Gateway sits inside that public subnet and uses that route to reach the internet on behalf of private instances.

Inbound connections initiated from the internet never reach the private instance. The NAT Gateway only maintains connection state for outbound-initiated sessions. This is the core security property that makes the private subnet pattern useful.

When to use a NAT Gateway

NAT Gateway is the right choice when private subnet workloads genuinely need outbound internet access:

• EC2 instances downloading OS packages or updates. apt, yum, or dnf updates from public repositories all require outbound internet access.
• Application servers calling external APIs. Payment gateways, SaaS webhooks, and third-party data providers all require your server to initiate outbound connections.
• VPC-attached Lambda functions. Lambda loses default internet access when placed inside a VPC. A NAT Gateway restores it. See Serverless VPC Access for the full picture.
• ECS tasks and Kubernetes pods in private subnets. Containerized workloads that need to pull images from public registries or make outbound API calls follow the same routing pattern as EC2.
• Allowing a single predictable egress IP. The NAT Gateway’s Elastic IP is fixed, so external services can add it to their IP allowlists for your traffic.

When not to use a NAT Gateway

NAT Gateway is often the default answer to “how does my private subnet reach anything?”, but it is not always the right one:

• S3 and DynamoDB traffic. AWS offers free VPC Gateway Endpoints for both services. Traffic stays on the AWS network, avoids NAT processing charges, and is often lower latency. If your workload primarily reads and writes S3 or DynamoDB, setting up an endpoint is a quick win.
• Other AWS service traffic. Many AWS services support PrivateLink interface endpoints for private access without going through NAT or the internet. Services like SQS, SNS, Secrets Manager, and ECR all support this pattern.
• IPv6 outbound traffic. For instances with IPv6 addresses that need internet egress but not inbound, use an Egress-only Internet Gateway instead. NAT Gateway does not natively handle IPv6 egress (though NAT64/DNS64 exists for translating to IPv4 destinations).
• No internet access needed at all. If your workload only communicates with other AWS services via endpoints, other VPCs via peering, or on-premises via Direct Connect, you may not need a NAT Gateway. Skipping it eliminates both cost and an unnecessary egress path.
• Cross-VPC connectivity. NAT Gateway is not a tool for connecting VPCs together. Use VPC Peering or Transit Gateway for that use case.

NAT Gateway vs alternatives

Several AWS constructs handle related but distinct problems. Understanding which one fits your use case avoids misrouting traffic or paying for unnecessary NAT processing.

Public vs private NAT Gateway

AWS offers two connectivity modes for NAT Gateway, and they solve different problems:

Public NAT Gateway is what most teams use. It has an Elastic IP, sits in a public subnet, and provides outbound internet access for private subnet workloads. This is the standard pattern for giving private EC2 instances or Lambda functions access to the internet.

Private NAT Gateway has no Elastic IP and no internet access. It is used for private connectivity scenarios, specifically for routing traffic between VPCs or between a VPC and on-premises networks where IP address ranges overlap. If you have two VPCs that both use 10.0.0.0/16 and need to communicate, a private NAT Gateway can translate addresses to resolve the conflict.

Zonal NAT Gateway vs Regional NAT Gateway

Traditionally, a NAT Gateway is an AZ-scoped resource. You create it in a specific AZ’s public subnet, and it serves traffic from private subnets in that same AZ. This is why the classic high-availability design requires one NAT Gateway per AZ. There is no automatic failover across AZs for the zonal pattern.

AWS has introduced a Regional NAT Gateway that changes this model. A Regional NAT Gateway can serve traffic from private subnets across multiple AZs within a region without requiring you to provision one gateway per AZ. AWS manages the redundancy and cross-AZ routing automatically.

The practical implication: Regional NAT Gateway simplifies the operational model (one gateway instead of three) and can reduce management overhead for architectures that do not need strict AZ-level control over their egress path. For workloads that already have multi-AZ redundancy at the application layer, Regional NAT Gateway is worth evaluating.

Route table setup

Creating a NAT Gateway is only half the work. Without the correct route table entries, traffic from your private subnet has no path to reach it. Two route tables must be correct for end-to-end connectivity.

The public subnet where the NAT Gateway lives needs a 0.0.0.0/0 route pointing at the Internet Gateway. Without this, the NAT Gateway cannot forward traffic to the internet. The public subnet would not actually be public.

Each private subnet needs a 0.0.0.0/0 route pointing at the NAT Gateway, not the Internet Gateway. Pointing it directly at the Internet Gateway would attempt internet routing for a private instance that has no public IP, which fails silently. See Route Tables in AWS for the full explanation of how routes are evaluated.

High availability and multi-AZ design

A zonal NAT Gateway is tied to a single AZ. AWS manages internal redundancy within that AZ, but if the AZ itself has a disruption, the NAT Gateway in that AZ becomes unavailable.

The failure mode to understand: if private subnets in AZ-A, AZ-B, and AZ-C all route through a single NAT Gateway in AZ-A, and AZ-A goes down, then instances in AZ-B and AZ-C lose internet access even though their own AZ is healthy. The shared NAT Gateway is a hidden availability dependency that does not show up in your EC2 or ECS health dashboards.

The correct production pattern is one NAT Gateway per AZ. Each AZ’s private route table points to the NAT Gateway in that same AZ. An AZ failure then isolates the impact. Only instances in the affected AZ lose internet access, while the other AZs continue normally.

Same-AZ NAT routing is a standard item on a well-architected networking checklist. If you are building toward highly available systems, treat it as a baseline requirement alongside multi-AZ subnets and health checks.

Cost and how to reduce it

NAT Gateway billing has two dimensions:

• Hourly charge: a fixed fee for every hour the NAT Gateway exists, whether or not traffic passes through it. In us-east-1, this is approximately $0.045/hour (around $33/month per gateway). A three-AZ production setup costs roughly $99/month in hourly charges before any data processing.
• Data processing charge: a per-GB fee for every gigabyte the gateway processes in either direction. In us-east-1, this is approximately $0.045/GB. For workloads with high throughput (frequent container image pulls, large file downloads, streaming data), this becomes the dominant line item.

Cost-reduction strategies:

• VPC Gateway Endpoints for S3 and DynamoDB. Free to create. Traffic to these services no longer passes through the NAT Gateway, eliminating all processing charges for that traffic. For workloads that read and write S3 heavily, this is typically the highest-leverage change.
• PrivateLink interface endpoints for other AWS services. ECR, SQS, SNS, Secrets Manager, and many others support private endpoints. Each has its own hourly cost, so evaluate whether the traffic volume makes the trade worthwhile.
• Cache dependencies locally. Pulling the same container image or package multiple times through NAT multiplies the data processing charge. Push images to ECR and use package mirrors or caching proxies inside the VPC.
• Same-AZ routing. Eliminating cross-AZ NAT traffic removes both the cross-AZ transfer charge and reduces unnecessary NAT processing volume.
• Delete unused gateways. NAT Gateways in dev and test environments charge hourly with zero traffic. Delete them when not needed, or automate shutdown outside business hours.

NAT Gateway vs NAT instance

Before NAT Gateway existed, the only option was running an EC2 instance configured to perform NAT. NAT Gateway replaced this pattern for most teams because it is managed, scales automatically, and requires no OS maintenance.

The only scenario where a NAT instance makes practical sense today is when you need custom iptables rules at the NAT layer, for example an allowlist of permitted external destinations for compliance reasons. Even then, AWS Network Firewall is usually a cleaner and more maintainable solution. For new architectures, NAT Gateway is the default.

How to create a NAT Gateway

These steps assume you have a VPC with at least one public subnet and an Internet Gateway already attached. You will need the subnet ID of your public subnet and the route table ID of your private subnet.

# 1. Allocate an Elastic IP for the NAT Gateway
aws ec2 allocate-address --domain vpc
# Note the AllocationId from the output (eipalloc-...)

# 2. Create the NAT Gateway in your public subnet
aws ec2 create-nat-gateway \
  --subnet-id subnet-YOUR_PUBLIC_SUBNET \
  --allocation-id eipalloc-YOUR_ALLOC_ID
# Note the NatGatewayId from the output (nat-...)

# 3. Wait until the gateway is available (~1 minute)
aws ec2 wait nat-gateway-available \
  --nat-gateway-ids nat-YOUR_NAT_ID

# 4. Add the default route to your private subnet's route table
aws ec2 create-route \
  --route-table-id rtb-YOUR_PRIVATE_ROUTE_TABLE \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-YOUR_NAT_ID

For a multi-AZ setup, repeat all four steps for each AZ: a separate Elastic IP, a separate NAT Gateway in that AZ’s public subnet, and a separate route table update for that AZ’s private subnet.