Why Your NAT Gateway Costs More Than Your Compute

This is not a universal AWS truth. It is a specific pattern that appears in private-subnet architectures running ECS or EKS, and it catches teams off guard because the cost is invisible until someone looks at the right line item.

The pattern: your containers are in private subnets. Every image pull from ECR, every S3 API call, every SSM parameter fetch, and every patch download crosses your NAT Gateway. You pay $0.045 per GB for every byte of that traffic. Your EC2 or Fargate compute costs are fixed and predictable. Your NAT Gateway data processing costs grow with every deployment, every container restart, and every dependency update.

In accounts running ECS or EKS at any meaningful scale, NAT Gateway data processing charges routinely exceed the compute costs they are supposed to be supporting.

The Data Path Nobody Designed Explicitly

When you deploy containers into private subnets, the default data path for any traffic that needs to reach AWS services is: container → private subnet → NAT Gateway → internet → AWS service endpoint → back through NAT Gateway → container.

AWS charges $0.045 per GB processed by the NAT Gateway. Every ECR image pull, every S3 GetObject, every Secrets Manager call, every SSM parameter fetch is metered at that rate as it passes through. At $0.045/GB, a single ECS service pulling a 2GB container image on every deployment across 10 tasks is paying $0.90 per deployment just in NAT Gateway data processing. Multiply that by daily deployments across multiple services and the number compounds fast.

The alternative path: container → private subnet → VPC endpoint → AWS service. No NAT Gateway. No data processing charge. The traffic stays inside the AWS network.

Source: Amazon VPC pricing, NAT Gateway section

What VPC Endpoints Actually Do

A VPC endpoint creates a private connection between your VPC and an AWS service without requiring traffic to leave the AWS network. There are two types relevant here.

Gateway endpoints are free. They cover S3 and DynamoDB. If your containers are making S3 API calls and those calls are going through NAT, you are paying for traffic that should cost nothing. Adding a Gateway endpoint for S3 is a one-time configuration change that takes under 10 minutes and immediately removes S3 traffic from your NAT Gateway data processing charges.

Source: Gateway endpoints for S3 and DynamoDB

Interface endpoints cost $0.01/hour per AZ plus $0.01/GB of data processed. For ECR, this is $7.20/month per AZ for the endpoint itself, plus data processing at $0.01/GB instead of $0.045/GB through NAT. For accounts pulling large container images frequently, the math favors the endpoint.

Source: AWS PrivateLink pricing

The ECR Pull Tax

ECR image pulls are the most common driver of unexpected NAT Gateway costs in ECS and EKS environments. Here is why.

When ECS launches a new task, it pulls the container image from ECR. If the image is not cached on the underlying EC2 instance (or if you are using Fargate, where there is no persistent cache), every task launch triggers a full image pull. A 1GB image pulled by 20 tasks on a deployment is 20GB of NAT Gateway traffic. At $0.045/GB, that is $0.90 per deployment.

Add the Amazon ECR VPC endpoint and the ECR pull traffic moves off NAT for the image layer data path. Note that ECR pulls involve two endpoints: ecr.api for the API calls and ecr.dkr for the actual image layers. Both need to be created for the full pull path to stay private. The endpoint data processing rate is $0.01/GB instead of $0.045/GB through NAT. For an account pulling 500GB/month from ECR, the difference is $22.50/month in data processing savings, minus the endpoint hourly cost.

For EKS clusters using Karpenter or Cluster Autoscaler, node scale-out events trigger image pulls on every new node. A scale-out event that launches 10 new nodes, each pulling a 2GB image, is 20GB of NAT traffic in a single event. Without an ECR VPC endpoint, that is $0.90 per scale-out event. With high-traffic workloads that scale frequently, this adds up.

The Deployment Circuit Breaker Connection

There is a less obvious NAT Gateway cost driver in ECS environments: failed deployments.

When an ECS deployment fails and the ECS deployment circuit breaker is not configured, ECS will keep trying to launch new tasks. Each failed task launch triggers a new image pull. Each image pull crosses NAT. A deployment that fails 50 times before someone notices has pulled the container image 50 times through NAT Gateway.

This is the pattern from a real ECS incident: a failed deployment before a holiday, three microservices not turning healthy, ECS retrying repeatedly, all traffic going through NAT because there was no VPC endpoint for ECR. Daily costs doubled. The fix was two things: the ECR VPC endpoint and the deployment circuit breaker.

The circuit breaker is configured at the ECS service level. Source: ECS deployment circuit breaker

The Security Dimension

When traffic to AWS services routes through NAT instead of VPC endpoints, it loses the private endpoint path and the endpoint-policy controls that VPC endpoints provide.

With a VPC endpoint for S3, you can attach an endpoint policy that restricts which S3 buckets your VPC can access. Traffic going through NAT has no equivalent network-level control. Any IAM principal in your VPC can reach any S3 bucket they have IAM permissions for, with no additional constraint at the network layer.

The same applies to ECR. An ECR VPC endpoint lets you restrict which ECR repositories your VPC can pull from. Without it, a compromised container with valid ECR credentials can pull from any repository in any account.

VPC endpoints are thus both a cost optimization and a security control. The data path decision you make for cost reasons has security implications you may not have considered.

How to Audit Your Current NAT Gateway Costs

Three steps to understand what is actually crossing your NAT Gateway:

Step 1: Check VPC Flow Logs for destination IPs

Enable VPC Flow Logs on your NAT Gateway if they are not already enabled. Filter for traffic destined for AWS service IP ranges. S3, ECR, and other AWS services have published IP ranges in the AWS IP address ranges JSON. Traffic to these IPs through NAT is traffic that could be using VPC endpoints instead.

Step 2: Filter Cost Explorer by EC2 Other usage type

In Cost Explorer, filter by service “EC2” and usage type containing “NatGateway-Bytes”. This shows your NAT Gateway data processing charges separately from the hourly fees. Compare this against your EC2 or Fargate compute costs for the same period. If NAT Gateway data processing is more than 20% of your compute costs, you have a data path problem worth fixing.

Step 3: Check which services are generating the traffic

In the AWS console, go to VPC → NAT Gateways → select your gateway → Monitoring. The CloudWatch metrics show bytes in and bytes out over time. Correlate spikes with deployment events, scale-out events, or batch jobs. This tells you which workloads are driving the cost.

What to Add First

If you are starting from scratch, add these in order:

1. S3 Gateway endpoint — free, immediate savings, 10-minute setup. Add it to every route table in your private subnets.

2. ECR Interface endpoint — costs $0.01/hour per AZ but removes ECR pull traffic from NAT. Worth it for any account running ECS or EKS with frequent deployments.

3. ECS deployment circuit breaker — not a VPC endpoint, but prevents failed deployments from generating runaway NAT traffic. Configure it on every ECS service.

4. SSM and Secrets Manager endpoints — if your containers fetch parameters or secrets at startup, this traffic crosses NAT on every task launch. Interface endpoints for both services remove this traffic from NAT.

Note: Adding VPC endpoints requires updating your route tables and security groups. For S3 Gateway endpoints, you add the endpoint to the route table. For Interface endpoints, you create the endpoint in your VPC and ensure your security groups allow traffic to the endpoint’s private IP. Test in a non-production environment first.

The Broader Point

NAT Gateway is not expensive by design. It is expensive when used as the default path for traffic that has a better option.

Private-subnet architectures are the right security posture for production workloads. The cost of that posture should not be paid in NAT Gateway data processing charges for traffic that never needed to leave the VPC network boundary.

The data path decision is a one-time architectural choice. Most teams never made it explicitly. They deployed into private subnets, added a NAT Gateway for internet access, and assumed that was sufficient. The VPC endpoint layer is the part that makes the architecture both secure and cost-efficient simultaneously.

Start your free CostObserver beta — read-only access, no credit card, connects in minutes.