AWS costs: The NAT gateway bill - the $32/month nobody planned

Short answer: that $32-a-month sticker price is almost never the real bill. A single NAT Gateway costs $0.045 an hour — about $32.85 a month — just to exist, but AWS also charges $0.045 for every gigabyte it processes, on top of standard data transfer charges, and none of that shows up until the invoice does. The counterintuitive part: the fix that saves the most money is usually free. AWS ships a no-cost way to route a large chunk of your traffic around the NAT Gateway entirely, and most accounts have never turned it on.

Jake found out the hard way. He runs a small phone repair shop, and about eight months ago Ethan talked him into moving his ticketing and inventory app off a spare laptop in the back room and onto AWS — an EC2 instance in a private subnet, a small RDS database, backups going to S3 every night. Clean setup, cheap, exactly what a one-location shop needs.

Then one Tuesday his AWS bill was $340 instead of the usual $38. His first thought was that someone had broken in and was mining something with his account. His second thought was to call Ethan and ask what he'd done wrong. Neither was right. The private subnet his EC2 instance lived in couldn't reach S3 without going through a NAT Gateway — a component Ethan had set up correctly, on purpose, months earlier — and a change to the nightly backup job meant it was suddenly pushing four times as much data through that NAT Gateway every night. The hourly charge for the NAT Gateway itself hadn't moved a cent. The data flowing through it had.

Also Read: AWS costs: Data transfer pricing - the map of what is free and what is not

What a NAT Gateway actually charges you for

Start with the plumbing, because the pricing only makes sense once you see the shape of it. A NAT Gateway (Network Address Translation Gateway) is a managed AWS device that sits in a public subnet and lets instances in a private subnet — a subnet with no direct route to the internet — reach the outside world (to download a security patch, call an API, or write a file to S3) without the outside world being able to reach back in and initiate a connection to them. It's the one-way mirror between your private resources and the internet.

AWS bills a NAT Gateway on three separate meters, and almost every surprise bill comes from someone only ever having budgeted for the first one:

Those numbers come straight from AWS's own worked example on the Amazon VPC pricing page: send 1 GB from a private EC2 instance, through a NAT Gateway, out to a non-AWS destination on the internet, and you're charged $0.045 for the hour, $0.045 for the gigabyte processed, and $0.09 for the gigabyte transferred out — three separate line items for one file. AWS calls this out explicitly rather than burying it: the hourly charge and the data processing charge apply "regardless of the traffic's source or destination," and each partial NAT Gateway-hour is billed as a full hour.

Why the bill jumped even though "nothing changed"

This is the question that actually gets typed into a search bar at 11pm: nobody deployed anything new, nobody changed a setting, and the bill still doubled or tripled. Almost every time, one of these three things happened, quietly:

• A workload started talking to an AWS service through the NAT Gateway instead of around it. Traffic to Amazon S3 or DynamoDB from a private subnet still has to leave through the NAT Gateway if there's no VPC endpoint configured for it — even though the data never actually leaves the AWS network. You pay the $0.045/GB processing fee for a trip that AWS could have routed for free.
• A backup, sync, or log-shipping job grew. The hourly charge is fixed; the data processing charge is not. Doubling your nightly backup size doubles that line item, and it compounds with every additional NAT Gateway in the path.
• Traffic started crossing Availability Zones. A NAT Gateway lives in a single Availability Zone (AZ) — one of the physically separate, isolated data center clusters that make up an AWS Region. If an EC2 instance in AZ-b routes through a NAT Gateway sitting in AZ-a, that hop typically adds its own cross-AZ data transfer charge on top of the NAT processing fee, roughly $0.01/GB each way.

None of these show up as an alert. They show up as a bigger number next to "VPC" or "EC2-Other" a month later, and by then the traffic pattern that caused it has usually already happened forty or fifty times.

Do you even need a NAT Gateway running right now?

Before touching anything, work through this in order. It takes about ten minutes and it tells you which of the fixes below actually apply to your situation.

1. Does anything in a private subnet need to reach the general internet? If every private-subnet workload only ever talks to other AWS services (S3, DynamoDB, other APIs inside your VPC), you may not need a NAT Gateway at all — VPC endpoints can cover it, at zero hourly cost.
2. Is the traffic destined for an AWS service that has a Gateway Endpoint? Only Amazon S3 and DynamoDB currently support the free Gateway Endpoint type. If most of your NAT traffic is backups or reads/writes to one of those two services, this is your single highest-value fix — see the next section.
3. Do you have one NAT Gateway per Availability Zone, or one shared across all of them? AWS's own guidance is one NAT Gateway per AZ for resilience, but that means the hourly charge multiplies by however many AZs you're running in — three AZs is three separate $0.045/hour meters running around the clock, three times the base cost before a single byte moves.
4. Is the workload behind the NAT Gateway a dev or staging environment that doesn't need to be up 24/7? A NAT Gateway bills by the hour it's provisioned, not by the hour it's used. A dev VPC's NAT Gateway running unattended over a three-day weekend is billing the full $0.045/hour the entire time.

Jake's answer to question 2 turned out to be "basically all of it." His nightly backup job writes straight to S3. That's the fix that actually moved his bill.

Fix 1 — Route S3 and DynamoDB traffic around the NAT Gateway for free

A VPC endpoint is a private connection between your VPC and an AWS service that doesn't require an internet gateway or a NAT device at all. There are two kinds, and the distinction matters a lot for your wallet: Interface Endpoints (built on AWS PrivateLink) cost $0.01 per hour per Availability Zone plus $0.01 per GB processed, and work for a long list of AWS services. Gateway Endpoints only work for two services — Amazon S3 and Amazon DynamoDB — but AWS's own pricing page states plainly that there is no additional charge for using them: no hourly fee, no per-GB data processing fee. Traffic to S3 or DynamoDB routes through the endpoint using the Amazon network's own prefix list instead of touching the NAT Gateway at all.

1. Open the VPC console and go to Endpoints, then choose "Create endpoint."
2. Pick the service — search for com.amazonaws.<region>.s3 for S3, or the DynamoDB equivalent, and select the "Gateway" endpoint type (not "Interface" — that's the paid one).
3. Select your VPC and choose the route tables used by the private subnets that need S3 or DynamoDB access. AWS automatically adds a route in each selected table pointing S3/DynamoDB-bound traffic at the endpoint instead of the NAT Gateway.
4. Review the endpoint policy (optional but worth doing) to restrict which buckets or tables the endpoint can reach, then create it.
5. Confirm it's working by checking your route table — you should see a route to the S3 prefix list pointing at the new endpoint — then watch next month's NatGateway-Bytes usage type drop.

This is the equivalent CLI command if you'd rather script it than click through the console:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-XXXXXXXX \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-XXXXXXXX

Fix 2 — Stop paying for high availability you didn't ask for

The standard, resilient pattern for a multi-AZ VPC is one NAT Gateway per Availability Zone, so that if one AZ has a problem, the workloads in the others keep working without a cross-AZ dependency. It's the right call for production. It's also three separate $0.045/hour meters running whether or not you're using them — about $98.55 a month in pure hourly charges before a single byte of traffic moves, for a three-AZ setup.

For a lot of small accounts — dev environments, staging, a solo shop's backend — that resilience is being paid for and never used. If your account only ever runs workloads in one AZ, or your dev environment doesn't need to survive an AZ outage, a single NAT Gateway is a legitimate way to cut that fixed cost by two-thirds.

AWS launched a middle option in November 2025 worth knowing about here: a Regional NAT Gateway, which is a single NAT Gateway resource that automatically expands and contracts across whichever AZs your workloads are actually running in, rather than requiring you to manually create and delete one per AZ. It still bills per AZ-hour while it's active in that zone — so a Regional NAT Gateway spanning three AZs for an hour bills the same three NAT Gateway-hours as three separate zonal ones — but it removes the operational overhead of managing separate NAT Gateways and route tables by hand, and it automatically stops billing for an AZ the moment your workload footprint leaves it.

Fix 3 — Stop paying twice for cross-Availability-Zone traffic

If your workloads are spread across AZ-a and AZ-b, but every private subnet routes to the single NAT Gateway sitting in AZ-a's public subnet, every packet from an AZ-b instance now crosses an Availability Zone boundary before it even reaches the NAT Gateway, and crosses back afterward. That's a separate cross-AZ data transfer charge (roughly $0.01/GB each direction) stacked on top of the NAT Gateway's own $0.045/GB processing fee — for traffic that could have avoided the cross-AZ hop entirely with a NAT Gateway placed in each zone.

The fix here isn't glamorous: run one NAT Gateway per AZ your workloads actually use, and route each private subnet's traffic to the NAT Gateway that lives in the same AZ. It costs more in fixed hourly charges (see Fix 2's trade-off in reverse) but it can cost less overall once you account for the cross-AZ transfer fees you were paying to avoid it. There's no universal right answer — it genuinely depends on whether your bottleneck is the fixed hourly cost or the variable data cost, which is exactly what the Cost Explorer steps further down will tell you.

Fix 4 — Trade the managed NAT Gateway for a self-run NAT instance

Before there was a managed NAT Gateway service, people ran a plain EC2 instance configured to do the same job — a NAT instance. That option never went away. A NAT instance is just an EC2 VM you own and manage, running network address translation software, with the source/destination check disabled on its network interface so it can forward traffic on behalf of other instances. You pay for the EC2 instance and standard data transfer — there's no separate $0.045/GB processing fee layered on top, because that fee belongs specifically to the managed NAT Gateway product.

This is where a popular piece of internet advice needs a correction: "just switch to a NAT instance, it's basically free" oversimplifies what you're taking on. Ethan put it bluntly when Jake asked why he hadn't just done this from day one: "It's not free — it's a different bill with your name on it instead of AWS's, and you're the one who gets paged if it goes down at 2am." A NAT instance is not managed — you patch it, you monitor it, and if it goes down, so does outbound internet access for everything behind it, with no automatic failover unless you build one yourself. It's a legitimate trade for a workload with predictable, moderate traffic and someone willing to own the operational risk. It is not a like-for-like swap for a production system that needs to just work.

A number of open-source projects package a NAT instance with automated failover to try to close the gap — watching for a health-check failure and re-pointing route tables to a standby instance in another AZ. That closes part of the operational gap, but it's still your infrastructure to maintain, monitor, and patch; it's a trade, not a free upgrade.

Fix 5 — Skip NAT entirely for IPv6-only outbound traffic

A NAT Gateway solves a problem that's specific to IPv4: there aren't enough public IPv4 addresses to give one to every private instance, so instances share the NAT Gateway's address instead. IPv6 doesn't have that scarcity problem — every instance can have its own globally routable address — so if a workload can talk IPv6-only, it can use an egress-only internet gateway instead, which allows outbound IPv6 traffic and blocks unsolicited inbound connections, at no hourly or per-GB charge. This only works if the destination service also supports IPv6, and won't help traffic that still needs to reach IPv4-only endpoints — but for workloads that qualify, it removes the NAT Gateway bill for that traffic entirely, not just reduces it.

Edge cases — containers, Lambda, and multi-account networks

Everything above assumes a simple picture: one VPC, one or two private subnets, one workload. Real accounts get messier, and each of the common variations changes the math slightly.

• ECS and Fargate tasks in private subnets behave exactly like EC2 instances for NAT purposes — every image pull, API call, and outbound request from the task routes through the NAT Gateway unless a VPC endpoint or a public IP on the task covers it. A task definition change that adds a new external dependency can quietly move a lot of traffic overnight.
• EKS worker nodes commonly pull container images, call the Kubernetes API, and talk to other AWS services constantly. Because image layers can be large and frequent, this is one of the most common places teams find their NAT Gateway data processing charge is actually an ECR (Elastic Container Registry) pull problem in disguise — worth checking for an ECR-specific Interface Endpoint if node traffic is heavy.
• Lambda functions attached to a VPC only need that attachment if the function must reach something that's only reachable from inside the VPC, such as an RDS database sitting in a private subnet. If a function's only outbound need is other AWS services or the general internet, keeping it outside a custom VPC sidesteps the NAT Gateway question for that function entirely. If it does need VPC placement, the same Gateway and Interface Endpoint options from Fix 1 apply to it.
• Multi-account and multi-VPC setups sometimes centralize outbound internet access through a shared NAT Gateway in a dedicated networking account, reached over Transit Gateway or VPC peering from each application VPC — a pattern usually called centralized egress. It's efficient at scale, but it means cross-VPC and cross-account data transfer charges stack on top of the usual NAT charges, and the bill for all of it can land in an account that isn't the one generating the traffic. If your organization uses this pattern, the Cost Explorer steps further down need to be run against the networking account, not the application account, or you'll be looking at the wrong invoice entirely.
• On-premises networks connected over VPN or Direct Connect cannot use a Gateway Endpoint — AWS's own documentation is explicit that gateway-type endpoints don't accept connections from outside the VPC, including from peered VPCs in other Regions or over a Transit Gateway. For that traffic pattern, an Interface Endpoint (the paid PrivateLink kind) is the only VPC-endpoint option; it still beats routing everything through NAT for high-volume AWS-service traffic, but it isn't free the way the S3/DynamoDB Gateway Endpoint is.

The security side of routing everything through one gateway

Cost isn't the only reason to care about what's actually flowing through your NAT Gateway. Because every byte from your private subnets funnels through one or a few known points, that same chokepoint is also your best vantage point for watching what's leaving your network — and for locking it down.

Two things worth doing at the same time you're doing the cost audit:

• Attach an endpoint policy to any Gateway Endpoint you create. By default a new S3 or DynamoDB Gateway Endpoint can reach any bucket or table in the Region. A policy that restricts it to the specific buckets your application actually uses turns a general-purpose door into a specific one, which matters if an instance is ever compromised — the blast radius of what it can reach through that endpoint is smaller.
• Turn on VPC Flow Logs on the subnets or ENIs feeding your NAT Gateway, if they aren't already. The same logs that tell a FinOps team which destination IP ranges are driving the data processing charge also tell a security team whether a private-subnet instance is talking to something it has no business talking to. You're already looking at this data for the cost investigation below — it's worth a second look with that lens on.

None of this replaces a dedicated network security tool if your traffic and compliance needs call for one, but for a small setup like Jake's, it's a meaningful amount of visibility for no extra spend.

Finding exactly what's driving your NAT Gateway bill

Every fix above is wasted effort if you apply it to the wrong problem. A NAT Gateway with a high bill driven mostly by the hourly charge needs a consolidation fix (Fix 2). One driven mostly by data processing needs an endpoint or traffic-pattern fix (Fix 1 or Fix 3). Telling the two apart takes five minutes in Cost Explorer.

1. Open AWS Cost Explorer from the Billing and Cost Management console, and set the date range to the past 1–3 months with daily granularity.
2. Group by Usage Type and filter the service to EC2-Other, where NAT Gateway line items are billed.
3. Isolate the hourly charge by filtering Usage Type to NatGateway-Hours — this tells you your fixed floor, driven purely by how many NAT Gateways exist and for how long.
4. Isolate the data charge by switching the filter to NatGateway-Bytes — this is your variable cost, driven by traffic volume, and on a busy account it's usually the larger of the two.
5. Group the bytes filter by Region, then by linked account, if you manage more than one, to narrow down which environment is actually generating the volume before you go looking at flow logs.

If the bytes number is the one that's climbing, VPC Flow Logs can tell you the destination IP ranges responsible, which will usually point straight at an AWS service's public IP range (a sign you're missing a VPC endpoint) or at a specific external API your application calls constantly.

Automate the alert so this doesn't surprise you again

Finding a runaway NAT Gateway bill once is a fire drill. Finding it every time is a process. Two AWS-native tools cover this, and neither one costs anything extra to turn on for a small account.

1. Turn on AWS Cost Anomaly Detection. In the Billing and Cost Management console, go to Cost Anomaly Detection and create a monitor of type "AWS services." It uses machine learning to establish your normal spending pattern and flags deviations from it automatically — AWS provides this monitoring at no charge; you're only billed for the notifications it sends (email or SNS), which fall well within the free tier for a small account.
2. Set up an alert subscription on that monitor so a spike gets emailed to you the same day it starts, not a month later when the invoice arrives.
3. Add an AWS Budget as a second layer with a fixed monthly threshold for your VPC or networking costs. Monitoring and notifications on a budget are free; only "budget actions" that automatically respond to a breach (like disabling a resource) carry a small daily charge.
4. Revisit the Cost Explorer usage-type breakdown from the previous section monthly, even if nothing alerted — a slow, steady creep in NatGateway-Bytes is exactly the kind of change that a percentage-based anomaly detector can miss if it happens gradually enough.

This is the step Jake skipped the first time, and the one Ethan made him set up right after they fixed the $340 bill. It wouldn't have prevented the spike, but it would have caught it on day two instead of at the end of the billing cycle.

When a NAT Gateway is still the right call

Frequently asked questions

Why is my NAT Gateway bill so much higher than $32/month?

Because $32.85 is only the fixed hourly charge for one NAT Gateway existing. AWS also charges $0.045 for every gigabyte the gateway processes, plus standard data transfer charges for anything that leaves AWS. On any account with real traffic, those two variable charges usually add up to more than the hourly base fee.

What exactly does a NAT Gateway charge you for?

Three separate things: an hourly charge for the gateway being provisioned and available ($0.045/hour), a data processing charge for every gigabyte that passes through it ($0.045/GB), and the standard AWS data transfer charge for any of that traffic that leaves the AWS network (up to $0.09/GB to the internet). All three can appear on the same gigabyte of traffic.

Is the $32/month charge per NAT Gateway or per VPC?

Per NAT Gateway. If you're running one per Availability Zone across three zones, the pattern AWS recommends for resilience, that's three separate $0.045/hour meters running around the clock, roughly $98.55/month in hourly charges alone before any data moves.

Can I avoid the NAT Gateway hourly charge entirely?

Yes, by deleting any NAT Gateway you don't need, or by not creating one at all for workloads that only talk to AWS services with a free Gateway Endpoint. If any private-subnet workload genuinely needs general internet access, something has to provide that path, and a NAT Gateway, a NAT instance, or a proxy will each carry some cost.

Does deleting my NAT Gateway break my private instances' internet access?

Yes, immediately, for any traffic that was routing through it, unless that traffic is destined for S3 or DynamoDB and you've already added a Gateway Endpoint, or it's IPv6 traffic covered by an egress-only internet gateway. Confirm what's actually using the NAT Gateway with Cost Explorer or Flow Logs before deleting it.

Do VPC Gateway Endpoints really cost nothing?

For Amazon S3 and DynamoDB specifically, yes, AWS's own pricing page states there is no additional charge for using Gateway Endpoints, no hourly fee and no per-GB data processing fee. This only applies to the Gateway Endpoint type, not to Interface Endpoints, which do carry an hourly and per-GB charge and cover a much longer list of services.

Will a NAT instance actually save me money?

Usually on the per-GB side, since a NAT instance you run yourself doesn't carry the managed NAT Gateway's $0.045/GB data processing fee, you just pay for the EC2 instance and standard data transfer. It shifts operational responsibility such as patching, monitoring, and failover onto you, so the savings come with real trade-offs, not just a smaller number on the invoice.

What is fck-nat and is it safe to use in production?

It's one of several open-source projects that package a NAT instance with automated failover, aiming to close the reliability gap between a self-managed NAT instance and the managed NAT Gateway service. It can be a reasonable production option for teams comfortable owning that infrastructure, but it's still self-managed and doesn't carry AWS's own availability guarantees.

Why do I have three NAT Gateways in my account?

Most likely because your VPC spans three Availability Zones and you, or a template or module you deployed, created one NAT Gateway per AZ, which is AWS's recommended pattern for resilience. Check whether all three zones are actually in use by your workloads, since an unused AZ's NAT Gateway is pure fixed cost with no benefit.

Does a Regional NAT Gateway cost less than three zonal ones?

Not automatically. A Regional NAT Gateway still bills $0.045 per Availability Zone per hour it's actively expanded into that zone, the same per-AZ-hour rate as separate zonal NAT Gateways. What it removes is the manual work of creating, deleting, and re-routing individual NAT Gateways as workloads move between zones, and it automatically stops billing for a zone your workload has left.

How do I find which usage type is driving my NAT Gateway bill?

In AWS Cost Explorer, group by Usage Type and filter to EC2-Other, then look at NatGateway-Hours and NatGateway-Bytes separately. Whichever one is larger and growing tells you whether your problem is too many or too-long-running NAT Gateways, or too much traffic through them.

Does traffic to S3 always go through my NAT Gateway?

Only if there's no Gateway VPC Endpoint configured for S3 in that VPC's route tables. Without one, private-subnet traffic to S3 routes out through the NAT Gateway and back in, incurring the $0.045/GB data processing charge even though the traffic technically never leaves the AWS network. Adding the endpoint removes that charge for S3 traffic entirely.

What happens to my NAT Gateway bill if I switch a workload to IPv6-only?

If the workload and its destinations both support IPv6, you can route that traffic through an egress-only internet gateway instead of a NAT Gateway, at no hourly or per-GB charge. This only removes the charge for the traffic that's genuinely IPv6-capable end to end; anything still requiring IPv4 destinations still needs a NAT path.

Is Public IPv4 pricing part of my NAT Gateway bill?

It's a separate line item, but it often shows up in the same VPC-related section of the bill. Since February 1, 2024, AWS has charged $0.005 per hour for every public IPv4 address in use, including the one attached to your NAT Gateway, whether or not it's actively passing traffic. It's a small charge on its own but worth knowing it's not part of the $0.045/hour NAT Gateway rate — it's additional.

Can Lambda functions in a VPC avoid NAT Gateway charges?

A Lambda function only needs to be placed inside a VPC if it must reach a resource that's only accessible from inside that VPC, such as an RDS database in a private subnet. If a function's only outbound need is other AWS services or the public internet, keeping it outside a custom VPC avoids the NAT Gateway question for that function entirely. If it does need VPC placement, the same Gateway Endpoint and Interface Endpoint options apply to it as to any other private-subnet resource.

Should a small business or solo developer ever use a NAT Gateway at all?

Often yes, for the same reason Jake did — it's the standard, low-effort way to give a private-subnet backend controlled internet access without managing your own NAT infrastructure. The mistake isn't using one; it's never checking whether a free Gateway Endpoint could take over part of the traffic, or whether the account is still paying for more Availability Zones of redundancy than the workload actually needs.

Also Read:

AWS costs: The NAT gateway bill - the $32/month nobody planned

 AWS costs: Data transfer pricing - the map of what is free and what is not

 AWS costs: CloudWatch Logs ingestion - the log bill that outgrew the app

 AWS costs: Cross-AZ traffic - the invisible cent per gigabyte

 AWS costs: Unattached Elastic IPs and idle load balancers - the standing waste list

AWS costs: S3 request pricing - when storage is cheap but touching it is not

AWS costs: S3 storage classes decided honestly - IA, Glacier, Intelligent-Tiering

AWS costs: Glacier retrieval - the bill for wanting your data back

Revision note. Written September 2026, covering current NAT Gateway, Gateway Endpoint, and PrivateLink pricing in US East (N. Virginia), including the Regional NAT Gateway availability mode released November 2025 and Public IPv4 address pricing in effect since February 2024. Rates vary by region and AWS updates pricing pages periodically, so check the current numbers on your own bill before budgeting off any figure here. If you're staring at a bill you didn't see coming, you're not the first person this has happened to, and it's fixable — take it one line item at a time.Happy learning!