Understanding Amazon VPC Regional NAT Gateway

Overview

Regional NAT Gateway operates at the VPC level rather than per-AZ. You create one NAT Gateway, reference a single ID in your route tables across all AZs, and AWS handles expansion, IP allocation, and high availability automatically. No public subnets needed, RNAT is a standalone resource with its own route table.

This simplifies centralized egress architectures from managing N NAT Gateways (one per AZ) + N public subnets + N route tables down to one RNAT + one route entry.

How Regional NAT Gateway works

When you launch resources in a new Availability Zone, the Regional NAT Gateway detects the presence of a network interface (ENI) in that AZ and automatically expands to that zone. Similarly, it contracts from AZs that have no active workloads. This expansion and contraction maintains zonal affinity, traffic from AZ1 is processed by the NAT instance in AZ1, traffic from AZ2 by the instance in AZ2.

It may take up to 60 minutes to expand to a new AZ after a resource is instantiated there. Until expansion completes, traffic from that AZ is processed cross-zone by the Regional NAT Gateway in one of the existing Availability Zones.

Regional NAT Gateway supports two modes:

• Automatic mode (recommended): AWS manages IP addresses and AZ expansion. When the NAT Gateway expands to a new AZ, it automatically allocates and associates an EIP. If you use Amazon VPC IPAM, it can pull addresses from your IPAM pools for governed allocation.

• Manual mode: You manage IP addresses and control NAT for each AZ yourself. You are responsible for expanding and contracting across Availability Zones.

Own route table: When you create a Regional NAT Gateway, AWS automatically creates a route table for it with a pre-configured route to the internet gateway (0.0.0.0/0 → IGW). You can add return routes to this table for middleboxes (Network Firewall endpoints, GWLB endpoints, Transit Gateway). This is what enables traffic inspection chaining on the return path.

Port and IP scaling: Each IP supports up to 55,000 concurrent connections to a unique destination (unique combination of destination IP, port, and protocol). Regional NAT Gateway supports up to 32 IP addresses per AZ (compared to 8 for zonal). When connections approach ~40,000 to the same destination, it automatically adds IPs. Scale-up takes ~5 minutes. Scale-down is conservative, happens after connections drop below ~20,000 for approximately 1 hour.

No public subnets required: Unlike zonal NAT Gateways that must be hosted in a public subnet, Regional NAT Gateway is a standalone VPC resource. You do not need a public subnet in your VPC, which reduces the risk of accidentally placing private resources in subnets with public connectivity.

Regional NAT Gateway vs. Zonal NAT Gateway

Aspect	Regional NAT Gateway	Zonal NAT Gateway
Scope	VPC-level, auto-expands across AZs	Single AZ, manually deployed
Public subnet required	No	Yes
Route tables	One entry for all AZs (same RNAT ID)	One NAT GW per AZ in route table
AZ expansion	Automatic (up to 60 min for new AZs)	Manual (create new NAT GW + routes)
IP scaling	Automatic, up to 32 IPs per AZ	Manual, up to 8 IPs
Bandwidth	5 Gbps per AZ, scales to 100 Gbps	5 Gbps per AZ, scales to 100 Gbps
Private NAT	Not supported	Supported
Limit	5 RNATs per VPC	No per-VPC limit

When to use Regional vs. Zonal

Use Regional NAT Gateway when:

• You want simplified architecture with one NAT ID across all AZs
• You don't need public subnets in your VPC (improved security posture)
• Workloads frequently expand to new AZs
• You want automatic IP scaling for port exhaustion protection
• You need VPC IPAM integration for governed IP allocation

Use Zonal NAT Gateway when:

• You need private NAT connectivity (RNAT doesn't support private connectivity)
• You need deterministic AZ placement from the start (no expansion delay)
• You have strict requirements about which EIP is used per AZ from creation

Important considerations

• AZ expansion takes 15-60 minutes after an ENI is detected. Until then, traffic routes cross-AZ.
• Private NAT is not supported, use zonal NAT Gateways for private connectivity.
• Up to 5 Regional NAT Gateways per VPC.
• The RNAT route table supports IGW, VPC endpoints (GWLBE/firewall), network interfaces, and Transit Gateway as route targets.
• When chaining with Network Firewall, add per-AZ spoke subnet routes in the RNAT route table to avoid asymmetric routing (return traffic blackholed).
• Manual mode requires you to manage EIP allocation and AZ expansion yourself.

Key takeaways

• Regional NAT Gateway simplifies egress architecture: one NAT ID, one route entry, auto-expands across AZs.
• No public subnets required, improved security posture for VPCs hosting private workloads.
• Zonal affinity ensures traffic stays local per AZ (different EIPs per AZ confirm this).
• Not a replacement for zonal NAT in all cases, private NAT still requires zonal mode.
• When chaining with stateful firewalls, per-AZ routes in the RNAT route table are mandatory to prevent asymmetric routing.

Related information

[1] Introducing Amazon VPC Regional NAT Gateway (AWS Blog)

[2] Regional NAT Gateways — AWS Documentation

[3] Build scalable IPv4 addressing with Regional NAT Gateway, VPC IPAM, and Prefix Lists (AWS Blog)

[4] Amazon VPC NAT Gateway pricing