AWS cost optimization

AWS NAT Gateway Cost: What Small Teams Should Check

AWS NAT Gateway cost can grow through hourly, data processing, and traffic-path charges. Use this safe review guide before changing routes or endpoints.

Published 2026-06-01 Updated 2026-06-01 By Cloud Cost Clinic

Quick takeaway

AWS NAT Gateway cost usually comes from more than one billing signal: the gateway existing, the data it processes, and the traffic path around it. The practical answer is not "delete the gateway." It is: start with the bill, split the usage type, map the route table, and verify what would break before changing anything.

NAT Gateway spend is like a toll road. The surprise is often not that the road exists. It is how much traffic quietly started using it.

Network cables in a server room used as a visual cue for AWS NAT Gateway cost review

Why AWS NAT Gateway cost gets expensive

A NAT Gateway lets resources in private subnets reach services outside the VPC while keeping those resources from being directly reachable from the internet. That managed convenience can be worth paying for, especially in production.

The cost surprise usually appears when a private workload sends a lot of traffic through that path. As of June 1, 2026, AWS documentation says NAT Gateway billing includes each hour the NAT Gateway is available and each gigabyte of data it processes. Exact rates vary by Region and can change, so use the current Amazon VPC pricing page before estimating dollars.

For small teams, the common pattern looks like this:

  • A VPC template creates NAT Gateways in one or more Availability Zones.
  • Private workloads use default routes through NAT.
  • S3, DynamoDB, ECR, CloudWatch Logs, package downloads, or external API calls start moving real volume.
  • Nobody reviews the route path until the VPC line item grows.

That does not mean the gateway is wrong. Expensive can be valid. Mysterious is the problem.

What is inside the NAT Gateway bill

When reviewing aws nat gateway cost, separate the components before recommending a fix:

  • NAT Gateway hours: the recurring charge while the gateway exists.
  • NAT Gateway data processing: data that flows through the gateway.
  • Standard data transfer: internet egress, cross-AZ transfer, or other network transfer charges that may sit beside the NAT charge.
  • Public IPv4 address cost: a public NAT Gateway uses public IPv4 addressing, and AWS public IPv4 pricing can be an adjacent line item.
  • Regional and Availability Zone design: the number of gateways, the workload placement, and cross-AZ routing shape the bill.

This is why a NAT review should start in billing, not in the VPC console. The VPC console shows the network parts. Cost Explorer shows whether the material issue is hours, bytes, transfer, Region, or a new daily baseline.

The bill is the most honest dashboard in the account. It is not always the friendliest one.

How to find NAT Gateway spend in Cost Explorer

Start with a narrow billing view:

1. Open Cost Explorer. 2. Set the date range to the last full month, then compare it with the current month. 3. Filter or group for Amazon VPC-related spend. 4. Group by usage type. 5. Split by Region and linked account if you use multiple accounts. 6. Change the granularity to daily to find spikes, steady baselines, and step-changes.

Look for usage types that clearly separate gateway hours from NAT data processing. The exact labels can vary by report view, but the practical goal is consistent: isolate "gateway exists" spend from "traffic moved through the gateway" spend.

Then add context:

  • Which account owns the VPC?
  • Which Region is driving the spend?
  • Did the daily trend jump after a deploy, migration, batch job, load test, or logging change?
  • Is the cost steady every day, or did one event create a spike?
  • Is NAT spend growing beside ECR, CloudWatch Logs, S3, DynamoDB, data transfer, or public IPv4 spend?

Do the cheap investigation before the expensive mistake.

How to trace the traffic path

After the billing view tells you NAT matters, map the route.

Check:

  • NAT Gateway IDs, account, Region, and Availability Zone.
  • Route tables for private subnets with 0.0.0.0/0 or other routes pointing at NAT.
  • Which subnets are associated with those route tables.
  • Which EC2, ECS, EKS, Lambda VPC, RDS-adjacent jobs, or batch workloads live in those subnets.
  • Whether high-volume traffic goes to AWS services, internet destinations, partner APIs, package registries, or another VPC path.
  • Whether traffic crosses Availability Zones before it reaches NAT.

CloudWatch NAT Gateway metrics can help separate direction and volume. AWS documents metrics such as bytes in from the source and bytes out to the destination in the AWS/NATGateway namespace. VPC Flow Logs can add packet-level source and destination context, but remember that flow logs create their own storage and analysis cost. Turn on the visibility you need, set retention, and avoid creating a second cost leak while investigating the first one.

Now for the part that keeps this from becoming an outage with a receipt: the route table is production infrastructure. Treat changes to NAT, endpoints, or subnet routing like network changes, not billing cleanup chores.

When VPC endpoints can reduce NAT Gateway cost

VPC endpoints are often the first alternative to review when NAT traffic is mostly going to AWS services.

There are two broad endpoint patterns:

  • Gateway endpoints for supported services such as Amazon S3 and DynamoDB.
  • Interface endpoints, powered by AWS PrivateLink, for many other AWS services.

AWS guidance notes that gateway endpoints for S3 and DynamoDB do not have hourly or data transfer charges, while interface endpoints have their own hourly and data processing charges. That makes the decision more practical than ideological.

Use this review:

  • If traffic is mostly S3 or DynamoDB in the same Region, check whether gateway endpoints fit the route tables and policies.
  • If traffic is ECR image pulls, CloudWatch Logs, Systems Manager, Secrets Manager, SQS, SNS, or another supported AWS service, compare interface endpoint cost against NAT data processing and transfer patterns.
  • If traffic is mostly public internet or third-party APIs, endpoints may not help.
  • If the workload needs strict DNS, endpoint policy, or network controls, validate those before changing routes.
  • If the endpoint path affects security posture, involve the service owner or security owner before implementation.

VPC endpoints are not magic discount buttons. They are network architecture choices with pricing, policy, DNS, and operations attached.

Regional NAT Gateway and availability tradeoffs

AWS announced Regional availability mode for NAT Gateways on November 19, 2025. In that mode, AWS says a single NAT Gateway can expand and contract across Availability Zones in a VPC based on workload presence, simplifying setup compared with manually managing separate zonal gateways.

That is useful to know if you are creating or redesigning NAT today. It does not remove the need to check the bill.

For any NAT design, review:

  • Availability requirements for the workloads.
  • Whether traffic stays in the same Availability Zone when possible.
  • Whether one regional design or multiple zonal resources better matches the workload.
  • How route tables behave when workloads move or expand.
  • Whether cost shifts from hourly gateway count to data processing, transfer, public IPv4, or other services.

The boring controls are the useful ones here: document the chosen design, owner, expected traffic path, and rollback plan.

Safer ways to lower NAT Gateway cost

Start with evidence, not a dramatic architecture rewrite.

Useful first moves:

  • Add an owner to each NAT Gateway and VPC.
  • Record which private subnets route through each gateway.
  • Compare NAT spend by usage type, Region, and daily trend.
  • Identify high-volume AWS service traffic that may fit endpoints.
  • Add S3 or DynamoDB gateway endpoints where the route table and policy model are safe.
  • Compare interface endpoints against actual NAT traffic before adding many of them.
  • Keep NAT resources in Availability Zones that match workload placement when that fits the availability model.
  • Remove truly unused NAT Gateways only after route tables, dependencies, and owners are checked.
  • Add budget or anomaly alerts for recurring NAT growth.

Possible waste becomes confirmed waste only after ownership, dependencies, and rollback are clear.

For non-production accounts, there may be more flexibility to simplify NAT architecture. For production accounts, do not let the delete button make the first speech. Schedule route changes during a change window, monitor after the change, and keep a rollback path.

What not to do

Do not remove NAT Gateways just because the bill is annoying. Private workloads may depend on them for package pulls, container image pulls, software updates, API calls, webhooks, license checks, or deployment steps.

Do not replace every NAT path with interface endpoints without modeling endpoint count, Availability Zones, data processing, DNS behavior, security groups, and endpoint policies.

Do not use one quiet week of traffic as proof that a path is safe to remove. Batch jobs, month-end work, customer imports, security scans, and release windows can change the traffic profile.

Do not ignore cross-AZ routing. A cheap-looking design can create transfer charges or resilience tradeoffs if workloads and gateways are not placed intentionally.

Do not turn on VPC Flow Logs with unlimited retention and then forget about them. The investigation tool can become the next line item.

NAT Gateway cost review checklist

  • Confirm NAT spend is material enough to review.
  • Group Cost Explorer by usage type, Region, account, and day.
  • Separate gateway-hour spend from data-processing spend.
  • Check related public IPv4, data transfer, ECR, CloudWatch Logs, S3, and DynamoDB signals.
  • List NAT Gateways with owner, VPC, subnet, route tables, and Availability Zone.
  • Map private subnet routes and workloads that depend on NAT.
  • Use CloudWatch NAT Gateway metrics to confirm traffic direction and volume.
  • Use VPC Flow Logs only with a retention and analysis plan.
  • Identify traffic that could safely use S3, DynamoDB, or interface endpoints.
  • Compare endpoint cost and operational impact before changing routes.
  • Schedule production routing changes during a change window.
  • Record the decision as accepted cost, needs follow-up, possible waste, or safe to change.

FAQ

Why is AWS NAT Gateway cost high?

AWS NAT Gateway cost can be high because the bill includes both gateway availability and data processed through the gateway. Standard data transfer, cross-AZ traffic, public IPv4, and adjacent services can make the overall networking cost feel larger than the NAT line alone.

How do I check NAT Gateway cost in AWS?

Start in Cost Explorer, filter or group for Amazon VPC-related spend, and group by usage type and Region. Then compare the daily trend so you can tell whether the issue is a steady gateway-hour baseline, a data-processing spike, or a new traffic pattern.

Can VPC endpoints reduce NAT Gateway cost?

Sometimes. Gateway endpoints can be useful for supported S3 and DynamoDB traffic, and interface endpoints can be useful for some high-volume AWS service traffic. Compare current NAT data processing against endpoint pricing, DNS behavior, security policy, and route-table impact before changing anything.

Is it safe to delete an unused NAT Gateway?

Not automatically. A NAT Gateway with little or no current traffic is a review candidate, but you still need to check route tables, private workloads, deployment paths, rollback needs, and owner approval before deleting it.

Should each Availability Zone have its own NAT Gateway?

It depends on availability, traffic volume, and routing design. Per-AZ NAT can reduce some cross-AZ traffic patterns but adds gateway-hour cost. Regional NAT Gateway mode may simplify newer designs, but you should still verify pricing, routing, and resilience requirements for your workload.

Are NAT instances cheaper than NAT Gateways?

NAT instances can look cheaper on a small bill, but they move operational responsibility to your team. You must handle instance sizing, patching, failover, throughput, monitoring, and security. For production, compare cost against the operational risk and maintenance burden, not only the hourly line item.

What is the safest first action for NAT Gateway cost optimization?

Make the cost explainable. Identify the usage type, owner, route tables, dependent workloads, and traffic destination first. The safest first change is often an endpoint, tag, alert, or documented accepted-cost decision rather than deleting a gateway.

Sources

Reader question

When NAT Gateway spend shows up, which is harder for your team to answer: where the traffic is going, or who owns the route path?

Back to top