NAT Gateways Explained

NAT Gateways are one of those infrastructure components that most teams set up once and never think about again. They work quietly in the background, enabling private resources to access the internet. But that quiet background work comes with a price tag that catches many organizations off guard.

What Is a NAT Gateway?

A NAT (Network Address Translation) Gateway allows resources in a private subnet to initiate outbound connections to the internet while preventing unsolicited inbound connections. Think of it as a one-way door: your private servers can reach out to download updates, call APIs, or push logs, but external traffic can't initiate connections back in.

Every major cloud provider offers managed NAT Gateway services: AWS NAT Gateway, Google Cloud NAT, and Azure NAT Gateway. They're simple to set up, highly available, and auto-scaling. They're also surprisingly expensive.

How NAT Gateway Costs Add Up

NAT Gateway pricing has two components that compound:

• Hourly charge: You pay per hour the NAT Gateway exists, regardless of usage. On AWS, that's ~$0.045/hour or ~$32/month per gateway.
• Data processing charge: You pay per GB of data processed through the gateway. On AWS, that's ~$0.045/GB.

The hourly charge is predictable. The data processing charge is where surprises happen.

Real Cost Example

That's one NAT Gateway in one availability zone. Most production setups have 2-3 for high availability. And 500 GB is modest. Applications pulling container images, downloading dependencies, sending logs, and calling external APIs can easily process 2-5 TB/month.

A seemingly simple NAT Gateway setup can quietly cost $200-500+/month. Across multiple environments and regions, that adds up to thousands annually.

When You Actually Need a NAT Gateway

• Private resources need to reach external APIs (payment gateways, SaaS tools)
• You need a fixed outbound IP for allowlisting by external partners
• Compliance requires that your backend resources have no direct internet access

When You Don't Need One (Alternatives)

VPC Endpoints / Private Link

If your private resources are mainly accessing AWS/GCP/Azure services (S3, DynamoDB, Container Registry), VPC Endpoints provide private connectivity without going through a NAT Gateway. The data processing charges for gateway endpoints are often free (S3, DynamoDB on AWS) or significantly cheaper.

Public Subnets for Stateless Services

Not every service needs to be in a private subnet. Stateless, containerized workloads behind a load balancer can run in public subnets with security groups providing the access control. This eliminates NAT Gateway costs entirely for those workloads.

NAT Instances

For development and staging environments, a small EC2 instance acting as a NAT instance costs a fraction of a managed NAT Gateway. A t3.nano (~$3.80/month) can handle moderate traffic for non-production environments.

How to Audit Your NAT Gateway Usage

1. Check VPC Flow Logs. Identify which resources are sending traffic through the NAT Gateway and where it's going.
2. Review the destinations. If most traffic goes to AWS services, VPC Endpoints eliminate that cost.
3. Measure data volumes. Use CloudWatch metrics (BytesOutToDestination, BytesOutToSource) to understand actual throughput.
4. Evaluate per-environment needs. Dev and staging environments rarely need the same NAT Gateway setup as production.
5. Consider alternatives. For each traffic pattern, determine if a VPC Endpoint, public subnet, or NAT instance is more cost-effective.