AWS Regional vs Zonal NAT Gateways: When to Use Each

What Is Regional NAT Gateway?

A Regional NAT Gateway is a single resource that operates at the VPC level. Instead of deploying one NAT Gateway per AZ and managing routes individually, you create one Regional NAT Gateway and it automatically expands and contracts across AZs based on your workload presence.

Key characteristics:

• No public subnets required — it's a standalone resource with its own managed route table (pre-configured with an internet gateway route)
• One NAT Gateway ID used in all private subnet route tables — no per-AZ routing logic
• Auto-expands when workloads launch in a new AZ; contracts when they leave
• Up to 32 IP addresses per AZ (vs 8 for zonal), with automatic port exhaustion protection
• Maintains zonal affinity — once expanded, traffic stays in-zone

For the full feature walkthrough, see Introducing Amazon VPC Regional NAT Gateway (https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-amazon-vpc-regional-nat-gateway/).

Quick Comparison

	Zonal NAT Gateway (Public)	Zonal NAT Gateway (Private)	Regional NAT Gateway
Use Case	Internet Egress	Private - to - private Routing	Regional NAT Gateway
Scope	Single AZ	Single AZ	Auto Expands across AZs
Public Subnet Required	Yes	No	No
Internet Access	Yes	No	Yes
EIP Required	Yes	No	Yes
BYOIP	Supported	NA	Supported
Private Connectivity	No	Yes	No
Max IP Addresses assignable	Up to 8	Up to 8	Up to 32
HA Model	Manual (1 per AZ)	Manual (1 per AZ)	Automatic

When to Use Each Type

Requirement	Recommended	Why
Internet egress from private subnet	Regional	Single resource, auto HA, no public subnet needed
New VPC Deployments	Regional	Simpler Infrastructure, Fewer resources to manage
Existing multi AZ Zonal Setup (Internet egress only)	Regional - consider migrating	Less operational overhead
Private-to-private routing (TGW, VPC peering, overlapping CIDRs)	Zonal (Private mode)	Regional NAT does not support private NAT
Must retain specific EIPs for external allow-listing	Regional (Manual mode) or Zonal	Both support manual EIP assignment
Egress with traffic inspection	Regional	Supports Network firewall/GWLBs

Simple rule: Regional for all public internet egress use cases. Zonal only when you need private NAT connectivity.

Operational Considerations

With zonal NAT Gateways, high availability requires deploying and maintaining one NAT Gateway per AZ — typically three in most regions. Each incurs its own hourly charge. Regional NAT Gateway achieves the same availability with a single billable resource that handles AZ expansion automatically.

This reduces:

• Number of NAT Gateway resources to manage and pay for
• Public subnets to create, secure, and audit
• Route table entries to maintain
• IaC template complexity (fewer resources per VPC module)

For current pricing, see Amazon VPC Pricing (https://aws.amazon.com/vpc/pricing/).

Cost Comparison

An important clarification: Regional NAT Gateway is billed per active Availability Zone, not as a flat single-resource fee. If your workloads run in 3 AZs, you pay for 3 AZ-hours — equivalent to 3 zonal NAT Gateways in hourly cost.

Example (3 AZs, us-east-1):

	3 * Zonal Nat Gateway	1 Regional NAT Gateway (3 AZ Active)
Hourly Cost	3 * $0.045 = $0.135/hr	3 * $0.045 = $0.135/hr
Monthly (~730 Hours)	~$98.55	~$98.55
Data Processing	$0.045/GB	$0.045/GB

So where's the savings?

• Auto-contraction: When workloads leave an AZ, Regional NAT Gateway stops billing for that zone automatically. With zonal, you keep paying until you manually delete the gateway.
• Operational cost: Fewer resources to manage = less engineering time on infrastructure maintenance, fewer IaC resources, fewer route tables.
• No cross-AZ transfer during steady state: Regional maintains zonal affinity once expanded — traffic stays in-zone just like per-AZ zonal deployment.

The primary value of Regional NAT Gateway is operational simplification and automatic HA — not a per-unit price discount. Note: Regional NAT Gateway expansion is triggered by network interface (ENI) detection. Idle ENIs in an AZ — such as stopped EC2 instances or unused ECS/Lambda interfaces — may keep the gateway expanded and billing active in that zone. Clean up unused ENIs to ensure contraction works as expected.

How to Migrate

Converting from zonal to regional requires a brief connectivity interruption. Plan for a maintenance window.

Option A: New IP addresses (simpler)

1. Create a Regional NAT Gateway:

aws ec2 create-nat-gateway --vpc-id vpc-abcabcabc --availability-mode regional

2. Update private subnet route tables: change the 0.0.0.0/0 target to the new Regional NAT Gateway ID
3. Verify connectivity
4. Delete old zonal NAT Gateways (and public subnets if no longer needed)

Option B: Preserve existing EIPs

1. Delete existing zonal NAT Gateways (releases their Elastic IPs)
2. Create a Regional NAT Gateway in Manual mode using the released EIPs
3. Update route tables
4. Remove public subnets if no longer needed

What to expect

• Existing connections reset when routes change
• Regional NAT Gateway may take up to 60 minutes to fully expand to all AZs with active workloads — traffic is processed cross-zone in the interim.
• Cross-AZ data transfer during expansion: Until the Regional NAT Gateway expands to a workload's AZ, traffic is routed cross-zone to an AZ where the gateway is already active. This incurs $0.01/GB cross-AZ data transfer in each direction ($0.02/GB round-trip). For high-throughput workloads, factor this interim cost into your maintenance window planning.
• Once expanded, zonal affinity is maintained automatically

Quotas & Limits to verify before migration:

• Connections per NAT Gateway: 55,000 simultaneous connections to a single destination (same as Zonal)
• Bandwidth: 100 Gbps burst per AZ (same as Zonal)
• EIP limit: Default 5 per region
• Check your Service Quotas dashboard for current limits

Common Migration Mistakes to Avoid

• Shared route table with zonal NAT Gateways: If you currently use one route table for all private subnets pointing to a single zonal NAT Gateway (a common misconfiguration), you already have cross-AZ charges. Regional NAT Gateway actually fixes this for you.
• Not checking VPC Endpoints first: Before migrating, audit your NAT Gateway traffic. If most of it goes to S3 or DynamoDB, deploy Gateway VPC Endpoints (free) to eliminate that traffic entirely. Interface VPC Endpoints may also be cheaper than NAT for high-volume AWS API traffic.
• Migrating during peak hours: The expansion delay means cross-AZ routing during your busiest period. Schedule migrations during low-traffic windows.

What Regional NAT Gateway Does Not Replace

• Private NAT Gateway — for private-to-private routing without internet access, continue using zonal NAT Gateways in private mode
• VPC Endpoints — for AWS service access (S3, DynamoDB, etc.), gateway and interface endpoints remain the best practice
• Transit Gateway — Regional NAT Gateway supports TGW as a route target but doesn't replace TGW for inter-VPC connectivity

Conclusion

Regional NAT Gateway delivers the same multi-AZ resilience as the traditional per-AZ deployment with less infrastructure to manage. If your VPCs have multiple zonal NAT Gateways deployed purely for internet egress high availability, Regional mode is a simpler alternative.

Resources :

• Regional NAT Gateway documentation (https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateways-regional.html)
• Introducing Amazon VPC Regional NAT Gateway (https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-amazon-vpc-regional-nat-gateway/)
• Build scalable IPv4 addressing with Regional NAT Gateway and IPAM (https://aws.amazon.com/blogs/networking-and-content-delivery/build-scalable-ipv4-addressing-with-aws-nat-gateway-in-regional-availability-mode-amazon-vpc-ipam-policies-and-prefix-lists/)
• Amazon VPC Pricing (https://aws.amazon.com/vpc/pricing/)