A NAT gateway is one of the smallest pieces of an AWS network and one of the most surprising lines on the bill. It is charged per hour for every gateway in every availability zone, plus a rate for every gigabyte that passes through it. A three-zone setup therefore pays three hourly charges before a single request is served, and then pays again for the traffic.
That structure is not a pricing trick. It reflects what the service does: managed outbound internet access for private subnets, with no instance to patch. The surprise comes from how much traffic quietly routes through it.
What actually travels through your NAT gateway
Anything in a private subnet that needs the internet without a public address. That includes:
- Package installs and container image pulls during deploys
- Calls to third-party APIs from application servers
- Log shipping agents sending to an external collector
- Backups uploading to storage outside the VPC
- Health checks and monitoring agents
On a small application, image pulls and log shipping often dominate. A CI pipeline that rebuilds every push can pull hundreds of megabytes a day, and a verbose log agent can match it.
The charge that catches people: cross-zone traffic
A NAT gateway lives in one availability zone. If a subnet in zone A routes through a gateway in zone B, the traffic crosses zones and is billed as data transfer on top of the processing charge. Multi-zone architectures that share a single gateway create exactly that pattern.
The usual reason a single gateway is used is cost. The usual result is that the saving is smaller than the cross-zone charge it creates, and the architecture loses availability at the same time.
The fix that costs nothing: gateway endpoints
Traffic to S3 and DynamoDB does not need a NAT gateway at all. A gateway endpoint keeps that traffic on the AWS network and is not charged by the hour or by the gigabyte. For a workload that reads assets, writes uploads or stores backups in S3, this single change removes a large share of NAT processing.
For most teams this is the first thing to check. It is also the change least likely to break anything, because it only alters the route for those two services.
Interface endpoints: useful, but not free
Other AWS services are reached through interface endpoints, which are billed hourly per endpoint per zone plus a processing rate. They still beat a NAT gateway when the traffic is heavy and stays inside AWS, but they are not a blanket replacement.
The decision is per service: how much traffic, how many zones, and whether the endpoint replaces NAT traffic or adds a parallel path. Adding endpoints for services nobody calls just moves the cost.
Where the traffic should not exist at all
Some of the busiest NAT flows are unnecessary:
- Log shipping to an external vendor when the platform’s own logging would do, with retention set deliberately.
- Container image pulls from the public internet on every node, every deploy, instead of a registry closer to the cluster with cached layers.
- Backups to a third-party bucket when storage in the same account would be cheaper and faster.
- Chatty health checks from an external monitor when a regional check would suffice.
Each is an architecture decision that shows up as a network line item.
Reading the bill properly
The cost explorer will show NAT gateway charges as a single line unless you split by usage type. Look for the hourly component separately from the processed-bytes component: they tell different stories. Hourly charges that dominate mean too many gateways. Processing charges that dominate mean too much traffic, and traffic has a source.
Tag the subnets and the workloads behind them before you start, or the investigation turns into guesswork about which team owns the flow.
What we check in a cost review
Start with the number of gateways per VPC and whether each zone needs one. Then map S3 and DynamoDB traffic to gateway endpoints. Then look at what remains: image pulls, log shipping, third-party APIs and backups, in that order, because that is usually the order of volume.
Only after that does it make sense to talk about commitments or instance sizes. Buying a savings plan while a NAT gateway processes avoidable traffic is paying upfront for a problem you have not fixed.
When a NAT instance is the right answer
A NAT instance — a small EC2 machine doing the same job — is cheaper at low, steady traffic and more work to operate: patching, failover, and bandwidth limits are yours. It suits a lab or a very small environment where the traffic is predictable and someone owns the machine.
For anything with production expectations, the managed gateway is usually the correct trade. The point is to stop paying for traffic that should never have crossed it.
If the bill is the reason you are reading this, a fixed-scope cloud cost review starts with the network layer, and the wider cloud services picture explains how the account, network and identity fit together. For the AWS-specific configuration, including S3 and CloudFront, see AWS cloud services.
