NAT gateway surprise bill: the quiet networking cost

Quick answer

A NAT gateway lets resources in a private subnet reach the internet, and it bills two ways: an hourly charge for each gateway (running around the clock) plus a per-GB data processing charge for every byte that flows through it. The surprise is the per-GB fee: high-traffic workloads, container image pulls, and data sent to the internet or even to AWS services over the public path can process terabytes, quietly costing far more than the hourly fee. Cut it with VPC endpoints for AWS services and by reducing traffic through the gateway.

Few line items surprise people like the NAT gateway. It is a small, boring networking component that lets private resources reach the internet, and it looks cheap until the data processing charge shows up. Because it bills per gigabyte in addition to an hourly rate, a busy workload can turn the NAT gateway into one of the larger lines on the bill, and almost nobody expects it.

How a NAT gateway bills

Charge	What it covers
Hourly fee	Per gateway, charged 24/7 while it exists
Data processing	Per GB of data passing through the gateway

The hourly fee is predictable and modest. The data processing fee is the trap: every gigabyte that flows through the gateway, in either direction, is charged per GB, and that is on top of any data transfer cost. For a private subnet doing heavy outbound work, the per-GB charge dwarfs the hourly fee, which is why the bill surprises people.

What quietly drives the data charge

Common culprits: containers pulling large images from public registries on every deploy or scale event, applications downloading big datasets or dependencies, backups or logs shipped to internet endpoints, and, crucially, traffic to AWS services like S3 and DynamoDB routed over the public path through the NAT gateway instead of a private endpoint. That last one is pure waste: you pay NAT data processing to reach a service that offers a free or cheaper private route. It compounds with other unexpected AWS charges.

Cutting the cost with endpoints

The biggest win is adding VPC endpoints for AWS services. A gateway endpoint for S3 and DynamoDB routes that traffic privately at no per-GB NAT cost, and interface endpoints via PrivateLink keep other AWS service traffic off the NAT gateway. For workloads that pull heavily from AWS services, endpoints alone can slash the NAT bill. Weigh the endpoint cost against the NAT savings, since interface endpoints have their own hourly and per-GB rates.

Reducing traffic and right-sizing the design

Beyond endpoints, cut the traffic itself: cache container images in a private registry so scale events do not re-pull from the internet, avoid routing internal traffic through the NAT gateway, and consolidate gateways where you have redundant ones. Consider whether some workloads even need internet egress. Centralizing egress through shared networking, as in the Transit Gateway comparison, can cut NAT sprawl further. Compare NAT-heavy designs with alternatives, and price your networking against the resource catalog so the data processing charge is visible before it lands on the invoice.

FAQ

Why is my NAT gateway bill so high?

Because a NAT gateway charges a per-GB data processing fee on every byte that flows through it, in addition to an hourly fee. The hourly fee is modest, but the per-GB charge adds up fast for high-traffic private subnets: container image pulls, large downloads, backups shipped to the internet, and especially traffic to AWS services routed over the public path instead of a private endpoint.

How is a NAT gateway priced?

Two ways: an hourly charge for each gateway that runs around the clock while it exists, plus a per-GB data processing charge for every gigabyte passing through it in either direction, on top of any data transfer cost. The per-GB data processing fee is usually the larger and more surprising part of the bill for busy workloads.

How do I reduce NAT gateway cost?

Add VPC endpoints for AWS services so that traffic to S3, DynamoDB, and other services bypasses the NAT gateway and its per-GB charge, cache container images in a private registry so scale events do not re-pull from the internet, avoid routing internal traffic through the gateway, and consolidate redundant gateways. Routing AWS-service traffic through endpoints is often the single biggest saver.

Do VPC endpoints eliminate NAT gateway charges?

They eliminate the NAT data processing charge for the traffic they carry. A gateway endpoint for S3 and DynamoDB routes that traffic privately at no per-GB NAT cost, and interface endpoints keep other AWS service traffic off the NAT gateway. Interface endpoints have their own hourly and per-GB rates, so weigh those against the NAT savings, but for AWS-service-heavy workloads endpoints usually win.

Why does AWS-service traffic through a NAT gateway waste money?

Because you pay the NAT per-GB data processing fee to reach a service like S3 or DynamoDB that offers a free or cheaper private route via a VPC endpoint. Routing that traffic through the NAT gateway is pure waste: the same requests could travel a private path at a fraction of the cost. Adding endpoints removes that avoidable charge entirely.

How does C3X help avoid NAT gateway surprise bills?

C3X prices your networking infrastructure, including NAT gateways and VPC endpoints, from Terraform before you deploy, so the hourly and data processing cost of a NAT-heavy design is visible in the pull request. That lets you spot an avoidable NAT bill and add endpoints at design time, rather than discovering the per-GB data processing charge after it has accumulated on the invoice.

What to do next

Catch NAT gateway data processing cost before it ships. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.