Regional NAT Gateway, and what it removes
One NAT Gateway per Availability Zone was the standard answer for years. The regional variant collapses that to one resource per VPC and takes SNAT port exhaustion off the list of things you monitor.
A NAT Gateway has always been a zonal resource. Want internet egress from private subnets across three Availability Zones without a single point of failure, and you deploy three of them, three public subnets, three Elastic IPs and a route table per AZ. AWS Regional NAT Gateway collapses that into one resource at the VPC level.
What the per-AZ pattern costs you
The old rule was simple enough. NAT Gateways live in one AZ, so an AZ failure takes egress with it unless you have one per zone. Every time the architecture grew into a new AZ, someone had to create a public subnet there, deploy a NAT Gateway into it, and point that zone's private route table at that specific gateway.
It works. It is also repetitive, easy to get subtly wrong in Terraform copy-paste, and it forces you to keep public subnets in VPCs you would rather keep entirely private.
The last part is the one that matters for security. A public subnet that exists only to host a NAT Gateway is still a public subnet, and sooner or later somebody launches something into it.
How the regional version differs
A Regional NAT Gateway is scoped to the VPC rather than to an AZ. It expands and contracts across zones based on where your workloads actually are, and every private subnet routes to the same gateway ID. One route table entry, no zone-specific branching.
Two consequences follow from that.
You no longer need a public subnet in a VPC that hosts sensitive workloads. The VPC can be entirely private and still get managed egress, which removes a whole class of accidental exposure rather than mitigating it with a control.
SNAT port exhaustion stops being a manual problem. The regional gateway associates additional IP addresses when it needs more ports, up to 32 per AZ, scaling up quickly and back down slowly. The old answer was a CloudWatch alarm on ErrorPortAllocation and an engineer adding secondary IPs by hand, usually during the incident that caused the alarm.
Zonal against regional
| Feature | Zonal NAT Gateway | Regional NAT Gateway |
|---|---|---|
| Scope | One Availability Zone | VPC level, cross-AZ by design |
| Public subnets | Required in every AZ with workloads | Not required |
| Port exhaustion | Manual remediation | Adds IPs automatically, up to 32 per AZ |
| Route tables | One entry per zone, pointing at that zone's gateway | One entry, same gateway ID everywhere |
| Cost shape | Pay per gateway, so per AZ | Fewer gateways for the same coverage |
Two things to check before you migrate
Enable it in every AZ where you run workloads. If a zone is not enabled, its traffic routes to a zone that is, and you pay cross-AZ data transfer for the privilege. On a chatty workload that charge can outweigh the gateway you saved.
Pick the right IP mode. Automatic mode lets AWS manage the addresses and suits most environments. Manual mode exists for the case where a third party allowlists your specific Elastic IPs, and if you are in that situation you need it, because addresses appearing without warning will break the allowlist.
What we would do with it
On a new VPC, this is the default for egress. There is very little reason to build the per-AZ pattern again.
On an existing environment, it is a refactor with a real payoff and a real change window: route tables, subnets and anything that depends on the current Elastic IPs. Worth scheduling, not worth doing on a Friday. If you already run a hub-and-spoke network with Transit Gateway, do the egress simplification as part of a planned network change rather than on its own.
Is a regional NAT Gateway cheaper than one per AZ?
Usually, because you pay one hourly charge instead of two or three. Data processing is billed the same either way, so a high-throughput VPC sees a smaller relative saving than a quiet one.
Does it still keep traffic in the same AZ?
Only if you enable it in every AZ that has workloads. It is a regional resource, but the zonal placement still decides whether traffic crosses an AZ boundary and picks up a cross-AZ data transfer charge.
What happens to SNAT port exhaustion?
It scales automatically across up to 32 IP addresses per AZ, so the ErrorPortAllocation alarm and the manual remediation of adding secondary IPs stop being work you own.
Can we keep a fixed set of egress IPs?
Yes, in Manual IP mode. That matters if a partner allowlists your egress addresses. Automatic mode manages the addresses for you and the set can change.
More notes
What a Well-Architected review actually finds
Two weeks of reading someone else's AWS account, and the same handful of problems keep showing up: single-AZ databases, IAM nobody has audited since 2021, and instances paid for at on-demand rates for three years.
Writing a cloud roadmap people will actually follow
Most cloud roadmaps are a list of technologies with quarters next to them. A useful one names the constraint you are working against, what you will not do, and who owns each piece.
Send us your AWS bill
Thirty minutes with an engineer, no slide deck. We will tell you what we would change first and what it would cost to have us do it.