AWS Regional NAT Gateway: The Game-Changing Update That Simplifies Multi-AZ Networking

admin

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:

Zonal vs Regional NAT Gateway Architecture

Figure 1: Zonal NAT Gateway requires separate resources per AZ, while Regional NAT Gateway is a single VPC-level resource.

Feature Comparison

FeatureZonal NAT GatewayRegional NAT Gateway
ScopeSingle AZEntire VPC (multi-AZ)
Public SubnetRequired in each AZNot required
Route TablesOne per AZSingle route for all AZs
AZ ExpansionManual provisioningAutomatic
High AvailabilityManual (multi-NAT setup)Built-in
Private Connectivity✅ Supported❌ Not yet supported
IP ManagementPer-gateway EIPsAutomatic or Manual mode
Max IPs per AZ8 secondary IPs32 IPs

How Regional NAT Gateway Works

Automatic Mode (Recommended)

In automatic mode, AWS handles everything:

  1. Workload Detection: AWS monitors where you launch resources (EC2, Lambda, EKS nodes, etc.)
  2. Automatic Expansion: When resources appear in a new AZ, the Regional NAT Gateway expands there within ~60 minutes
  3. IP Management: AWS automatically allocates and manages Elastic IPs
  4. Traffic Routing: Traffic stays AZ-local when possible, minimizing cross-AZ charges
Regional NAT Gateway Automatic Mode

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:

Production Architecture with Regional NAT Gateway

Figure 3: Complete production architecture with Regional NAT Gateway, VPC Endpoints, and multi-AZ workloads.

Architecture Highlights

  1. Single Regional NAT Gateway serves all private subnets
  2. VPC Endpoints for AWS services (S3, ECR, etc.) to reduce NAT costs
  3. Shared Route Table for all private subnets
  4. 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 exhaustion
  • PacketsDropCount — indicates capacity issues
  • IdleTimeoutCount — 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:

  1. Private NAT Gateway — for overlapping CIDRs or Transit Gateway connectivity
  2. Immediate AZ availability — if you can’t tolerate 60-minute expansion delay
  3. Specific IP addresses per AZ — though Manual mode can address this

Cost Comparison

ScenarioZonal (3 AZs)Regional
NAT Gateway hourly3 × $0.045 = $0.135/hr3 × $0.045 = $0.135/hr
Monthly (720 hrs)~$97.20~$97.20
Elastic IPs3 × $3.65 = $10.95/moManaged 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)

  1. Create Regional NAT Gateway
  2. Update route tables to point to new Regional NAT
  3. Delete old Zonal NAT Gateways

⚠️ This changes your outbound IP addresses.

Option 2: Preserve IP Addresses (Maintenance Window)

  1. Delete existing Zonal NAT Gateways (releases EIPs)
  2. Create Regional NAT Gateway with released EIPs
  3. Update route tables

⚠️ Requires downtime during transition.

Key Takeaways

  1. Regional NAT Gateway is a game-changer for multi-AZ VPC architectures
  2. Eliminates public subnets — better security posture
  3. Single route table — dramatically simpler management
  4. Automatic scaling — no more manual NAT provisioning
  5. Same pricing — but significant operational savings
  6. 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

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *