Most teams build a private subnet, drop a NAT Gateway in for outbound internet, and forget. Then over years: - Containers pull base images from public ECR through NAT - S3, DynamoDB, SQS, Secrets Manager calls all egress through NAT - CloudWatch agent ships logs through NAT - An EKS cluster doing 200 GB/day of image pulls = ~$270/month per cluster, just on NAT processing Multiply by environments, regions and accounts. Easy to hit five figures monthly.

AWS NAT Gateway Cost: Why It's Your Biggest Surprise

Q: What I look for on a real audit?

- NAT processing GB/month divided by NAT GB cost — that's your egress volume - Whether S3 and DynamoDB Gateway Endpoints exist (they should, they're free) - Whether ECR endpoints exist on any container-heavy account - Whether dev and staging environments share a NAT (they shouldn't egress much, but often do) - Cross-AZ NAT placement (one NAT per AZ if HA matters, otherwise one is fine for non-prod)

NAT Gateway is the silent line item that quietly eats $5-50k a month. Here's exactly what's driving it and how I cut it on real audits.

By Andrii Votiakov on 2026-02-15

When I open a new AWS bill, the first place I look after EC2 and RDS is NAT Gateway. On nine out of ten audits, it's a top-five line item and almost always recoverable. One client was paying $11,800 a month for NAT — we got it under $1,200 in a fortnight without a single architecture rewrite. NAT is closely related to the broader AWS data transfer charges picture — cross-AZ, cross-region, and NAT processing all show up on the same bill and are worth auditing together. For EKS clusters in particular, NAT from container image pulls is often the first thing to fix.

Quick answer

NAT Gateway charges you twice: a fixed hourly rate per gateway (about $0.045/hour, ~$32/month) and a per-GB processing fee on every byte that flows through it (around $0.045/GB). The processing fee is what kills bills. Cut it by routing AWS-bound traffic through VPC endpoints instead of NAT.

Why the bill grows

Most teams build a private subnet, drop a NAT Gateway in for outbound internet, and forget. Then over years:

Containers pull base images from public ECR through NAT
S3, DynamoDB, SQS, Secrets Manager calls all egress through NAT
CloudWatch agent ships logs through NAT
An EKS cluster doing 200 GB/day of image pulls = ~$270/month per cluster, just on NAT processing

Multiply by environments, regions and accounts. Easy to hit five figures monthly.

The fixes, ordered by ROI

1. Add a Gateway Endpoint for S3 and DynamoDB (free)

Gateway Endpoints cost nothing. They eliminate all S3 and DynamoDB traffic from NAT. On a typical workload this alone takes 30-60% off the NAT bill.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxx \
  --service-name com.amazonaws.eu-west-1.s3 \
  --route-table-ids rtb-xxx

2. Add Interface Endpoints for the chatty services

Interface (PrivateLink) endpoints cost about $0.01/hour each (~$7/month) plus $0.01/GB processed — but the per-GB rate is lower than NAT and there's no fixed NAT processing on top. Add endpoints for the services you actually use:

ecr.api and ecr.dkr (huge for any container workload)
logs (CloudWatch Logs)
secretsmanager
ssm, ssmmessages, ec2messages (SSM Session Manager)
sts, sqs, sns, kms

Rough rule: if traffic to a service exceeds 40-50 GB/month, an Interface Endpoint pays for itself.

3. Use VPC peering or Transit Gateway for cross-account AWS traffic

If your VPC talks to AWS services or accounts in another VPC, NAT is the wrong path. Peering or Transit Gateway is dramatically cheaper at scale.

4. Stop pulling images from public ECR

Move base images into a private ECR repo in the same region, behind your ecr.dkr endpoint. Eliminates the "1 GB image × 50 nodes × 3 times a day" disaster.

5. Centralise NAT in a shared egress VPC (only at scale)

If you have 10+ VPCs, run NAT in one shared egress VPC connected via Transit Gateway. Cuts fixed NAT hourly costs without changing per-GB economics.

How to find your worst offenders

Enable VPC Flow Logs, ship them to S3, and query with Athena. This one query gives you the top destinations consuming NAT bandwidth:

SELECT srcaddr, dstaddr, SUM(bytes) AS total_bytes
FROM vpc_flow_logs
WHERE date = '2026-02-14'
  AND interface_id = 'eni-of-your-nat'
GROUP BY srcaddr, dstaddr
ORDER BY total_bytes DESC
LIMIT 50;

You'll usually find one or two services responsible for 70%+ of the volume. Fix those first.

What I look for on a real audit

NAT processing GB/month divided by NAT GB cost — that's your egress volume
Whether S3 and DynamoDB Gateway Endpoints exist (they should, they're free)
Whether ECR endpoints exist on any container-heavy account
Whether dev and staging environments share a NAT (they shouldn't egress much, but often do)
Cross-AZ NAT placement (one NAT per AZ if HA matters, otherwise one is fine for non-prod)

Realistic savings

On clients I've worked with, NAT savings break down roughly:

Adding S3 + DynamoDB Gateway Endpoints: 30-50% reduction
Adding ECR + Logs + Secrets endpoints on container accounts: another 30-40%
Combined with VPC Flow Logs cleanup: typically 70-90% off the original NAT bill

Most of this is one engineer for one to two weeks of work.

If you want me to find your NAT cost leaks and fix them on a pay-for-savings basis, book a call. 30 minutes, no pitch.