NAT Gateway is the most over-paid resource on AWS, because almost nobody reads the second half of the pricing page. You pay an hourly charge per gateway AND ~$0.045 for every gigabyte that passes through it — and your private subnets push far more through it than you think. Here is exactly how it is priced, how to find your number in Cost Explorer and VPC Flow Logs, and the four fixes that typically cut it 60–95%.
Every cost-optimization engagement turns up the same surprise: a NAT Gateway line item far larger than anyone budgeted for, that nobody can immediately explain. It is the textbook silent cost trap — invisible by default, scales with traffic you never see, and feels like infrastructure plumbing rather than a metered service.
NAT Gateway exists to give private-subnet resources outbound internet access — packages, third-party APIs, container images, AWS service endpoints — without letting the public internet route back in. It is the correct, secure default, which is exactly why it is everywhere: the VPC console wizard, the Well-Architected guidance, and virtually every Terraform module spin one up per Availability Zone, and nobody questions it because removing it would break outbound connectivity.
The trap is the billing model. NAT Gateway is not flat-rate plumbing — it is a metered data-processing service. You pay twice: for the hours the gateway exists, and for every gigabyte it processes in both directions. The hourly charge is small and predictable; the per-gigabyte charge is neither, and it is what turns a "$30 networking component" into a four-figure monthly surprise. It compounds because the traffic is invisible — a private-subnet task does not announce that it just pulled a 1.2 GB image from ECR, or that your app reads 8 TB a month from S3 over NAT instead of a free Gateway endpoint. It all collapses into one aggregated NAT data-processing number on the bill, 30 days later, with no breakdown.
And it sits on the wrong side of attention. Teams obsess over EC2 instance sizes and forget that the NAT Gateway those instances talk through charges $0.045 per GB on top of any data-transfer cost. On a bill where EC2 is the headline, NAT Gateway is frequently the second- or third-largest line and the single highest-margin thing you can cut — because cutting it requires zero compromise on performance, availability, or security. You are not trading anything away; you are just stopping traffic from taking the expensive path.
There are exactly two charges, added together on your bill, and understanding the split is the whole game. One is fixed and harmless; the other is variable and is where essentially all the money goes. Treat the numbers below as representative 2026 US-Region pricing — always confirm the current per-Region rate on the AWS VPC pricing page.
The critical nuance — the part that catches even experienced engineers — is that the data-processing charge is completely separate from, and stacks on top of, normal AWS data-transfer charges. Send data to the internet through a NAT Gateway and you pay (a) ~$0.045/GB NAT data processing PLUS (b) the standard internet egress rate (~$0.09/GB at the first tier, lower at volume). For cross-AZ traffic you can pay NAT data processing plus a cross-AZ transfer charge. The NAT charge is rarely the only cost on a byte — it is the surcharge you forgot about, layered on top of the cost you already knew.
Two design decisions multiply this. High availability: one NAT Gateway per AZ is correct for resilience but means a three-AZ deployment has three hourly charges and three independent data-processing meters. And cross-AZ routing mistakes — a subnet in AZ-a routed to a NAT Gateway in AZ-b — make every byte pay NAT data processing AND a cross-AZ transfer charge, on the slow path, for no benefit. For budgeting, the hourly fee is a rounding error; the data-processing fee, driven by traffic volume you cannot see, is the entire story — and the highest-leverage move is finding which traffic takes the NAT path and rerouting the cheap-or-free portion off it entirely.
You pay ~$0.045/GB for every byte through a NAT Gateway, on top of any data-transfer cost that byte already incurs — so the goal is never "make NAT cheaper," it is "stop sending bytes through NAT that do not need to be there." Most of those bytes are AWS-to-AWS traffic (S3, DynamoDB, ECR, other APIs) that a VPC endpoint reroutes for free or near-free.
NAT data-processing charges are an aggregate; to cut them you have to know what generates the volume. In nearly every audit the culprits are the same handful of patterns — most of them AWS-to-AWS traffic that never needed the public internet path. When a partner attributes NAT traffic to destinations via Flow Logs, the breakdown is remarkably consistent across companies. The biggest contributors, roughly in order of how often they dominate:
The pattern is the headline: the overwhelming majority of NAT data-processing spend is AWS-to-AWS traffic — bytes going from your VPC to another AWS service in the same Region, routing out through NAT and back in for no reason. AWS gives you VPC endpoints precisely to keep that traffic on its private network. Genuinely-internet-bound traffic (third-party APIs, external SaaS, webhooks) is usually the minority of the bill — and the part you cannot reroute, only optimize.
Before you change anything, you need two numbers: how much you spend on NAT Gateway, and what traffic generates it. Cost Explorer answers the first in five minutes; VPC Flow Logs answer the second and tell you exactly which endpoints to deploy.
Open Cost Explorer, set monthly granularity over the last 3–6 months, filter to the EC2-Other usage type group, and group by Usage Type. NAT Gateway appears as two usage types: NatGateway-Hours (hourly) and NatGateway-Bytes (data processing). The Bytes line is the one to watch.
Read the ratio. If NatGateway-Bytes dwarfs NatGateway-Hours — which it almost always does — your problem is traffic volume, not gateway count, and VPC endpoints are your lever. If both are comparable and small, you may just have idle gateways in unused AZs or dev VPCs to delete. Group by Cost Allocation Tag or linked account to see which team/VPC owns the spend, and set a Cost Anomaly Detection monitor or Budget alert on EC2-Other so the next spike is flagged — one new chatty workload can move this 30% overnight.
Cost Explorer gives the total, not the cause. For that, enable VPC Flow Logs on the VPC or subnets (publish to CloudWatch Logs or, cheaper to analyze, to S3). The trick is to filter to flows whose destination is the NAT Gateway's elastic network interface, then aggregate bytes by destination address and port.
Querying Flow Logs in S3 with Amazon Athena is the standard move: a single GROUP BY on destination and port, ordered by total bytes descending, ranks exactly which destinations are eating your NAT budget. AWS publishes per-service IP ranges, so you can map the top talkers back to S3, ECR, DynamoDB, or an external API. That ranked list is your remediation backlog — each AWS service at the top is a VPC endpoint to deploy. The output is a sentence you can act on ("We spend $X/mo on NAT; 71% is S3 + ECR + DynamoDB, all of which have endpoints"), and it is exactly the artifact a CloudRoute partner produces on day one of a cost audit.
Once you know what is on the NAT path, the fixes are mechanical and low-risk: reroute AWS traffic off NAT (the big wins), fix misconfiguration (free wins), and right-size or replace the gateway (situational). They are ordered below by return — the first alone frequently removes the majority of the spend.
S3 and DynamoDB are reachable via Gateway VPC endpoints, which are completely free — no hourly or per-GB charge. Add the endpoint to the VPC, attach it to your private subnets' route tables, and their traffic immediately travels the AWS private network instead of the NAT path, dropping the NAT charge for it to zero. This is the single highest-leverage change in AWS networking cost: no downside, no performance cost (usually faster), no security tradeoff (lock it with a policy). If your Flow Logs show meaningful S3 or DynamoDB volume on NAT — and they almost always do — this one change can remove 40–70% of the data-processing bill on its own, for $0.
Most other AWS services (ECR, CloudWatch Logs, Secrets Manager, SSM, STS, SQS, KMS, and more) are reachable via interface endpoints (AWS PrivateLink). These are not free: each carries an hourly charge (~$0.01/hr per endpoint per AZ, roughly $7–$8/mo per AZ) plus a small per-GB fee (~$0.01/GB). But that per-GB rate is about a quarter of the NAT rate, so any service moving real volume is cheaper on an interface endpoint than on NAT.
The economics: an interface endpoint covers its hourly cost once it moves modest traffic, after which every gigabyte is ~$0.01 instead of ~$0.045. ECR is usually a clear win — note it needs both the ECR API interface endpoints and the S3 Gateway endpoint (image layers live in S3). Be selective: add endpoints for the high-volume services in your Flow Logs ranking and skip the long tail where the fixed hourly cost would exceed the NAT savings.
Audit route tables for the classic cross-AZ error: a subnet in one AZ pointing at a NAT Gateway in another, so every byte pays NAT data processing AND a cross-AZ transfer charge. Repointing each subnet to the gateway in its own AZ is a free fix that removes the surcharge and keeps traffic local.
AZ consolidation is the nuanced version. Each gateway is ~$32–$33/mo fixed, so a non-production VPC across three AZs pays ~$97/mo for resilience dev does not need. Collapsing dev/staging to one NAT Gateway is a legitimate saving — but only where you accept that an AZ outage takes the environment down. Never collapse production AZs to save NAT hours; the hourly fee is trivial next to the availability. A dev/test lever, not a production one.
For low-traffic, non-critical environments, a self-managed NAT instance (a small EC2 instance acting as a NAT, ideally Graviton/ARM) sidesteps the per-GB charge entirely — you pay only for the instance and normal data transfer. A t4g.micro can route modest dev traffic for a few dollars a month, far less than a managed gateway on the same volume. The tradeoffs are real: you own patching, it is a single point of failure unless you build HA yourself, and bandwidth does not scale automatically. It belongs in dev/test or genuinely low-traffic workloads, never as a casual production replacement.
The deepest lever is architectural: does this traffic need to leave the VPC at all? Caching dependencies in a private artifact repo or pull-through cache instead of re-pulling from the internet on every build, co-locating chatty services in one AZ, or replacing a polling integration with an event-driven one — these reduce the volume itself rather than rerouting it. Higher-effort, but they attack the root cause, and are exactly the kind of change a Well-Architected review surfaces.
Numbers make this concrete. Representative mid-stage startup VPC: three NAT Gateways (one per AZ) for HA, private subnets processing 30 TB/month through NAT — roughly 14 TB S3, 6 TB ECR image pulls, 4 TB DynamoDB, 3 TB other AWS API/telemetry, and 3 TB genuinely internet-bound to external APIs. Figures use representative 2026 US-Region rates; your Region and mix move the absolute numbers but rarely the shape.
Tally it up. NAT data processing falls from ~$1,350/mo to ~$135/mo. Add ~$90/mo of interface-endpoint data processing and ~$135/mo of interface-endpoint hourly fees, and the new all-in cost for this traffic is roughly $360/mo against the original $1,350 — about $990/mo, roughly $11,900/year, saved by deploying endpoints, with no change to availability, performance, or security. The free Gateway endpoints alone delivered the bulk of it.
This is why NAT Gateway is the first thing a competent cost audit checks: low-risk fix, immediate and recurring return, and the dominant lever (S3 + DynamoDB Gateway endpoints) costs nothing to pull. Scale these percentages up and the same shape of fix on a $10K/mo NAT line returns five figures a month.
Everything above is doable in-house if you have the time and VPC expertise to read Flow Logs, map destinations to services, and deploy and test endpoints without breaking connectivity. Most teams with a surprising bill do not. That is the gap CloudRoute closes.
CloudRoute routes you to a vetted AWS partner who runs the full loop: a cost audit quantifying your NAT spend in Cost Explorer, a Flow Logs analysis attributing it to specific services, then the remediation — deploying the Gateway and interface endpoints, correcting route-table and AZ mistakes, and validating that nothing breaks. You get the savings without spending your own cycles on the intricacies of PrivateLink pricing.
The part that makes this nearly free: AWS funds partner-led cost-optimization and Well-Architected work for qualifying engagements. A Well-Architected Review (its cost-optimization pillar covers exactly this NAT/endpoint pattern) can unlock AWS remediation credits, and AWS pays the partner through its funding programs — so for credit-eligible engagements you frequently cut the bill for $0. Honest framing: AWS-funding applies to qualifying engagements; where it does not, this is a vetted-partner referral that pays for itself in the first month, since the recurring NAT savings typically dwarf any one-time fee.
And it does not stop at NAT. The same audit surfaces the adjacent wins — broader data-transfer waste, idle resources, right-sizing, commitment coverage (Savings Plans / Reserved Instances), storage-class and EBS cleanup — so an engagement that started with "why is my NAT bill so high?" usually returns more than the NAT line alone.
For qualifying, credit-eligible engagements, AWS funds the partner and a Well-Architected Review can unlock remediation credits — so you cut your bill for $0. For everything else, it is a vetted-partner referral whose recurring savings pay for the work, fast. Either way, CloudRoute is paid by the partner, not by you.
These three approaches solve overlapping problems and you will usually run a combination, not pick one. The point is to route each kind of traffic to its cheapest correct path: AWS-to-AWS traffic onto VPC endpoints, genuinely-internet-bound traffic onto NAT, and low-traffic dev onto a NAT instance if it pencils out. Rates are representative 2026 US-Region figures — verify current per-Region pricing.
| Dimension | NAT Gateway (managed) | VPC endpoints (Gateway / Interface) | NAT instance (self-managed) |
|---|---|---|---|
| What it is for | Outbound internet access for private subnets | Private, direct path to specific AWS services (S3, DynamoDB, ECR, etc.) | DIY outbound internet via a small EC2 instance acting as NAT |
| Hourly cost | ~$0.045/hr (~$32–$33/mo) per gateway, per AZ | Gateway endpoints: $0. Interface: ~$0.01/hr (~$7–$8/mo) per endpoint, per AZ | Cost of the EC2 instance (e.g. t4g.micro ≈ a few $/mo) |
| Data-processing cost | ~$0.045/GB, every byte, both directions | Gateway: $0/GB. Interface: ~$0.01/GB | None beyond normal data-transfer charges |
| Reaches the public internet? | Yes — its core job | No — AWS services only | Yes |
| Reaches AWS services cheaply? | No — charges $0.045/GB to reach them | Yes — that is the entire point | No — same internet path, just self-run |
| High availability | Managed, AZ-resilient (one per AZ) | Managed, highly available | You build HA yourself; single point of failure by default |
| Bandwidth scaling | Automatic, up to tens of Gbps | Managed, scales with the service | Limited by instance size/NIC; you manage it |
| Operational burden | None — fully managed | None — fully managed | You patch, monitor, and scale it |
| Best for | Genuinely internet-bound traffic to third parties / external APIs | All AWS-to-AWS traffic (S3, DynamoDB, ECR, CloudWatch, Secrets Manager…) | Low-traffic dev/test where per-GB NAT fees would dominate |
Situation: The AWS bill had crept from ~$6K to ~$9K/month in two quarters with no obvious driver — Cost Explorer just showed a large, growing EC2-Other line nobody could explain. The lead engineer suspected data transfer but had no time to dig through Flow Logs while shipping. NAT Gateway data processing turned out to be ~$2,400/month — about 27% of the bill — driven by an analytics pipeline reading data lakes from S3 and pulling large container images from ECR on every autoscaling event, all routing through NAT across three AZs.
What CloudRoute did: CloudRoute matched them within 20 hours to an EU-Central partner with a Well-Architected cost-optimization track record. Day 1: partner pulled Cost Explorer + Athena-queried Flow Logs and attributed 81% of NAT data processing to S3, ECR, and DynamoDB. Day 2–3: deployed free Gateway endpoints for S3 + DynamoDB, interface endpoints for ECR and CloudWatch, and fixed two subnets routed cross-AZ to the wrong gateway — validating connectivity in staging before cutting production route tables. Filed as an AWS-funded Well-Architected remediation.
Outcome: NAT Gateway data processing dropped from ~$2,400/mo to ~$290/mo — an 88% cut, ~$25,300/year recurring — with zero change to availability or performance. The review also flagged unattached EBS volumes and uncommitted compute, adding ~$1,100/mo more savings the team actioned next. The engagement was AWS-funded; the customer paid $0, and CloudRoute was paid by the partner.
time-to-match: <24h · audit-to-fix: 3 days · NAT spend cut: 88% (~$25.3K/yr) · cost to customer: $0
CloudRoute matches you with a vetted AWS partner who audits your NAT spend, deploys the endpoints, and fixes the route tables. Often AWS-funded — you frequently cut the bill for $0. Otherwise the savings pay for the work in the first month.