The NAT gateway is one of the most expensive small things in AWS. It looks like plumbing, it appears on the bill under data transfer and VPC charges where nobody is looking, and on a busy environment it quietly runs into five or six figures a year. Learning how to reduce NAT gateway costs on AWS is one of the highest-return network optimizations available, because the savings are real, recurring, and usually carry no performance risk.
This guide explains exactly how NAT gateway pricing works, where the charges come from, and the specific moves that cut them: VPC endpoints, consolidation, and architecture changes that keep traffic off the gateway entirely. It is part of our complete guide to AWS cost optimization, and pairs closely with our breakdown of AWS data transfer and egress charges.
How NAT gateway pricing works
A NAT gateway has two charges that both matter. The first is an hourly charge for the gateway existing, which in us-east-1 is 0.045 dollars per hour, or roughly 32 to 33 dollars per gateway per month. The second, and usually the larger one, is a data processing charge of 0.045 dollars per gigabyte for every gigabyte that flows through the gateway. On top of both, standard data transfer out charges still apply when that traffic leaves AWS. Pricing is per Availability Zone, so a highly available setup with a gateway in each of three AZs triples the hourly base before a single byte moves. Always confirm the current rate for your region on the AWS VPC pricing page, since prices vary by region and change over time.
| Charge | Rate (us-east-1) | Notes |
|---|---|---|
| Gateway hourly | ~$0.045 / hour | ~$32 to $33 per gateway per month, per AZ |
| Data processing | ~$0.045 / GB | Charged on every GB through the gateway |
| Data transfer out | Standard egress rates | Applies on top when traffic leaves AWS |
The important insight is that the processing charge applies regardless of where the traffic goes, including to other AWS services in the same region. A private subnet pulling objects from S3 through a NAT gateway pays 0.045 dollars per gigabyte for the privilege, even though that traffic never leaves AWS. That single fact is the source of most surprise NAT bills, and it is also the source of the biggest savings.
How to find what is driving the cost
Before you change anything, find out which gateways are expensive and what is flowing through them. In Cost Explorer, filter by the usage types NatGateway-Hours and NatGateway-Bytes and group by Availability Zone or resource to see where the spend concentrates. Then enable VPC Flow Logs on the relevant subnets to see what the high-volume traffic actually is. In almost every audit we run, a large share turns out to be traffic to S3, DynamoDB, ECR, or other AWS services that should never have touched a NAT gateway at all.
Most of the processing charge is usually traffic to AWS services in the same region, not genuine internet egress. That portion can be moved to VPC endpoints and removed from the NAT bill entirely.
Lever 1: VPC endpoints for AWS services
The single most effective move is to route traffic to AWS services through VPC endpoints instead of the NAT gateway. There are two kinds. Gateway endpoints, available for Amazon S3 and DynamoDB, are free: no hourly charge and no per-gigabyte processing. If your private subnets pull significant data from S3 or DynamoDB through a NAT gateway, adding a gateway endpoint removes that traffic from the processing charge at zero cost. This is the highest-return change in the whole exercise.
Interface endpoints, powered by PrivateLink, cover most other AWS services such as ECR, CloudWatch, SSM, and Secrets Manager. They carry their own small hourly charge per endpoint per AZ plus a per-gigabyte data processing charge, both lower than letting the same traffic run through NAT, but not free. So the rule is simple: always add the free gateway endpoints for S3 and DynamoDB, and add interface endpoints where the NAT processing charge they remove exceeds the endpoint cost they add. For low-volume services the math sometimes favors leaving traffic on NAT, so check the volumes first.
Lever 2: consolidate gateways
High availability is the usual justification for one NAT gateway per Availability Zone, and for production traffic that is the correct design, because a gateway lives in a single AZ and you do not want a zone failure to cut internet access for the others. But not every environment needs that. Development, test, and staging VPCs frequently run a NAT gateway in every AZ out of habit, tripling the hourly base for traffic that could tolerate a brief outage. Consolidating non-production environments to a single NAT gateway, or sharing a centralized egress VPC across accounts through Transit Gateway, removes the duplicate hourly charges.
Be deliberate about the trade-off. Consolidating to one gateway saves the hourly cost but introduces cross-AZ data transfer charges when instances in other zones route to it, and a single point of failure. For non-production that trade is usually worth it; for production it usually is not. The companion piece on AWS data transfer and egress charges covers the cross-AZ math in detail.
Add the free S3 and DynamoDB gateway endpoints first, then consolidate NAT gateways in non-production. Those two moves alone typically remove the majority of an inflated NAT bill with no production risk.
Lever 3: keep traffic off the gateway
The cheapest gateway is the one nothing flows through. Beyond endpoints, several architecture choices reduce NAT volume. Pull container images from a regional ECR through an interface endpoint rather than over the internet. Cache package and dependency downloads so build fleets are not repeatedly pulling the same artifacts through NAT. Keep chatty service-to-service traffic within the VPC rather than hairpinning out and back. And review whether resources sitting in private subnets genuinely need outbound internet at all; some can move to a fully private design with no NAT path.
For workloads that only need outbound IPv6, an egress-only internet gateway provides outbound access with no NAT processing charge, which can replace NAT for IPv6 traffic entirely. As with every change here, validate connectivity in a non-production environment first, because network changes carry operational risk even when they carry no performance penalty.
The NAT gateway cost checklist
- Identify expensive gateways in Cost Explorer using
NatGateway-HoursandNatGateway-Bytes. - Use VPC Flow Logs to see what traffic is flowing through each one.
- Add free gateway endpoints for S3 and DynamoDB in every VPC that uses them.
- Add interface endpoints for high-volume services where the saving beats the endpoint cost.
- Consolidate NAT gateways in non-production environments.
- Move outbound-only IPv6 traffic to an egress-only internet gateway.
- Remove unnecessary outbound internet paths from private subnets.
- Re-check the bill the following month and confirm the processing charge dropped.
Find the network spend hiding in your AWS bill
Our AWS cost audit maps every NAT gateway, endpoint, and data transfer dollar, then shows exactly which moves pay back fastest. No savings, no fee on the performance model.
Book an AWS cost audit →NAT gateway charges reward attention out of all proportion to the effort. Add the free endpoints, prune duplicate gateways, keep AWS-bound traffic off NAT, and a line item that quietly grew for years starts shrinking the next billing cycle. For the full picture, read the complete guide to AWS cost optimization and download the AWS Cost Optimization Field Guide.