Skip to main content
A NAT gateway lets resources with private IPv4 addresses start connections to destinations outside their subnet without accepting unsolicited inbound internet connections. Updated October 9, 2026. The common example is an ECS task in a private subnet that needs to download a package, call a public API, or pull an image. The task has no public IPv4 address. Its route table sends internet-bound traffic to a NAT gateway, which presents a public source address to the destination.

​
The packet path

A typical public NAT gateway setup contains four pieces:
  1. A workload runs in a private subnet.
  2. The private subnet route table sends 0.0.0.0/0 to a NAT gateway.
  3. The NAT gateway sits in a public subnet and has an Elastic IP address.
  4. The public subnet sends internet traffic to an internet gateway attached to the VPC.
The NAT gateway replaces the task’s private source address with its Elastic IP and tracks the connection. Return traffic reaches the Elastic IP, passes through the NAT gateway, and is translated back to the task’s private address. This is source network address translation. The workload starts the flow. A host on the internet cannot use the NAT gateway to open a new connection to that private task.
A NAT gateway does not replace security groups. Security groups still decide which outbound and return traffic a resource can use.

​
Availability Zone design

A NAT gateway is created in one subnet and therefore in one Availability Zone. AWS manages its capacity and resilience within that zone, but your route design still matters. A common highly available design creates one NAT gateway per Availability Zone and routes each private subnet to the gateway in the same zone. This avoids making workloads in one zone depend on a gateway in another zone. A cheaper design may share one NAT gateway across zones. That reduces hourly gateway charges, but it creates a cross-zone dependency and can add regional data-transfer charges. If the gateway’s Availability Zone has a problem, private workloads in other zones may also lose that egress path.

​
Why NAT gateways become expensive

A NAT gateway has an hourly charge and a per-gigabyte data-processing charge. The surrounding path can add more charges, including cross-Availability Zone transfer and internet data transfer. Traffic volume often matters more than the number of workloads. Container image pulls, operating-system updates, large third-party API responses, and repeated artifact downloads can all pass through the gateway.
Do not look only at the NAT gateway line item. Cross-zone transfer and the service receiving the traffic may create separate charges.

​
Reduce unnecessary NAT traffic

You do not need to send every AWS service call through a NAT gateway.
  • Use gateway VPC endpoints for S3 and DynamoDB when appropriate.
  • Use interface VPC endpoints for supported AWS services when their fixed hourly and data costs beat the NAT path.
  • Keep large artifacts in the same region where possible.
  • Cache package and image downloads when the operational complexity is justified.
  • Check whether a workload actually needs a private subnet. A public IP with strict security groups can be a valid design for some stateless services.
VPC endpoints are not automatically cheaper. Interface endpoints have hourly charges per Availability Zone. Compare the complete traffic pattern before adding many endpoints.

​
NAT gateway, NAT instance, or no NAT

A NAT instance gives you more control and may cost less at small scale, but you own patching, scaling, failover, and throughput. A managed NAT gateway removes most of that operational work. Some architectures need no general internet egress. Workloads can use VPC endpoints, private APIs, and controlled proxies instead. This can improve security, but it also increases the number of dependencies you must configure. The right choice follows the workload:
  • Prefer a NAT gateway when reliable managed egress is worth the price.
  • Consider a NAT instance when traffic is small and you can operate it safely.
  • Prefer endpoints when traffic stays on supported AWS services and the cost model fits.
  • Remove general egress when the workload does not need it.
A NAT gateway is simple at the packet level. Most design mistakes come from route placement, cross-zone dependencies, and unmeasured data volume rather than from the translation itself.

​
Frequently asked questions

A public NAT gateway allows private resources to start outbound IPv4 connections and receive return traffic for those flows. It does not let an internet host initiate a new connection to a private workload. Use a load balancer or another explicit ingress path for inbound traffic.
One NAT gateway per Availability Zone avoids cross-zone dependency and keeps each private subnet’s egress local to its zone. A shared gateway costs less at low traffic but can add cross-zone charges and expands the impact of a zonal failure.
Reduce NAT gateway cost by keeping traffic in-zone, using appropriate S3 or DynamoDB gateway endpoints, evaluating interface endpoints for high-volume AWS API traffic, removing unnecessary downloads, and measuring processed bytes. Compare endpoint hourly charges with the complete NAT path before changing architecture.

​
Sources and further reading

Last modified on October 8, 2026