AWS NAT Gateway Billing: Why You Are Paying for Ghost Infrastructure

NAT Gateways are one of the most silent budget killers on AWS. A startup architect deploys three NAT Gateways across Availability Zones for high availability, and for months or years they sit idle—processing zero packets, handling zero connections, delivering zero value. Yet they silently accumulate $32.85 per month each, $98.55 for the full 3-AZ setup. Many of those gateways have been running since 2019, discovered by accident only when someone finally pulled a 24-month cost report and saw the $5,000+ networking line item.

The problem is so common that AWS finally added tooling to find them: in November 2025, AWS Compute Optimizer launched unused NAT Gateway recommendations. In February 2026, Trusted Advisor integrated those signals to make detection even easier. But here is the real lesson—and why this announcement matters beyond just cleanup: the best NAT Gateway is often the one you never build in the first place.

This post walks you through the NAT Gateway billing model, the new detection capability, and more importantly, when to use ranked alternatives that cost 90% less or even free.

The Layered Cost Model: Why NAT Gateways Are Expensive

NAT Gateway pricing has multiple compounding layers that interact in ways many architects do not anticipate:

Hourly existence fee: $0.045/hour per gateway. A single gateway running for a month costs $32.85 just to exist, regardless of traffic volume.

Data processing charge: $0.045/GB for all data flowing through the gateway in either direction. This is on top of internet egress fees.

Internet egress charge: $0.09/GB for data leaving AWS to the public internet. This applies separately from the NAT Gateway processing charge.

Public IPv4 address: $0.005/hour per public IP address, added in February 2024. A single NAT Gateway with one public IP costs $3.65/month for the address alone, $43.80/year.

Total cost for internet-bound traffic: $0.135/GB (processing + egress combined).

For a standard 3-AZ production setup with one NAT Gateway per AZ:

The costs look modest in isolation. At scale, the compounding charges across multiple regions, multiple environments, and months of idle infrastructure add up to thousands of dollars per year.

Why Idle NAT Gateways Accumulate

Idle NAT Gateways are not accidents—they are the result of predictable patterns in how infrastructure evolves:

Dev and test environments never cleaned up. A developer spins up a VPC with a NAT Gateway to test an application. The project gets shelved. The VPC is abandoned. The NAT Gateway remains, billing the account at $32.85/month until someone audits the infrastructure.

Disaster recovery standby gateways. A 3-AZ production setup deploys with route tables pre-configured to fail over to a secondary NAT Gateway in a different AZ. That secondary gateway sits idle 99.99% of the time, yet it costs $32.85/month to exist.

Orphaned VPC peering. An application originally required cross-region communication through a NAT Gateway for compliance reasons. The requirement changed, the traffic stopped, but the gateway was never deleted.

“Just in case” infrastructure. Architects deploying to a new region provision a full 3-AZ NAT Gateway setup with the standard architecture, then discover the application never needed it.

Each of these follows from reasonable decision-making at the time. The problem is that idle NAT Gateways generate no alarms, no alerts, and no visible cost signals. They silently bill each month, month after month, year after year.

AWS Compute Optimizer: Finding Idle NAT Gateways

In November 2025, AWS added the capability many wished for years earlier: automated detection of unused NAT Gateways.

How it works: AWS Compute Optimizer analyzes 32 days of CloudWatch metrics for each NAT Gateway. It flags a gateway as unused if it meets all three conditions:

• Zero active connections over the 32-day period
• Zero incoming packets from source (your resources)
• Zero incoming packets from destination (remote systems)

The 32-day window is long enough to capture normal traffic patterns; gateways used only occasionally will not be flagged.

Smart enough to avoid false positives: Compute Optimizer checks route table associations. If a gateway is associated with a route table but not actively handling traffic, it avoids flagging failover-only standby gateways—those pre-configured to take traffic only during disaster recovery when an application swaps route tables dynamically.

How to use it:

1. Open AWS Compute Optimizer in the AWS Console
2. Navigate to NAT Gateways and opt in to recommendations
3. Within 24 hours, recommendations appear with detailed cost savings estimates
4. Cross-reference with AWS Cost Optimization Hub for a centralized view alongside other cost-reduction actions
5. In February 2026, AWS enhanced Trusted Advisor with the same signals; activate Trusted Advisor checks to surface unused gateway recommendations

The catch: Compute Optimizer gives you detection and a recommendation to delete. It does not tell you whether deleting that gateway will break a failover process, a legacy application, or an undocumented dependency. Always verify before deleting.

Tier 1: Free Alternatives — VPC Endpoints

The best alternative is often free.

VPC Gateway Endpoints for S3 and DynamoDB eliminate the need for NAT Gateway for those specific services entirely. Instead of routing traffic through a NAT Gateway to the public AWS API, you configure a gateway endpoint, and traffic stays within the VPC and AWS network. Cost: $0.00.

This is the first optimization to make. If your application talks to S3 or DynamoDB from private subnets, configuring a gateway endpoint removes that traffic from the NAT Gateway entirely and eliminates NAT Gateway charges for that portion of your data transfer.

VPC Interface Endpoints (PrivateLink) extend the concept to nearly every AWS service: ECR, CloudWatch, Secrets Manager, SSM, SQS, SNS, and hundreds more. Instead of routing through NAT Gateway to a public API endpoint, traffic stays private within the VPC.

Cost: $0.01/hour per endpoint + $0.01/GB of data processed. For most services, this is significantly cheaper than NAT Gateway ($0.045/hr + $0.045/GB).

Real-world example: A team using Datadog logs from private subnets. All log traffic went through NAT Gateway at $0.045/GB processing + $0.09/GB egress = $0.135/GB. Switching to a Datadog VPC Interface Endpoint costs $0.01/GB. For 500GB/month: NAT Gateway cost $67.50, VPC endpoint cost $5.00. Savings: $62.50/month, $750/year, with zero application code changes.

Egress-Only Internet Gateway serves IPv6 traffic without requiring a NAT Gateway. Cost: $0.00, AWS-managed with 99.99% SLA. This is the future-forward option for applications moving to IPv6.

Tier 2: 90% Savings — fck-nat and NAT Instances

For workloads requiring general internet access (not just AWS service calls), fck-nat is the production-ready alternative that saves 90% on NAT infrastructure costs.

fck-nat is a modern, actively maintained open-source project that runs a NAT instance on a t4g.nano or t4g.micro EC2 instance. It handles IP masquerading and connection tracking, delivering NAT functionality without paying AWS’s managed NAT Gateway premium.

Cost breakdown:

• t4g.nano base cost: ~$3.00/month
• No per-GB data processing fee (unlike NAT Gateway at $0.045/GB)
• Data egress still charged at $0.09/GB (same as any EC2-based egress)
• Total for light-to-medium traffic: $3.81–$5.00/month vs $32.85/month for managed NAT Gateway

Trade-offs:

• No AWS SLA (managed NAT Gateway has 99.99% availability)
• Failover is manual—if the EC2 instance fails, you must update route tables to point to a secondary NAT instance (can take 30–60 seconds vs. AWS’s automatic failover)
• You own the EC2 instance: patching, monitoring, troubleshooting

Best for: Dev/test environments, cost-sensitive production teams comfortable managing the EC2 instance, startups where the operational trade-off is worth the 90% savings.

The DIY NAT Instance: If fck-nat feels like adding a new dependency, the DIY approach is simpler than it sounds. Launch a t4g.nano EC2 instance with Amazon Linux, disable source/destination checking, and run iptables -t nat -A POSTROUTING -j MASQUERADE to enable IP masquerading. Cost is identical (~$3.81/month base), but you manage the configuration yourself.

Terraform modules are available for both fck-nat and DIY NAT instances if you want infrastructure-as-code setup.

Tier 3: AWS-Managed Middle Ground — Regional NAT Gateway

In late 2025, AWS introduced Regional NAT Gateway, a single gateway per region that serves all Availability Zones instead of requiring one per AZ.

Cost impact: For a 3-AZ high-availability setup, Regional NAT Gateway costs $32.85/month (one gateway) instead of $98.55/month (three gateways). Savings: 66% on the hourly fee. Data processing and egress fees remain the same per GB, but the gateway can handle traffic from all AZs without duplication.

Best for: Production workloads that require an AWS-managed service with SLA but are sensitive to cost. Regional NAT Gateway keeps you on AWS’s managed service track while cutting costs significantly.

Trade-off: Still more expensive than fck-nat or NAT instances, but you retain the AWS SLA and automatic failover.

Optimization Without Changing Gateway Type

If you keep NAT Gateways, minimize their cost with these patterns:

Same-AZ traffic routing: Route traffic from EC2 instances through NAT Gateways in the same Availability Zone. Cross-AZ NAT traffic incurs $0.02/GB cross-AZ charge in both directions ($0.02/GB for leaving the source AZ, $0.02/GB for entering the destination AZ). For 1TB of cross-AZ NAT traffic, that is $20.00/month—easily avoidable with same-AZ routing.

Audit traffic with VPC Flow Logs and CloudWatch Logs Insights. Identify which traffic actually needs NAT Gateway vs. which is calling AWS services that could use free VPC endpoints. Often 50%+ of NAT Gateway traffic can be redirected to VPC endpoints with zero code changes.

Transit Gateway centralization: For organizations with multiple VPCs, consolidating NAT Gateways via Transit Gateway reduces duplication and improves visibility.

Decision Framework: Which Alternative to Use

Related Resources

• AWS Data Transfer Costs: The Line Item That Breaks Startups — Deep dive into NAT Gateway’s role in the data transfer bill
• AWS Cost Optimization Hub Guide — How to centrally track cost-reduction recommendations
• AWS VPC Networking Best Practices for Production — Design patterns to minimize network cost

Start Here

If you have NAT Gateways, your action list is:

1. Opt into AWS Compute Optimizer if you have not already (free)
2. Review unused NAT Gateway recommendations — Compute Optimizer will find the obvious candidates
3. Audit traffic with VPC Flow Logs — Identify which traffic could be redirected to VPC endpoints
4. Implement VPC Gateway Endpoints for S3 and DynamoDB first — instant savings, zero code changes
5. Implement VPC Interface Endpoints for other AWS services your application uses
6. Re-evaluate your NAT Gateway fleet. Do you need 3-AZ? One per region? Or could a fck-nat instance save 90%?

The NAT Gateway problem is not new—it is how AWS’s billing structure creates invisible costs that compound silently over months and years. The good news is you have multiple paths to reduce that cost by 66% to 90%, and some of those paths cost nothing to implement.

Ready to lower your networking bill? We help AWS customers architect cost-optimal infrastructure that does not compromise on availability or security.