NAT gateway cost optimization: a sneaky networking bill
NAT gateways bill an hourly fee plus per-GB data processing, so high-traffic private subnets accessing the internet or AWS services rack up processing charges. VPC endpoints, consolidation, and architecture cut it. Here is how.
Quick answer
NAT gateways let resources in private subnets reach the internet, billing an hourly fee per gateway plus a per-GB data processing charge on all traffic through them. The data processing charge is the sneaky part: high-traffic private resources, especially those pulling large amounts from S3 or other AWS services through the NAT, rack up significant cost. The levers: use VPC endpoints (Gateway endpoints for S3/DynamoDB are free and bypass the NAT), consolidate gateways sensibly, and reduce unnecessary internet-bound traffic.
A NAT gateway lets resources in private subnets initiate outbound connections to the internet (or to AWS services over the public path) while staying unreachable inbound. It bills an hourly fee plus a per-gigabyte data processing charge, and that processing charge is a commonly-underestimated cost, especially when private resources pull large volumes through it.
Hourly fee plus data processing
| Component | Cost |
|---|---|
| Hourly charge | Per NAT gateway, per hour |
| Data processing | Per GB through the gateway (the sneaky cost) |
| Plus egress | Internet egress on top, if internet-bound |
The hourly fee is modest and fixed. The data processing charge, billed per gigabyte of all traffic through the NAT, is the one that surprises: a private subnet pulling large amounts from S3, container registries, or package repositories through the NAT is charged per gigabyte processed (on top of any egress for internet-bound traffic). At high volume, this dominates the NAT cost.
VPC endpoints bypass the NAT
The biggest lever is VPC endpoints. Gateway endpoints for S3 and DynamoDB are free and route traffic to those services privately without going through the NAT, eliminating the data processing charge for that traffic. Interface endpoints (for other AWS services) have their own cost but can be cheaper than routing heavy service traffic through the NAT. Pulling container images and packages from services reachable via endpoints, rather than through the NAT, avoids large processing charges.
Controlling NAT gateway cost
Use Gateway VPC endpoints for S3 and DynamoDB (free, and they bypass the NAT for that traffic, often the biggest saving), use interface endpoints for heavy AWS service traffic where cheaper than the NAT, consolidate NAT gateways sensibly (one per AZ for availability, not more than needed), reduce unnecessary internet-bound traffic from private subnets, and route large data pulls through endpoints rather than the NAT. Because the data processing charge is the sneaky cost, bypassing the NAT for high-volume service traffic is the key lever, part of broader VPC cost.
FAQ
What drives NAT gateway cost?
An hourly fee per gateway (modest and fixed) plus a per-GB data processing charge on all traffic through it (the sneaky part). High-traffic private resources, especially those pulling large volumes from S3, container registries, or package repositories through the NAT, rack up significant data processing charges, plus internet egress on top for internet-bound traffic.
How do I reduce NAT gateway cost?
Use Gateway VPC endpoints for S3 and DynamoDB (free, and they bypass the NAT for that traffic, often the biggest saving), use interface endpoints for heavy AWS service traffic where cheaper than the NAT, consolidate NAT gateways sensibly (one per AZ for availability), reduce unnecessary internet-bound traffic, and route large data pulls through endpoints rather than the NAT.
Why is the NAT gateway data processing charge sneaky?
Because it bills per gigabyte of all traffic through the NAT, including traffic to AWS services like S3, and it is easy to overlook. A private subnet pulling large amounts from S3, container registries, or package repos through the NAT accrues per-gigabyte processing charges that surprise teams, since they focus on the modest hourly fee and miss the volume-based processing cost.
How do VPC endpoints reduce NAT cost?
Gateway VPC endpoints for S3 and DynamoDB are free and route traffic to those services privately without going through the NAT gateway, eliminating the per-GB data processing charge for that traffic. So moving heavy S3 or DynamoDB access from the NAT path to a Gateway endpoint removes those processing charges entirely, often the single biggest NAT cost saving.
How many NAT gateways do I need?
Typically one per availability zone for high availability (so an AZ failure does not sever internet access for that zone's private subnets), not more than needed. Running more NAT gateways than availability requires adds hourly fees without benefit, while consolidating too far sacrifices resilience. One per AZ balances availability against cost for most architectures.
Does C3X estimate NAT gateway cost?
C3X prices NAT gateways from your Terraform, including the hourly fee, so the fixed cost appears before deploy. The data processing charge depends on traffic volume through the NAT, which you provide as a usage assumption, and using VPC endpoints (which C3X also prices) reduces that traffic.
What to do next
Price your NAT gateways and VPC endpoints before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.