A deep dive into AWS’s new Regional NAT Gateway — automatic multi-AZ expansion, simplified architecture, and hands-on Terraform implementation
Introduction
If you’ve ever managed AWS VPC networking at scale, you know the pain: deploying NAT Gateways across multiple Availability Zones means managing separate gateways, public subnets, route tables, and Elastic IPs for each AZ. It’s complex, error-prone, and adds unnecessary operational overhead.
On November 19, 2025, AWS announced a significant architectural enhancement: Regional NAT Gateway. This feature fundamentally changes how we design outbound internet connectivity for private subnets.
In this article, I’ll break down everything you need to know about Regional NAT Gateway, why it matters, and provide complete Terraform code to deploy and test it in your environment.
The Problem with Zonal NAT Gateways
Before diving into the solution, let’s understand what we’ve been dealing with:
Traditional (Zonal) NAT Gateway Challenges
1. One NAT Gateway Per AZ Every Availability Zone with private workloads needs its own NAT Gateway. Running a 3-AZ production environment? That’s 3 NAT Gateways to manage.
2. Public Subnets Required Each NAT Gateway must live in a public subnet. This means creating and maintaining public subnets in every AZ — expanding your attack surface.
3. Complex Route Table Management Each private subnet needs a route table pointing to its local NAT Gateway. Forget to update a route table when expanding to a new AZ? Your workloads lose internet access.
4. Manual Scaling When workloads expand to new AZs, you must manually provision NAT Gateways and update routes before your applications can reach the internet.
5. Cost at Scale Each NAT Gateway costs ~$32.40/month (hourly) plus data processing fees. Multiply by the number of AZs, and costs add up quickly.
What is Regional NAT Gateway?
Regional NAT Gateway is a new availability mode that allows you to create a single NAT Gateway at the VPC level that automatically spans multiple Availability Zones.
Key Characteristics
- Single Resource: One NAT Gateway ID serves your entire VPC
- Automatic AZ Expansion: Expands and contracts across AZs based on workload presence
- No Public Subnets Required: AWS manages the infrastructure internally
- Simplified Routing: One route table entry covers all private subnets
- Built-in High Availability: Automatic failover and redundancy
Regional NAT Gateway vs Zonal NAT Gateway
Here’s a visual comparison of the architectural difference:
Figure 1: Zonal NAT Gateway requires separate resources per AZ, while Regional NAT Gateway is a single VPC-level resource.
Feature Comparison
| Feature | Zonal NAT Gateway | Regional NAT Gateway |
|---|---|---|
| Scope | Single AZ | Entire VPC (multi-AZ) |
| Public Subnet | Required in each AZ | Not required |
| Route Tables | One per AZ | Single route for all AZs |
| AZ Expansion | Manual provisioning | Automatic |
| High Availability | Manual (multi-NAT setup) | Built-in |
| Private Connectivity | ✅ Supported | ❌ Not yet supported |
| IP Management | Per-gateway EIPs | Automatic or Manual mode |
| Max IPs per AZ | 8 secondary IPs | 32 IPs |
How Regional NAT Gateway Works
Automatic Mode (Recommended)
In automatic mode, AWS handles everything:
- Workload Detection: AWS monitors where you launch resources (EC2, Lambda, EKS nodes, etc.)
- Automatic Expansion: When resources appear in a new AZ, the Regional NAT Gateway expands there within ~60 minutes
- IP Management: AWS automatically allocates and manages Elastic IPs
- Traffic Routing: Traffic stays AZ-local when possible, minimizing cross-AZ charges
Figure 2: Regional NAT Gateway automatically expands to AZs where workloads are detected.
Manual Mode
For organizations requiring fine-grained control:
- You specify which AZs the NAT Gateway operates in
- You manage Elastic IP assignments per AZ
- You control when to expand or contract coverage
Key Advantages of Regional NAT Gateway
1. Dramatically Simplified Architecture
Before (Zonal):
- 3 NAT Gateways
- 3 Public Subnets
- 3 Route Tables
- 3 Elastic IPs
- 6+ routing entries to manage
After (Regional):
- 1 NAT Gateway
- 0 Public Subnets (you manage)
- 1 Route Table (can be shared)
- AWS-managed EIPs
- 1 routing entry
2. No Public Subnets Required
This is huge for security-conscious organizations. With Regional NAT Gateway:
- Your VPC can be entirely private
- Reduced attack surface
- Simplified network ACL management
- Cleaner security posture
3. Automatic High Availability
No more worrying about:
- NAT Gateway failures in specific AZs
- Manual failover scripts
- Monitoring each gateway separately
The Regional NAT Gateway handles failover automatically.
4. Automatic Port Exhaustion Protection
Regional NAT Gateway integrates with VPC IPAM and automatically:
- Manages additional IP addresses when connection limits approach
- Distributes connections across multiple EIPs
- Supports up to 32 IPs per AZ (vs 8 for zonal)
5. AWS-Managed Route Table
When you create a Regional NAT Gateway, AWS automatically:
- Creates a route table for the NAT Gateway
- Adds a default route to the Internet Gateway
- Manages this infrastructure for you
Important Considerations
Expansion Delay
When workloads first appear in a new AZ:
- It can take up to 60 minutes for the Regional NAT Gateway to expand
- During this window, traffic is proxied through an existing AZ
- This may incur temporary cross-AZ data transfer charges
Pricing
The pricing structure is similar to zonal:
- Hourly charge: ~$0.045/hour per active AZ
- Data processing: ~$0.045/GB
Important: Running Regional NAT Gateway across 3 AZs costs the same as 3 separate Zonal NAT Gateways. The savings come from:
- Fewer Elastic IPs to manage (small savings)
- Reduced operational overhead (significant)
- Potential optimization as you only pay for AZs with actual workloads
Private NAT Gateway Not Supported
Regional mode currently only supports public connectivity. If you need private NAT Gateway for:
- VPC-to-VPC with overlapping CIDRs
- On-premises connectivity via Transit Gateway
You must continue using Zonal NAT Gateways for these use cases.
Migration Considerations
Converting from Zonal to Regional:
- Connections are reset during migration
- Recommend performing during maintenance windows
- You can reuse existing EIPs if needed
Real-World Architecture
Here’s a production-ready architecture using Regional NAT Gateway:
Figure 3: Complete production architecture with Regional NAT Gateway, VPC Endpoints, and multi-AZ workloads.
Architecture Highlights
- Single Regional NAT Gateway serves all private subnets
- VPC Endpoints for AWS services (S3, ECR, etc.) to reduce NAT costs
- Shared Route Table for all private subnets
- Automatic AZ expansion as workloads scale
Terraform Implementation
Now let’s implement Regional NAT Gateway with Terraform. The AWS provider added support in version 6.24.0.
Testing the Implementation
Step 1: Deploy the Infrastructure
# Initialize Terraform
terraform init
# Review the plan
terraform plan
# Deploy
terraform apply -auto-approve
Step 2: Connect to Test Instances
Use AWS Systems Manager Session Manager to connect (no SSH key or bastion needed):
# Get the SSM connect commands from Terraform output
terraform output ssm_connect_commands
# Connect to an instance (example)
aws ssm start-session --target i-0abc123def456 --region eu-central-1
Step 3: Test NAT Gateway Connectivity
Once connected to an instance, run the test script:
# Run the pre-installed test script
./test-nat.sh
Expected output:
=== Regional NAT Gateway Connectivity Test ===
Instance AZ: eu-central-1a
Private IP: 10.0.10.45
Testing outbound connectivity...
1. Checking public IP (via NAT Gateway):
52.28.xxx.xxx
2. Testing DNS resolution:
Server: 10.0.0.2
Address: 10.0.0.2#53
Name: google.com
3. Testing HTTPS connectivity:
HTTP Status: 200
4. Testing package download (via NAT):
Download test: 200 (15234 bytes)
=== Test Complete ===
Step 4: Monitor via CloudWatch
Access the CloudWatch dashboard to see metrics for:
- Active connections per AZ
- Data transfer volumes
- Connection attempts
- Packet drops (should be zero)
Best Practices
1. Use VPC Endpoints for AWS Services
Always create Gateway Endpoints for S3 and DynamoDB — they’re free and bypass NAT Gateway entirely.
2. Start with Automatic Mode
Unless you have specific IP requirements, use ip_allocation_method = "auto". AWS handles EIP management and port exhaustion prevention.
3. Plan for Expansion Delay
Remember: it takes up to 60 minutes for Regional NAT to expand to new AZs. Plan your scaling accordingly or pre-provision workloads in all AZs.
4. Monitor AZ-Level Metrics
Regional NAT Gateway emits CloudWatch metrics per AZ. Set up alarms for:
ErrorPortAllocation— indicates port exhaustionPacketsDropCount— indicates capacity issuesIdleTimeoutCount— may indicate application issues
5. Use for New Deployments
AWS recommends Regional NAT Gateway for all new use cases except those requiring private connectivity.
When NOT to Use Regional NAT Gateway
Stick with Zonal NAT Gateways if you need:
- Private NAT Gateway — for overlapping CIDRs or Transit Gateway connectivity
- Immediate AZ availability — if you can’t tolerate 60-minute expansion delay
- Specific IP addresses per AZ — though Manual mode can address this
Cost Comparison
| Scenario | Zonal (3 AZs) | Regional |
|---|---|---|
| NAT Gateway hourly | 3 × $0.045 = $0.135/hr | 3 × $0.045 = $0.135/hr |
| Monthly (720 hrs) | ~$97.20 | ~$97.20 |
| Elastic IPs | 3 × $3.65 = $10.95/mo | Managed by AWS |
| Data processing | $0.045/GB | $0.045/GB |
Bottom line: Hourly costs are identical. Savings come from:
- Fewer EIPs to manage
- Reduced operational overhead
- Only paying for AZs with actual workloads (if not using all AZs)
Migration from Zonal to Regional
Option 1: New IP Addresses (Simpler)
- Create Regional NAT Gateway
- Update route tables to point to new Regional NAT
- Delete old Zonal NAT Gateways
⚠️ This changes your outbound IP addresses.
Option 2: Preserve IP Addresses (Maintenance Window)
- Delete existing Zonal NAT Gateways (releases EIPs)
- Create Regional NAT Gateway with released EIPs
- Update route tables
⚠️ Requires downtime during transition.
Key Takeaways
- Regional NAT Gateway is a game-changer for multi-AZ VPC architectures
- Eliminates public subnets — better security posture
- Single route table — dramatically simpler management
- Automatic scaling — no more manual NAT provisioning
- Same pricing — but significant operational savings
- Use for new deployments — AWS recommends for all public connectivity use cases
Conclusion
AWS Regional NAT Gateway represents a significant step forward in VPC networking. By abstracting away the complexity of multi-AZ NAT management, AWS has made it easier to build secure, highly available architectures without the operational overhead.
The feature eliminates the need for public subnets, simplifies routing, and provides automatic high availability — all while maintaining familiar pricing. For any new VPC deployment, Regional NAT Gateway should be your default choice for outbound internet connectivity.
Give the Terraform code a try in your environment and experience the simplicity firsthand!
Found this helpful? Follow me for more AWS and DevOps content. Connect on LinkedIn or check out my technical blog at devopsgurus.cloud.
Tags: #AWS #VPC #Networking #NAT #RegionalNATGateway #Terraform #CloudArchitecture #DevOps #Infrastructure #IaC