NAT gateway

A NAT gateway lets instances in a private subnet reach the internet, or another network, while preventing anything outside from initiating a connection to them.

Nothing NAT-related exists in a new VPC. Creating a VPC gives you the VPC and its CIDR block, a main route table, a default network ACL and a default security group — no internet gateway and no NAT. Both are added deliberately, which is part of why a custom VPC is private until you decide otherwise.

Creating one

Create the NAT gateway in a public subnet — one whose route table has a route to an internet gateway.
Associate an Elastic IP address with it. A public NAT gateway requires one at creation; it is not assigned automatically. A private NAT gateway takes no Elastic IP.
Add a 0.0.0.0/0 route in each private subnet’s route table pointing at the NAT gateway.
Confirm the VPC has an internet gateway attached and that the public subnet routes to it.

Characteristics

A zonal NAT gateway is redundant within its Availability Zone but not across zones, so it is deployed one per zone. A regional NAT gateway spans zones on its own — see availability mode.
5 Gbps of bandwidth, scaling automatically to 100 Gbps.
One million packets per second, scaling to ten million. Beyond that it drops packets.
Nothing to patch or maintain.
No security group. Use security groups on the instances behind it and a network ACL on its subnet.
The Elastic IP chosen at creation cannot be changed afterwards.
Each IPv4 address supports up to 55,000 simultaneous connections to any one destination address, port and protocol. Associate secondary private addresses if a workload exceeds that against a single destination.
Uses ports 1024–65535, which a network ACL on the subnet must allow.
Traffic cannot be routed to a NAT gateway through a VPC peering connection, though traffic from one can traverse peering.

Connectivity types

Public. In a public subnet, with an Elastic IP. Private instances reach the internet through it; the internet cannot reach them.

Private. No Elastic IP and no internet path. Private instances reach other VPCs or an on-premises network through a transit gateway or virtual private gateway, presenting the NAT gateway’s private address as the source. Useful where an on-premises firewall expects one address, or where address ranges overlap.

Availability mode

A zonal NAT gateway lives in one public subnet in one Availability Zone and is redundant only within it, so you deploy one per zone and route each zone’s private subnets to their own gateway.

A regional NAT gateway (aws ec2 create-nat-gateway --vpc-id … --availability-mode regional) needs no public subnet and gets its own route table. It expands and contracts across Availability Zones as workloads appear there — one NAT gateway ID and one route entry serve the whole VPC — and supports up to 32 IP addresses per zone, against 8 for a zonal gateway. AWS recommends it for every case except private NAT, which it does not support, so overlapping-address and on-premises-source designs stay zonal. Expanding into a newly used zone can take up to 60 minutes, and until then that zone’s traffic is processed across zones.

Reducing the cost

A NAT gateway is charged per hour it exists and per gigabyte it processes. Both add up, and the data charge is frequently the larger.

1. Use VPC endpoints for AWS services. Traffic to Amazon S3 and DynamoDB through a gateway endpoint is free and does not touch the NAT gateway at all. Interface endpoints for other AWS services cost less per gigabyte than NAT processing for high-volume traffic. This is almost always the largest saving available, because a great deal of “internet” traffic from a private subnet is traffic to AWS.

2. Reduce cross-zone traffic. One NAT gateway serving three Availability Zones means two zones’ worth of traffic is charged as cross-zone transfer on top of the NAT processing charge. One zonal gateway per zone, with each zone routed to its own, removes that — as does a regional NAT gateway, which keeps zonal affinity automatically.

3. Question what is leaving. Package downloads, container image pulls and log shipping are frequently the bulk of it. A pull-through cache in Amazon ECR, an S3 gateway endpoint for artefacts, or an interface endpoint for CloudWatch Logs each remove a large slice.

4. Place workloads that must be public in public subnets. An instance that needs a public address anyway does not need a NAT gateway.

5. Schedule non-production gateways. A development environment that runs in office hours does not need a NAT gateway at 3 a.m. Deleting and recreating it around a schedule is straightforward, though it changes the Elastic IP unless you reassociate the same one.

6. Consider a NAT instance only with your eyes open. It is cheaper per hour at low volumes, but you patch it, you script the failover, and it is a single point of failure. The AWS-provided NAT AMI reached end of maintenance support on 31 December 2023 and receives no security updates, so this route means building and maintaining your own AMI. That is a real ongoing cost against a modest saving.