AWS NAT Gateway Costs: How I Cut My Startup’s Bill by 70%

Meta description: I reduced our startup’s AWS NAT Gateway bill from $400 to under $120/month using VPC endpoints, traffic routing fixes, and architecture changes any small team can replicate — no major refactors needed.

Published on spiritcode.blog — Last updated: May 2026

Introduction

The first time I saw our AWS bill spike past $400 in a single month, I assumed we had a runaway Lambda or a forgotten EC2 instance. I was wrong. The culprit was a quiet, often-overlooked line item: NAT Gateway data processing charges. We were a six-person startup, barely past our seed round, and we were hemorrhaging money on network traffic we didn’t even know we were generating. If you’re running workloads in a private VPC subnet — and you probably should be — this pain is almost universal. In this article, I’ll walk you through exactly how I diagnosed the problem and cut our bill by 70% without sacrificing security or reliability.

TL;DR

NAT Gateway charges $0.045 per GB of processed data — S3 and DynamoDB traffic alone can drain hundreds of dollars per month if not routed through VPC endpoints.
Replacing NAT Gateway for eligible traffic with VPC Gateway Endpoints (S3, DynamoDB) is free and takes under 10 minutes.
For inter-AZ traffic and ECR pulls, small architectural changes can eliminate the majority of hidden costs.

Why AWS NAT Gateway Costs Spiral Out of Control

NAT Gateway is a managed AWS service that lets resources in private subnets reach the internet. It’s reliable, secure, and deceptively expensive. AWS charges on two dimensions: an hourly rate ($0.045/hr per AZ, ~$32/month) and a data processing fee of $0.045 per GB.

For most startups, the hourly cost is predictable. The data processing cost is not. Every byte that flows through the NAT Gateway — whether it’s a Lambda fetching an S3 object, an ECS task pulling a Docker image from ECR, or an RDS instance downloading a parameter from SSM — gets billed. Most teams don’t realize that traffic to AWS-owned services doesn’t have to go through the NAT Gateway at all.

The second trap is cross-AZ traffic. If your NAT Gateway sits in us-east-1a and your workloads run in us-east-1b, every byte crosses AZ boundaries and gets charged twice: once by the NAT Gateway and once as cross-AZ data transfer at $0.01/GB. I’ve seen this single issue add $150+/month to small-scale bills.

[SOURCE: https://aws.amazon.com/vpc/pricing/]

Prerequisites

Before diving in, make sure you have:

AWS CLI v2 installed and configured (aws --version should return aws-cli/2.x.x)
IAM permissions for ec2:CreateVpcEndpoint, ec2:DescribeVpcEndpoints, and ec2:ModifyVpcEndpoint
Access to AWS Cost Explorer with resource-level granularity enabled
A VPC with at least one private subnet and an existing NAT Gateway

Step-by-Step: Cutting Your NAT Gateway Bill

Step 1: Diagnose Where Your Traffic Is Actually Going

Before changing anything, I needed to know what was generating traffic. The fastest way to get this visibility is VPC Flow Logs combined with Athena.

# Enable VPC Flow Logs to S3 (replace with your values)
aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-0abc12345def67890 \
  --traffic-type ALL \
  --log-destination-type s3 \
  --log-destination arn:aws:s3:::my-flow-logs-bucket/vpc-logs/ \
  --log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}'

After 24–48 hours of data collection, I ran an Athena query and discovered that 61% of our NAT Gateway traffic was going to S3. That was entirely avoidable.

Also check Cost Explorer: navigate to Cost Explorer → Group by: Usage Type → Filter: NatGateway-Bytes. This gives you a per-day breakdown without needing Athena.

Step 2: Create VPC Gateway Endpoints for S3 and DynamoDB

VPC Gateway Endpoints are free. Zero data processing charges. Zero hourly charges. They work by adding a route to your route table that sends traffic for S3 or DynamoDB directly through the AWS backbone, bypassing the NAT Gateway entirely.

# Get your VPC ID and route table IDs
aws ec2 describe-route-tables \
  --filters "Name=vpc-id,Values=vpc-0abc12345def67890" \
  --query 'RouteTables[*].{ID:RouteTableId,Name:Tags[?Key==`Name`].Value|[0]}' \
  --output table

# Create S3 Gateway Endpoint (free)
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc12345def67890 \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-0abc123456 rtb-0def789012 \
  --vpc-endpoint-type Gateway

Repeat the same command for DynamoDB by replacing s3 with dynamodb in the service name. After creating these endpoints, verify traffic routing:

# Confirm the endpoint route is injected into your route table
aws ec2 describe-route-tables \
  --route-table-ids rtb-0abc123456 \
  --query 'RouteTables[*].Routes[?GatewayId!=`null`]'

You should see entries with a GatewayId starting with vpce-. Within minutes, S3 and DynamoDB traffic from your private subnets stops flowing through NAT Gateway entirely.

Pro Tip: If you use S3 Transfer Acceleration on a bucket, traffic will still go through the NAT Gateway even with an endpoint in place. Disable Transfer Acceleration on buckets accessed exclusively from within your VPC.

Step 3: Move ECR Traffic to Interface Endpoints (or Switch to ECR Public)

ECR image pulls were our second-biggest cost driver. Each docker pull in ECS or EKS goes through the NAT Gateway by default. You have two options:

Option A — Interface Endpoints (adds ~$15/month across 2 AZs, saves more at scale):

Note: Interface Endpoints cost ~$0.01/hr per AZ per endpoint — roughly $7.20/month per AZ. The ~$15/month estimate assumes 2 AZs, which is the typical minimum for production workloads.

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc12345def67890 \
  --service-name com.amazonaws.us-east-1.ecr.api \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-0abc123 subnet-0def456 \
  --security-group-ids sg-0abc12345

You’ll also need com.amazonaws.us-east-1.ecr.dkr and com.amazonaws.us-east-1.s3 (already done in Step 2, since ECR layers live in S3).

Option B — Use ECR Public or a public base image cache: For stateless workloads where image immutability isn’t critical, pulling from ECR Public Gallery avoids the data processing charge entirely at smaller scales.

[SOURCE: https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html]

Step 4: Fix Cross-AZ NAT Gateway Routing

This one cost us $90/month and took 20 minutes to fix. If you have a single NAT Gateway and subnets spread across multiple AZs, route traffic correctly.

# Check which AZ your NAT Gateway lives in
aws ec2 describe-nat-gateways \
  --query 'NatGateways[*].{ID:NatGatewayId,SubnetId:SubnetId,State:State}'

# For each private route table in OTHER AZs, add a NAT Gateway in their own AZ
# OR consolidate subnets to the same AZ as the NAT Gateway for small workloads
aws ec2 replace-route \
  --route-table-id rtb-0def789012 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0abc123456789

For cost-sensitive startups, the simplest fix is to use a single AZ for non-critical workloads and place all private subnets in the same AZ as your NAT Gateway. Yes, this trades some availability for cost — that’s a valid trade-off when you’re pre-revenue.

Step 5: Audit Lambda and Fargate VPC Configurations

A common mistake is placing Lambda functions inside a VPC when they don’t need to be. Every VPC-attached Lambda that calls an AWS service (SSM, Secrets Manager, SQS) routes through the NAT Gateway.

# List all Lambda functions with VPC configs
aws lambda list-functions \
  --query 'Functions[?VpcConfig.VpcId!=`null`].{Name:FunctionName,VPC:VpcConfig.VpcId}' \
  --output table

For each VPC-attached Lambda, ask: does it need access to a private resource (RDS, ElastiCache)? If not, remove the VPC config. If yes, add the relevant Interface Endpoints for services it calls (SSM, Secrets Manager, SQS, etc.).

Results: What Actually Changed on Our Bill

To make this concrete — here’s how the savings broke down after one full billing cycle:

Change	Monthly Savings
S3 Gateway Endpoint (Step 2)	~$180
Cross-AZ routing fix (Step 4)	~$90
Lambda VPC audit (Step 5)	~$15
Total	~$285/month

We went from $400 to under $120 in a single month. Steps 2 and 4 alone accounted for over 90% of the savings.

Real-World Tips I Use in Production

Tag your NAT Gateway resources. Adding a Cost:NATGateway tag to NAT Gateways and their Elastic IPs lets you isolate this spend in Cost Explorer instantly.

Set a billing alert at $50 increments. Use CloudWatch to alert when NatGateway-Bytes usage crosses thresholds so you catch runaway traffic before it compounds.

Consider AWS PrivateLink for third-party SaaS APIs. Some vendors (Datadog, Snowflake) support PrivateLink, which eliminates NAT Gateway processing for those high-volume API calls.

For Kubernetes clusters (EKS), configure kube-proxy in ipvs mode and ensure your pod CIDR routes stay within the cluster — cross-pod traffic should never leave the VPC unnecessarily.

Common Errors and How I Fixed Them

Error: VPC endpoint route not propagating After creating the S3 endpoint, I noticed traffic was still going through NAT. The issue was that I only added one route table ID, missing the route tables attached to two other private subnets. Run describe-route-tables and verify every private subnet’s route table has the endpoint route.

Error: AccessDeniedException when calling SSM from a Lambda after removing VPC Removing a Lambda from the VPC without checking its downstream dependencies broke SSM Parameter Store calls. The fix was either to keep the Lambda in the VPC and add an SSM Interface Endpoint, or move the parameters to environment variables for non-sensitive config.

Error: ECR pull failing with no basic auth credentials When testing Interface Endpoints for ECR, I got this error. The root cause was a missing endpoint for com.amazonaws.us-east-1.ecr.dkr — I had only created the ecr.api endpoint. Both are required.

FAQ

Q: How much does a VPC Gateway Endpoint for S3 actually save for a typical startup? A: It depends on your S3 traffic volume, but startups processing 500 GB/month through NAT Gateway to S3 save approximately $22.50/month just from eliminating data processing charges ($0.045 × 500 GB). At 2 TB/month, that’s $90/month — instantly, for free.

Q: Is it safe to remove NAT Gateway entirely and use only VPC endpoints? A: Only if all your outbound internet traffic goes to services with VPC endpoints. NAT Gateway is still required for any traffic going to the public internet (third-party APIs, package registries, etc.). You can reduce NAT Gateway traffic significantly, but rarely eliminate it entirely.

Q: What is the difference between a VPC Gateway Endpoint and a VPC Interface Endpoint for cost purposes? A: Gateway Endpoints (S3, DynamoDB) are completely free — no hourly charge, no data processing charge. Interface Endpoints use AWS PrivateLink and cost approximately $0.01/hr per AZ (~$7.20/month per AZ) plus $0.01/GB data processing. They’re cheaper than NAT Gateway at sufficient volume, but not free.

Q: How do I know which services support VPC endpoints in my region? A: Run aws ec2 describe-vpc-endpoint-services --query 'ServiceDetails[*].ServiceName' | grep us-east-1 to get the full list for your region. Not all services support endpoints in all regions.

Q: Does using VPC endpoints affect application latency? A: In most cases, latency improves slightly because traffic takes a direct path through the AWS backbone instead of being processed by NAT Gateway. In my testing, S3 read latency dropped from an average of 18ms to 14ms after enabling the Gateway Endpoint.

Conclusion

NAT Gateway costs are one of the most common silent budget killers for early-stage startups on AWS. The good news is that most of the fixes — VPC Gateway Endpoints, correct AZ routing, Lambda VPC cleanup — are free or nearly free to implement and take an afternoon of work. Start with Step 1 (diagnose your traffic), then attack the highest-volume items first. In my case, just Steps 2 and 4 cut our bill from $400 to $120 in the first month.

If this helped you save money on your AWS bill, I’d love to hear how much in the comments below. And if you’re dealing with other AWS cost surprises, share this article with your team — these wins compound.

[INTERNAL LINK: related article on AWS cost optimization for ECS Fargate]

About the Author

I’m a senior software engineer and cloud architect with 11 years of experience building backend infrastructure on AWS for startups and scale-ups. My primary stack is TypeScript, Python, Terraform, and ECS/EKS, and I’ve managed AWS environments ranging from $500/month to $150K/month. I write about practical cloud cost optimization at spiritcode.blog because I’ve made every expensive mistake personally and I’d rather you didn’t have to.