Why is your AWS NAT gateway bill so high, and how do you cut it?

How AWS charges for NAT Gateways

AWS bills a NAT gateway across three distinct meters: uptime, data processing, and public IP allocation. If you deploy a gateway across multiple zones or send traffic across boundaries, extra data transfer charges get tacked on too.

Hourly charges and partial hours

According to the official AWS VPC pricing, you are billed for each NAT Gateway-hour that your gateway is provisioned and available. In the US East (Ohio) region, the base rate is $0.045 per hour.

There is no prorated down-to-the-second billing for running a NAT gateway: each partial NAT Gateway-hour consumed is billed as a full hour. If you spin up a gateway for five minutes to run a script and tear it down, you pay for the full hour. Over a 30-day month (720 hours), one standard gateway costs $32.40 just to exist.

If you choose to create a NAT gateway with regional availability in your VPC, the pricing structure scales with your footprint. A Regional NAT Gateway is charged for each hour it is configured in each Availability Zone. In US East (Ohio), that rate is $0.045 per hour per AZ. If your regional NAT spans three Availability Zones for an hour, you are billed for three NAT Gateway-hours, which amounts to $0.135 per hour ($0.045 x 3). When workloads scale down and the regional NAT removes support from an Availability Zone, AWS automatically adjusts your billing and stops charging for that specific AZ.

Data processing charges

Data processing is where bills get out of hand. AWS charges $0.045 per GB processed through the NAT gateway in US East (Ohio), regardless of the traffic's source or destination.

It does not matter whether the traffic goes to an external API on the public internet, an S3 bucket in your own account, or an internal repository. If the network packet enters the NAT gateway, you pay the $0.045 per GB fee.

Public IPv4 charges

Every NAT gateway requires an Elastic IP address to communicate with the internet. AWS charges $0.005 per hour for both in-use and idle public IPv4 addresses, calculated in one-second increments with a minimum of 60 seconds. That adds roughly $3.60 per month to the running cost of each gateway, making your real base price closer to $36.00 a month per NAT gateway before any data moves.

Data transfer out charges

Using a NAT gateway also incurs standard AWS data transfer charges for all data transferred via the gateway. For example, if an EC2 instance sends data through a Regional NAT Gateway to a non-AWS internet location in US East (Ohio), you pay the standard Data Transfer Out to Internet rate of $0.09 per GB in addition to the $0.045 per GB processing charge.

Why traffic to S3 and DynamoDB drives surprise bills

The most common reason for a sudden spike in NAT Gateway costs is AWS internal traffic.

By default, an EC2 instance sitting in a private subnet has no direct route to the public internet or to AWS public service endpoints. When your private instances need to download packages, call third-party APIs, or upload objects to Amazon S3, you configure your subnet's route table to point default outbound traffic (0.0.0.0/0) to the NAT gateway.

Once you do that, every request your instance makes to S3 or DynamoDB goes through the NAT gateway. When an EC2 instance sends data to an S3 bucket in the same region via a NAT gateway, AWS does not charge an EC2 data transfer fee for the transfer to S3, but you still pay the $0.045 per GB NAT Gateway data processing charge. If you stream database dumps, write application logs, or pull large datasets to or from S3 through that route, you are paying $45 per terabyte for data that never left the AWS network.

Cross-Availability Zone placement creates a secondary leak. There is no data transfer charge between a NAT gateway and an EC2 instance when both are in the same Availability Zone using private IP addresses. But if an EC2 instance in Availability Zone A sends data through a NAT gateway sitting in Availability Zone B, standard cross-AZ data transfer charges apply on top of the NAT data processing fee.

Comparing NAT Gateways and Gateway Endpoints

Before routing all your VPC traffic through a NAT device, look at what endpoints AWS provides for free. Gateway Type VPC endpoints connect private subnets directly to Amazon S3 and Amazon DynamoDB without touching the NAT gateway.

Gateway VPC endpoints provide reliable connectivity to Amazon S3 and DynamoDB without requiring an internet gateway or a NAT device. Unlike other VPC endpoint types, gateway endpoints do not use AWS PrivateLink, and there is no additional charge for using them.

Step-by-step: route S3 and DynamoDB away from your NAT Gateway

If most traffic through your NAT gateway goes to AWS services that support interface or gateway endpoints, creating an endpoint is the fastest way to drop your bill. Both Amazon S3 and DynamoDB support gateway endpoints.

Here is how VPC gateway endpoints work and how to configure them properly:

1. Create the gateway endpoint in the VPC console. Choose either the S3 or DynamoDB service name for your region, select your VPC, and select the route tables associated with your private subnets.
2. Review the automated route table updates. When creating a gateway endpoint, AWS automatically adds a route to each selected VPC route table. The destination is an AWS-owned prefix list for the service (such as pl-xxxxxx for S3), and the target is the gateway endpoint ID. You cannot manually modify or delete endpoint routes added to a route table; AWS removes the route automatically if you disassociate the route table or delete the endpoint.
3. Understand route precedence. VPC routing uses longest prefix match. Because the service prefix list is more specific than the default 0.0.0.0/0 route, the endpoint route takes precedence over the internet route for traffic destined for S3 or DynamoDB in the current region. You do not need to alter your instance code or rewrite endpoints; traffic immediately diverts from the NAT gateway to the free endpoint.
4. Check route table constraints. A single VPC route table can have both an S3 endpoint route and a DynamoDB endpoint route. You can have endpoint routes to the same service in multiple route tables, but you cannot have multiple endpoint routes to the same service in a single route table. If a route table contains an explicit route specifying the exact IP address range for S3 or DynamoDB in the same region, that route takes precedence over the gateway endpoint route.
5. Verify regional boundaries. Gateway endpoint prefix lists are Region-specific. Traffic destined for an S3 bucket or DynamoDB table located in a different AWS Region will not use the gateway endpoint; it will continue out through your default 0.0.0.0/0 route to the NAT gateway or internet gateway.
6. Update network ACLs if necessary. Subnet network ACLs cannot reference prefix lists directly. If you restrict outbound traffic with network ACL rules, you must allow traffic using the actual IP address ranges from the service's prefix list.
7. Verify DNS settings. To use DNS record IP types other than service-defined on a gateway endpoint, both enableDnsSupport and enableDnsHostnames must be enabled in your VPC settings. Note that DynamoDB gateway endpoints only support the service-defined DNS record IP type and cannot be changed. Also, if you create a gateway endpoint using an IPv4 service endpoint and your client applications call dualstack service endpoints, traffic using AAAA records will not route through the gateway endpoint.

Once the route is associated, all instances in subnets tied to that route table automatically use the gateway endpoint. Instances in unassociated subnets continue using the public service endpoint via the NAT device.

Reducing cross-AZ fees and deleting unused gateways

If your NAT bill is still high after isolating S3 and DynamoDB, look at your Availability Zone traffic patterns.

When instances in multiple AZs talk to a single NAT gateway, you pay cross-AZ transfer fees on top of the gateway processing fee. If your AWS resources send or receive a significant volume of traffic across Availability Zones, make sure the resources reside in the same Availability Zone as the NAT gateway. Alternatively, create an independent NAT gateway in each Availability Zone where you run resources, though you must balance the extra $0.045 hourly fee against the cross-AZ data savings.

If you spun up a NAT gateway for a temporary deployment, tests, or initial staging, remember that simply stopping your instances does not stop NAT charges. The gateway bills for every hour it is provisioned. To stop incurring charges, you must explicitly delete the NAT gateway using the AWS Management Console, command line interface (CLI), or API.

Catching NAT Gateway spikes early with Costbrake

Surprise data processing charges often hide until the monthly invoice arrives. AWS Cost Explorer updates billed costs once a day, meaning a runaway backup script running on a Friday night might burn hundreds of dollars before you notice the spike on Saturday or Sunday. If you are tracking cloud costs, you can read our guide on why Cost Explorer has delays to see how those updates settle.

Costbrake monitors your spend across AWS and other cloud and AI providers to catch these spikes as they happen. On Pro and Team plans, Costbrake checks live CloudWatch metrics every 5 minutes (and up to every minute during a spike), reading NAT gateway data processed directly to estimate usage within minutes instead of waiting for daily billing reports. If an hourly bill jumps more than 3x above your 7-day baseline and increases by at least $5, Costbrake sends a spike alert to Slack, Discord, email, or webhooks.

Costbrake costs a flat $0 on the Free plan, $12 a month for Pro, or $39 a month for Team, with no percentage cut of your cloud spend. You can review plan limits on the Costbrake pricing page. To connect your account without configuring manual monitors, see the agent setup guide.