AWS NAT Gateway Pricing 2026 (Calculator + Alternatives)

Complete pricing reference with a monthly cost calculator, regional comparison, and when VPC Endpoints or alternative architectures are cheaper.

AWS NAT Gateway pricing has two components that combine into nearly every "surprise bill" story you've seen on DevOps forums: an always-on hourly charge per NAT Gateway per Availability Zone, plus a per-GB data-processing fee on every byte routed through it — in either direction, regardless of destination. The data-processing fee is what catches teams out: it stacks on top of standard internet egress charges, so the same byte can be billed twice on the way out of AWS.

This page is the pricing reference. If you want the war-story version of what bill shock looks like in practice, see The AWS NAT Gateway Bill That Should Have Been $0.

NAT Gateway pricing components

AWS bills NAT Gateway on three separate lines. All three show up on the bill, but the data-processing fee is usually the largest and the one teams under-anticipate.

NAT Gateway pricing by region

Rates vary by region. US East regions are the cheapest baseline; Asia Pacific and South America regions can be 2× or more. The values below reflect typical 2026 list pricing — always cross-check with the AWS VPC pricing page before committing architecture, since AWS adjusts these without much announcement.

A NAT Gateway running 24/7 in one AZ costs roughly $32.85/month in US East before any data charges. Multi-AZ deployments multiply this — 3 AZs = $98.55/month minimum. Add data-processing fees on top.

Where NAT Gateway costs explode (and where they don't)

NAT Gateway is fine at low traffic volumes. It becomes expensive when one of these patterns is in play:

• Container image pulls through ECR over the public route. Every restart pulls hundreds of MBs. At 100+ task restarts/day, you're processing terabytes/month through NAT for traffic that should never have left the AWS internal network. Fix: VPC Interface Endpoints for ECR + S3 Gateway Endpoint.
• S3 traffic via the internet route. Without an S3 Gateway Endpoint, S3 traffic from a private subnet hits NAT processing fees plus egress. Fix: S3 Gateway Endpoint (free).
• DynamoDB, Secrets Manager, KMS, SSM traffic over NAT. All have Interface Endpoints. At any non-trivial volume, the endpoint hourly fees are dwarfed by the NAT processing savings.
• Cross-region replication and backup traffic. Inter-region S3 replication, RDS cross-region read replicas, and backup synchronization can be terabytes/month — all billable if routed through NAT.
• Third-party log shipping (Datadog, Splunk, New Relic). Agents on private-subnet hosts ship logs/metrics outbound through NAT. At 10–50 GB/host/month, this compounds quickly across a large fleet.

NAT Gateway vs the alternatives

When NAT Gateway is still the right choice

Despite the bad reputation, NAT Gateway is the correct architecture for plenty of workloads. Specifically:

• Private-subnet workloads that need to reach arbitrary third-party APIs and SaaS endpoints (Stripe, Twilio, OpenAI, Slack, etc.) for which no Interface Endpoint exists.
• OS updates, package repositories (apt, yum, npm, PyPI) from private subnets — these have no AWS-internal route.
• Outbound webhooks, callbacks, and integrations where you can't predict the destination ahead of time.
• Low-volume (<100 GB/month) workloads where the engineering cost of architecting around NAT exceeds the bill.

The default pattern that works for most production VPCs: NAT Gateway in 2 AZs for HA, with S3 + DynamoDB Gateway Endpoints and Interface Endpoints for the 4–6 AWS services your workloads use heavily (most commonly ECR, ECR-DKR, KMS, Secrets Manager, SSM, and STS).

How to find your actual NAT Gateway spend

1. Open AWS Cost Explorer → group by Service and filter to EC2-Other.
2. Within that, group by Usage Type. Look for NatGateway-Bytes (the data-processing fee) and NatGateway-Hours (the hourly charge).
3. Compare NatGateway-Bytes against your total outbound data volume. If it's >30% of your VPC's egress, your private-subnet workloads are routing traffic through NAT that doesn't need to.
4. Drill into VPC Flow Logs for one NAT Gateway over a representative 24-hour window. Group destination IPs by frequency. The top 20 destinations almost always reveal at least one egress-heavy pattern (third-party log shipping, an ECR pull pattern, a missing S3 Endpoint) that's fixable.

Quick-win architectural fixes

1. Add an S3 Gateway Endpoint on every VPC where private-subnet workloads touch S3. It's free and immediately removes S3 traffic from your NAT bill.
2. Add a DynamoDB Gateway Endpoint on every VPC with DynamoDB-using workloads. Also free.
3. Add Interface Endpoints for ECR (ecr.api + ecr.dkr) and ECS if you run containers from private subnets. The hourly fees are dwarfed by the NAT processing savings on container pulls.
4. Add Interface Endpoints for KMS, Secrets Manager, and SSM. These three are called constantly by application code; pulling them through NAT is pure waste.
5. Move third-party log shipping through a VPC Endpoint where the vendor offers one (Datadog, Splunk both do).
6. For egress-heavy workloads above 5 TB/month outbound: consider moving storage to Cloudflare R2 (zero egress fees) or moving the workload to Vultr or Hetzner (10–20 TB included in instance price).

For broader networking and egress strategy, see the guide to reducing AWS egress costs, the zero-egress storage stack, and the AWS vs Vultr egress calculator. For broader AWS cost work, the AWS cost optimization checklist.