AWS NAT Gateway: what it actually costs, and the alternatives

An AWS NAT Gateway is the kind of line item nobody puts in the first budget. It looks like plumbing, it costs a few cents an hour, and then a bill review three months later finds it quietly running up a number that has nothing to do with the work your servers were doing. This is a look at where that money actually goes, and the honest set of alternatives, including the cases where the plain NAT Gateway is the right call and you should leave it alone.

Full disclosure before we start: I work on Enforza, which is one of the alternatives further down. It gets one section, late, alongside the others, and I have tried to be fair about where it is not the answer. If you want the mechanics of NAT itself first, how NAT gateways work covers the address-translation side; this article is about the bill.

The two charges on a NAT Gateway bill

A managed NAT Gateway bills two ways, and only one of them is the one people expect:

• $0.045 per gateway-hour. The fixed cost of the gateway existing, about $33 a month if it runs all month.
• $0.045 per GB processed. The data-processing charge, on every byte that passes through, in or out, regardless of where it was going.

Rates are us-east-1, dated 2026-06-14, directional and subject to change; they vary a little by region. The hourly charge is the one you notice at provisioning time and then forget. The per-GB charge is the one that grows with your business, and it is billed on volume, not on value. The gateway does not know or care whether a byte was a critical API call or a container pulling the same base image for the thousandth time. It is $0.045 either way.

A worked example, deliberately modest. One NAT Gateway, running the full 730 hours in a month, with 5 TB of egress behind it:

• Gateway-hours: $0.045 × 730 = about $33
• Data processing: $0.045 × 5,000 GB = $225
• Monthly total: about $258, for connectivity only

That $258 buys you exactly nothing except the ability for private subnets to reach the internet. No filtering, no policy, no record of what left. And 5 TB is not a large estate. Double the traffic and you have doubled the larger of the two lines, because it scales linearly and never stops.

Where the bill actually surprises people

The headline rates are not the surprise. These three are.

It multiplies per Availability Zone. AWS’s own guidance is one NAT Gateway per AZ, and for good reason: a gateway lives in a single zone, so a single shared gateway is both a single point of failure and a source of cross-AZ data-transfer charges (roughly $0.01/GB each way, directional) for every workload in the other zones. Do the resilient thing across three AZs and you are now paying three lots of the hourly charge, about $99/month, before a single byte moves. Try to save that by centralising to one AZ and you pick up the cross-AZ transfer fee on all the traffic from the other zones instead. It is a genuine trade-off, not a free lunch either way.

The per-GB charge applies to traffic that never needed the internet. A large share of what many workloads send out is not going to the internet at all. It is going to AWS services: S3, ECR, CloudWatch, Systems Manager, Secrets Manager, DynamoDB. If that traffic routes through the NAT Gateway, you are paying $0.045/GB to reach a service that is sitting inside AWS the whole time. This is the single most common source of a NAT bill that looks too high for the amount of real internet traffic, and it is also the most fixable. More on that in the next section.

There is no off switch. A managed NAT Gateway cannot be paused when idle the way an instance can be stopped. The hourly charge runs whether traffic is flowing or not, so a forgotten gateway in a dev account is a small standing charge that nobody is watching. Not a disaster, but it adds up across accounts.

VPC endpoints: take AWS-service traffic off NAT entirely

If a meaningful fraction of your egress is to AWS services, the cheapest thing you can do is stop sending it through the NAT Gateway at all. That is what VPC endpoints are for, and there are two kinds with very different economics.

Gateway endpoints for S3 and DynamoDB are free. No hourly charge, no per-GB charge. You add a gateway endpoint, point the route at it, and traffic to S3 or DynamoDB leaves the NAT path entirely. If your workloads move a lot of objects to and from S3, this one change can take a large bite out of the per-GB line for nothing. There is no reason not to do it.

Interface endpoints (PrivateLink) are cheap but not free. For the other AWS services (ECR, CloudWatch, SSM, Secrets Manager and the rest) you use interface endpoints, which cost roughly $0.01 per hour per endpoint per AZ plus about $0.01/GB (AWS PrivateLink pricing, us-east-1, checked 2026-07-31, directional). That per-GB rate is well under the NAT Gateway’s $0.045/GB, so for heavy service traffic it wins clearly. The honest catch is that you pay per endpoint per AZ, so a dozen services across three zones is a standing hourly cost of its own. Endpoints pay off when the traffic through them is high relative to the number of endpoints, and they do nothing for traffic to the general internet, which still needs a NAT path.

The practical read: gateway endpoints for S3 and DynamoDB are close to free money, add them. Interface endpoints are worth it for the busy services and not worth it for the quiet ones. Neither removes the need for a NAT path for genuine internet egress; they shrink how much goes through it.

NAT instances and fck-nat: cheaper, if you want the ops

The oldest alternative is to run NAT yourself. A NAT instance is a NAT AMI on an EC2 VM: you pay for the instance and for normal data-transfer-out, and there is no $0.045/GB processing fee, because the processing is just your own box forwarding packets. For a lot of workloads that is a real saving.

The well-made modern version of this is fck-nat, an open-source NAT instance with a current ARM/Graviton image, a clean Terraform module and a responsive maintainer. If what you need is cheap outbound connectivity for dev or for prod that can tolerate a brief blip, it is genuinely good and I would point you to it before I pitched anything.

The trade-offs are real and worth stating plainly:

• High availability is on you. A single NAT instance is a single point of failure. The documented HA pattern is active-passive with a health check that swaps a route on failure, which severs in-flight connections and takes a few seconds to reconverge. That is fine for a lot of workloads and not fine for some.
• Patching and lifecycle are on you. It is an EC2 VM. It needs an OS, updates, and an eye on the AMI as base images get deprecated.
• It is plain source NAT and nothing else. No egress filtering, no FQDN or hostname rules, no audit log of what left. If you later need to control egress, you are adding another box.
• It sits in a public subnet with a public path. That is attack surface on the box that is carrying all your outbound traffic, and it is your job to lock it down.

None of that is a reason to avoid a NAT instance. It is a reason to be clear-eyed that “cheaper” here means “cheaper plus operational work.” For a homelab or a small estate that is a fine deal. For a fleet across accounts it is a lot of boxes to babysit.

When a plain NAT Gateway is simply the right answer

It is worth saying, because articles like this tend to imply the managed service is always a mistake, and it is not. A plain NAT Gateway is the correct choice when:

• Your egress is low or predictable, so $0.045/GB on a few hundred gigabytes is a rounding error you would happily pay to run nothing.
• You value zero operational surface more than the saving. No box, no patching, no HA design. AWS runs it and scales it.
• Most of your traffic is already off the NAT path via endpoints, so the per-GB line is small to begin with.

If that is you, add the free S3 and DynamoDB gateway endpoints, leave the NAT Gateway alone, and spend your attention on something that matters more. The rest of this only pays off once the per-GB line is a number you would notice.

A managed middle: a flat-priced NVA

Between “rent the metered managed service” and “run your own box” there is a third shape: a network virtual appliance that does the NAT for you, managed, but on a flat licence instead of a per-GB meter. This is where Enforza sits, and, as promised, here is the honest version.

Enforza is a single Linux VM in your own AWS network that does secure source NAT, the same outbound translation a NAT Gateway provides, under a flat per-firewall licence with no per-GB data-processing charge. Because it is a full firewall, it also does egress filtering (FQDN and hostname rules) and logging on the same box, which a NAT Gateway and a NAT instance both leave out. Migration is a route-table change: point the route that currently exits via your NAT Gateway at the Enforza instance instead.

What it does not do, so the comparison stays honest:

• It does not remove your AWS bill. You still pay AWS for the EC2 instance the appliance runs on, and for normal data-transfer-out where it applies. The flat licence replaces the per-GB NAT and firewall metering, not AWS’s underlying infrastructure.
• It is a box you deploy in your network. Managed and self-upgrading, but it is still a VM you run, not a zero-footprint service. If you genuinely want nothing to deploy, the managed NAT Gateway wins on that specific axis.
• The saving is directional. Against a metered NAT-plus-firewall stack it typically lands up to 60–80% lower from meaningful egress volumes upward, and the gap widens as traffic grows because the flat line stays flat. At low volumes the difference is small and a NAT Gateway may be simpler. Run your own numbers in the savings calculator rather than taking a range on faith.

If you are consolidating egress across several VPCs or accounts, the same appliance is the point where you would centralise it. The AWS landing-zone pattern and the open Terraform for it show the route-table and appliance-mode detail, which is the same regardless of whose appliance you put in the path.

The short version

The NAT Gateway hourly charge is not the problem; the $0.045/GB data-processing charge is, and it multiplies quietly per AZ and on traffic that never needed the internet. In order of effort-to-reward:

1. Add the free S3 and DynamoDB gateway endpoints. Do this regardless of anything else.
2. Add interface endpoints for the busy AWS services, skip them for the quiet ones.
3. If you want cheaper internet egress and can own the ops, a NAT instance or fck-nat removes the per-GB charge.
4. If you want it managed and want egress control on the same box, a flat-priced NVA removes the per-GB charge and adds the firewall, at the cost of running a VM.
5. If your egress is small, do step 1 and stop. The plain NAT Gateway is fine.

Knowing which of the two lines, the hourly or the per-GB, is actually driving your bill is the whole game. For a step-by-step playbook ranked by impact, see how to reduce AWS NAT Gateway costs: 7 ways; for the AWS-specific rates at a glance and a calculator, see AWS NAT Gateway cost; for the same question across AWS, Azure and GCP, see reducing cloud NAT costs.

FAQ