.webp)
On November 20, 2025, AWS announced the Regional NAT Gateway, a significant architectural enhancement for VPCs. This feature allows customers to provision a single NAT Gateway per Region—rather than one per Availability Zone (AZ)—dramatically simplifying operations, improving resiliency, and minimizing misconfigurations.
In this post, I will break down what this feature means for your AWS environment, why it matters, what problems it solves, and how to decide whether you should adopt it—or skip NAT entirely and push toward IPv6.
Why NAT Exists in IP Networks
Network Address Translation (NAT) emerged to solve two core problems in IPv4 network design:
- IPv4 address scarcity - Private subnets allow organizations to run thousands of instances behind a small number of public IPs.
- Protecting internal systems from the public internet - NAT enables outbound connections without exposing inbound paths.
Servers can fetch updates, connect to SaaS APIs, or send logs outbound while remaining unreachable from the outside world. This pattern remains central in AWS VPC design, especially for workloads such as:
- EC2-based microservices
- Amazon ECS and EKS nodes
- Private Lambda functions using VPC ENIs
- Managed services that require internet access (e.g., sending telemetry, downloading OS packages)
- Data pipelines that need to access public endpoints
Note on IPv6: While IPv6 solves the scarcity issue, adoption remains slow due to hardware/software upgrade costs and the learning curve of the new addressing format. Consequently, NAT remains a necessary evil for most.
The Evolution of AWS NAT
NAT Instances
When Amazon VPC launched in 2013, there was no managed NAT service. Customers deployed NAT Instances (EC2 instances running IP tables). While flexible, this approach had significant downsides:
- Single point of failure (bound to an AZ).
- Maintenance overhead (OS patching, software updates).
- Throughput limited by instance size.
- High availability was manual and cumbersome.
Zonal NAT Gateway
The first managed NAT offering from AWS was simply called NAT Gateway which is now being referred to as Zonal NAT Gateway. It was the first step towards uplifting some of the work required in maintaining NAT instances. It was fully managed by AWS, removing the burden of patching and scaling, offering tens of gigabits of throughput. However, it introduced new architectural friction:
- AZ-Bound: You needed one Gateway per AZ to ensure redundancy.
- Complex Routing: Cross-AZ routing mistakes could lead to high data transfer costs.
- Scale: Costs and management overhead scaled linearly with the number of AZs.
For many customers, especially those running 3-AZ production workloads, NAT Gateway costs became a meaningful line item in their invoices, as you get charged for the gateway being active and a per-gigabyte charge for data processed through it.
The New Era: Regional NAT Gateway
AWS is addressing some of these pain points with the Regional NAT Gateway; a single, Region-wide NAT that simplifies architecture and significantly reduces overhead.
How Regional NAT Works
- You create one single NAT Gateway at the Region level
- You attach it to any private subnets across AZs
- AWS ensures multi-AZ resiliency behind the scenes
- Traffic automatically uses the Regional NAT for egress
Traffic automatically uses the Regional NAT for egress. It acts like a Zonal NAT Gateway from a security perspective but is no longer tied to a specific Availability Zone. This brings NAT in line with other regional constructs like Transit Gateways and Network Firewalls.
The Million Dollar Question: Does it Save Money?
Cost has long been the primary frustration with Zonal NAT Gateways. At first glance, a single Regional NAT Gateway sounds cheaper than three Zonal ones.
Unfortunately, the answer is no. There is no difference in pricing.
For the us-east-1 region, a Zonal NAT Gateway costs $0.045/hour. The Regional NAT Gateway also costs $0.045/hour per active AZ. Enabling a Regional NAT Gateway for 3 AZs costs exactly the same as deploying 3 separate Zonal NAT Gateways.
Cost Comparison (us-east-1)
Verdict: You save a few dollars on Elastic IPs (EIPs), but the heavy lifting costs remain identical.
Verdict
What we love about Regional NAT Gateways
- Simplicity: One Terraform resource instead of three (or six, or nine...).
- Security: No public subnets needed, reducing the blast radius.
- Observability: Single CloudWatch metric namespace and one set of tags to manage.
- Clean Routing: No more route-table-per-AZ spaghetti.
- Capacity: Slightly higher connection limits per AZ (32 IPs vs 8).
What we don’t love
- Cost is exactly the same per active AZ — the #1 complaint we hear in every Well-Architected review
- 60-minute warm-up delay when expanding to a new AZ (traffic is proxied in the meantime)
- Connection state is still reset during migration from zonal → regional
Our recommendation
For New VPCs: Default to Regional NAT Gateways. The operational simplicity and reduced misconfiguration risk are worth it, even at identical costs.
For Existing Zonal Deployments: Migrate only if you have a maintenance window or are already refactoring the VPC. There is no financial ROI to justify the migration effort alone.
IPv6 Is Still the Only Real Cost Fix
If cost is your primary concern, the Regional NAT Gateway is not your savior. The fastest path to $0 NAT spend remains IPv6.
For greenfield workloads, IPv6-only + Egress-Only Internet Gateway is the only way to make outbound internet access truly free and regional by default.
Conclusion
AWS finally gave us the operational experience we’ve begged for since 2015: a single, auto-scaling, regional NAT Gateway with no public subnets.
But let’s not sugar-coat it: this announcement does not reduce your bill in any meaningful way. If cost is your primary concern (and for most of our customers it is), the fastest path to $0 NAT spend remains the same as it was yesterday: move to dual-stack or IPv6-only as aggressively as your dependencies allow.
%20(1).svg)
.svg)
.png)
