NAT Gateway costs: what you're paying for and how to cut it
If a NAT Gateway line item on your AWS bill is bigger than expected, it’s almost never the hourly charge. It’s the per-gigabyte data processing charge, and it scales with traffic you probably weren’t tracking. This guide covers what a NAT Gateway actually bills for, whether you need one at all, what it costs by region using the live rates in our networking pricing reference, and the alternatives that remove or shrink the charge. For the mechanics of how the per-GB fee compounds with internet egress and internal AWS traffic, see The NAT Gateway trap; this guide is the shorter, decision-focused version.
What you’re actually billed for
A NAT Gateway has exactly two billing dimensions, and they behave very differently:
- Hourly charge, billed per gateway per hour it exists, whether or not it processes any traffic.
- Data processing charge, billed per gigabyte that passes through it, in both directions.
The hourly charge is predictable and small: about $33/month in us-east-1 for a single gateway. It’s also the number most people budget for, because it’s the one on the pricing page.
The data processing charge is the one that produces surprise invoices, because it’s proportional to traffic, and traffic through a NAT Gateway includes things people don’t think of as “internet egress”: container image pulls, patch downloads, calls to third-party APIs, and, if you haven’t set up a gateway endpoint, same-region calls to S3 or DynamoDB. A service moving a few terabytes a month through a single gateway turns a $33 line item into several hundred dollars, before you’ve added the separate internet data transfer charge AWS bills on top of it.
Do you need one at all
A NAT Gateway exists to let resources in a private subnet (no public IP, not directly reachable from the internet) initiate outbound connections. You need one, or something that does its job, whenever a private-subnet workload has to reach something outside its VPC.
But “outside the VPC” doesn’t always mean “the public internet,” and that distinction is where most of the savings live:
- Reaching AWS services that support Gateway Endpoints (S3, DynamoDB): route the traffic directly, for free. A Gateway Endpoint is a route table entry, not a running resource, so there’s no hourly charge and no per-GB charge. If your NAT Gateway is processing meaningful volume and you haven’t added these, this is the first thing to fix.
- Reaching other AWS services (ECR, CloudWatch Logs, Secrets Manager, SQS, SSM, and more): these support Interface Endpoints (AWS PrivateLink) instead. An Interface Endpoint runs as a network interface in your subnet and carries its own hourly-plus-per-GB charge, set independently of NAT Gateway pricing. It’s often cheaper than the NAT rate for high-volume services, but confirm the current PrivateLink price for the specific service on AWS’s pricing page before switching; it isn’t in our dataset.
- Reaching the actual public internet (third-party APIs, package registries, webhooks): this is what a NAT Gateway is for. No endpoint replaces it here.
If most of what shows up in your NAT Gateway’s data processing charge is same-region AWS traffic, you’re paying for something a route table change would make free.
What it costs, region by region
The hourly and per-GB rates aren’t uniform. They vary by region, sometimes by more than 2x. Pulled from our networking pricing data:
| Region | Hourly | Monthly (730 hrs, idle) | Per GB processed |
|---|---|---|---|
| us-east-1 (N. Virginia) | $0.045 | $32.85 | $0.045 |
| eu-west-1 (Ireland) | $0.048 | $35.04 | $0.048 |
| ap-east-1 (Hong Kong) | $0.065 | $47.45 | $0.065 |
| sa-east-1 (São Paulo) | $0.093 | $67.89 | $0.093 |
AWS keeps the hourly and per-GB rate identical within a region, so a region that’s expensive on one dimension is expensive on both. sa-east-1 charges more than double the us-east-1 rate on every gigabyte processed — a real cost if your architecture has a NAT Gateway running there rather than a cheaper region in the same geography. Check the full regional list, including every Local Zone we track, on the networking page, which has a live cost estimator for exactly this comparison.
Worked scenario: same setup, different regions
A single NAT Gateway, always on, processing 5 TB (5,000 GB) of traffic a month: a reasonable estimate for a mid-size service’s egress and inter-AZ AWS calls.
| Region | Hourly (730 hrs) | Data processing (5,000 GB) | Total / month |
|---|---|---|---|
| us-east-1 | $32.85 | $225.00 | $257.85 |
| eu-west-1 | $35.04 | $240.00 | $275.04 |
| ap-east-1 | $47.45 | $325.00 | $372.45 |
| sa-east-1 | $67.89 | $465.00 | $532.89 |
Same workload, same traffic volume: the São Paulo deployment costs more than double the Virginia one, and the gap is almost entirely the data processing rate, not the hourly charge. If your NAT Gateway sits in a region you didn’t deliberately choose for latency or compliance reasons, check what the same setup costs elsewhere.
One shared gateway vs. one per Availability Zone
A NAT Gateway lives in a single AZ. AWS’s own guidance, and most production architectures, put one gateway in each AZ so an AZ failure doesn’t take down egress for every private subnet: traffic from each AZ routes to the NAT Gateway local to it.
The alternative is one shared gateway in a single AZ, with every other AZ’s traffic crossing AZ boundaries to reach it. That’s cheaper but has a single point of failure: lose that AZ and every private subnet loses internet access, not just the ones in it.
Using the us-east-1 rates above, for the same 5,000 GB/month total traffic:
| Setup | Hourly charges | Data processing | Total / month |
|---|---|---|---|
| 1 shared NAT Gateway | $32.85 (1 gateway) | $225.00 | $257.85 |
| 1 NAT Gateway per AZ (3 AZs) | $98.55 (3 gateways) | $225.00 | $323.55 |
The data processing charge doesn’t change: it’s the same total bytes either way, billed per gigabyte regardless of which gateway handles it. The entire cost of the redundant setup is the extra hourly charge, $65.70/month here, or two gateways’ worth of idle time. That’s a small price for AZ-level resilience on most production budgets. For a dev or staging VPC where an AZ outage taking down egress for an hour isn’t a real incident, a single shared gateway is a legitimate way to cut the bill, not a corner-cutting mistake.
Cutting the bill without losing what you need
In rough order of effort:
- Add Gateway Endpoints for S3 and DynamoDB. Free, a route table change, no application changes. If you haven’t done this, it’s probably the single highest-leverage fix available: same-region S3/DynamoDB traffic is transferred for free by AWS but still gets metered at the full NAT rate if it happens to route through the gateway.
- Check Interface Endpoint pricing for your highest-volume AWS services. If a service like ECR or CloudWatch Logs accounts for a large share of your NAT data processing charge, PrivateLink pricing for that service may undercut the NAT rate, especially at volume. Confirm the current numbers on AWS’s own pricing page before switching.
- Reconsider one-per-AZ if it’s a non-production VPC. A single shared gateway removes two of the three hourly charges at the cost of AZ-level redundancy, a reasonable trade for dev, staging, or genuinely non-critical workloads.
- Consider a self-managed NAT instance for high, steady internet-bound volume. An EC2 instance doing packet forwarding has no per-GB charge at all; you pay only for the instance and its network throughput. This trades away the managed gateway’s automatic scaling and AWS-operated failover for a flat cost, and only makes sense once traffic is genuinely internet-bound (VPC endpoints can’t help there) and high enough that the per-GB savings outweigh the work of running and patching the instance yourself. See The NAT Gateway trap for the instance-sizing math.
- Check your region. If a workload’s NAT Gateway sits in a region you didn’t choose deliberately for latency, data residency, or compliance, compare the rate against a cheaper region on the networking page before assuming the current location is fixed.
Making the call
Fix regardless of scale. Missing Gateway Endpoints for S3 and DynamoDB. There’s no downside to adding them, and the fix is often the entire source of a surprise bill.
Worth checking against current numbers. Interface Endpoints for high-volume AWS API traffic (ECR, CloudWatch Logs, and similar), and self-managed NAT instances for sustained internet-bound volume. Both can beat the NAT Gateway rate, but the comparison depends on service-specific PrivateLink pricing or your own instance-management overhead — verify before committing either way.
A deliberate trade, not a default. One shared NAT Gateway instead of one per AZ. It’s the right call for non-production environments and genuinely cost-sensitive setups where an AZ outage taking down egress for a while is tolerable; it’s the wrong call for anything where that outage is an incident.
Bottom line: the hourly charge is the one you’ll remember and the per-GB charge is the one that actually moves the bill. Before questioning your architecture, check the two things a route table can fix for free, Gateway Endpoints for S3 and DynamoDB, then use the networking pricing reference to confirm you’re not paying a regional premium you didn’t choose.