TL
The short answer

NAT gateway cost has two parts: a fixed hourly charge for each gateway you run, and a data processing charge for every gigabyte that flows through it. The hourly charge is predictable and small. The per gigabyte processing charge is the one that grows silently, because it scales with traffic and applies even to traffic that never needed to touch the internet, such as calls to S3, DynamoDB, or other AWS services. Cut the processing charge by removing AWS service traffic from the NAT path with VPC endpoints, and the line drops without touching application behaviour.

This article is part of the AWS network and data cluster, alongside data transfer between AZs and regions and VPC endpoints as a cost move. Together they cover the quiet network charges that rarely appear in a rightsizing exercise.

Why are NAT gateway costs so high?

The surprise is almost always the data processing fee, not the hourly fee. Teams provision a NAT gateway per availability zone for resilience, see a modest hourly line, and ignore it. Meanwhile every byte a private subnet sends out, to the internet or to an AWS service reached over a public endpoint, is billed per gigabyte through the gateway. On a busy microservices estate pulling images, writing to object storage, and calling managed services, that processed volume can be enormous.

Two design habits make it worse. First, routing AWS service traffic through NAT: if a private subnet reaches S3 over the public endpoint, every object byte is processed by the NAT gateway and billed, despite never leaving the AWS network. Second, per AZ gateways with cross AZ traffic: instances talking to a gateway in another availability zone add cross zone transfer on top. Both are invisible until you read the processing line.

What are the alternatives?

Ordered by how much they typically save, and how disruptive they are.

VPC endpoints for AWS service traffic

Gateway endpoints for S3 and DynamoDB are free and route that traffic off the NAT path. Interface endpoints cover many other AWS services and carry their own hourly and per gigabyte charge, so they pay off when they divert enough NAT processing to beat their own cost. For most estates, adding S3 and DynamoDB gateway endpoints is the single largest, lowest risk NAT saving available. We cover the sizing in VPC endpoints as a cost move.

Consolidate or centralise egress

Running one NAT gateway per AZ across many small VPCs multiplies the hourly charge. A shared egress VPC with centralised NAT, reached over Transit Gateway, can cut the number of gateways, though you then weigh Transit Gateway processing against the saving. This is an architecture decision, not a config tweak, so model it before committing.

Self managed NAT instance, narrowly

In specific high volume, latency tolerant cases, a self managed NAT instance avoids the per gigabyte processing fee in exchange for running and operating the instance yourself, including patching and high availability. It is rarely worth the operational burden for general workloads, but for a small number of extremely chatty egress paths the maths can favour it. Treat it as an exception, not a default.

A worked example

Worked example

A Fortune 500 retailer saw a steadily rising NAT data processing line and assumed it was internet egress growth. The CUR told a different story: a large share of the processed gigabytes were calls from private subnets to S3 over the public endpoint, for image and asset reads. Adding an S3 gateway endpoint, which is free, removed that traffic from the NAT path overnight and cut the processing charge by a material double digit percentage with zero application change. A second pass consolidated several per VPC NAT gateways into a shared egress design, trimming the hourly component too. Figures are verified against billing data and anonymised, and the endpoint move carried no functional risk.

The general lesson: before you touch architecture, read the Cost and Usage Report to see what is actually being processed. NAT charges are usually a routing problem, not a traffic problem.

Frequently asked questions

Why are NAT gateway costs so high?
A managed NAT gateway charges an hourly rate per gateway plus a per gigabyte processing fee on every byte through it. On chatty workloads the per gigabyte charge, not the hourly fee, is what makes the line large, and it grows silently as traffic grows.
What are the alternatives to a NAT gateway?
VPC gateway and interface endpoints keep AWS service traffic off the NAT path. For internet bound traffic, consolidate gateways, route through a shared egress VPC, or in narrow cases use a self managed NAT instance. The biggest win is usually removing AWS service traffic from the NAT path.
Do VPC endpoints replace a NAT gateway?
Partly. Gateway endpoints for S3 and DynamoDB are free and remove that traffic from the NAT path. Interface endpoints carry their own hourly and per gigabyte charge, paying off when they divert enough processing. You still need a NAT path for general internet egress.

Where this fits the network review

NAT charges are one of several quiet network and data transfer costs we hunt in an AWS review, alongside cross AZ traffic, egress, and endpoint design. We do this as an independent buyer side advisory across AWS, Azure, GCP, and OCI, with zero provider commissions and a guarantee: we reduce your cloud spend or we reimburse our service fee.

For more buyer side network and data moves, subscribe to The Cloud Spend Navigator.

Independent · buyer-side

Put a defensible number on your cloud spend.

No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.

Buyer-side intelligence, monthly.

The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.