NAT Gateway
The StandardV2 SKU is zone-redundant by default; the older Standard SKU is a zonal resource pinned to one Availability Zone (or, if you skip zone selection, a nonzonal placement Azure picks for you — the weakest option). The zone configuration is locked in at creation and can't be changed afterward. Like other networking appliances, it's single-region with no native cross-region failover.
Standard SKU, zonal (single AZ) or nonzonal placement
Standard SKU pinned to one Availability Zone, or deployed with no zone specified at all (nonzonal — Azure silently picks a zone for you). Either way, one zone's failure takes outbound connectivity down for every subnet attached, even for VMs sitting in otherwise-healthy zones.
- Replication
- None
- RPO
- N/A — stateless outbound connectivity, not a data store
- RTO
- Unavailable until the zone recovers, or until you manually reroute to a NAT gateway in another zone
- Failover trigger
- Manual (customer-triggered)
- Relative cost
- No extra cost
Standard SKU baseline pricing, zonal or not.
Nonzonal is explicitly not recommended by Microsoft — it gives no protection against a zone outage despite looking like a simpler default.
Shows Unknown at every tier — there's no fixed RPO/RTO for this option; it depends entirely on an architecture you'd have to design and build.
StandardV2 SKU, zone-redundant (recommended)
Automatically spreads NAT gateway instances across every Availability Zone in the region. Traffic from any healthy zone routes through a surviving instance with no customer action.
- Replication
- None
- RPO
- N/A — stateless; active connections through the failed zone drop and clients retry
- RTO
- New connections route through a healthy zone almost immediately; existing connections in the failed zone must be retried
- Failover trigger
- Automatic
- Relative cost
- Low cost premium
StandardV2 may carry a modest premium over Standard SKU pricing — check current NAT Gateway pricing for exact rates before assuming parity.
Requires a StandardV2 SKU public IP — you can't attach a Standard (v1) public IP to a StandardV2 gateway.
Independent NAT gateways per region (customer-built)
NAT Gateway has no multi-region capability of any kind. A second region means a fully separate NAT gateway, its own public IPs, and its own subnet attachment — there's nothing to fail over, only something to duplicate.
- Replication
- N/A
- RPO
- N/A — connectivity layer
- RTO
- Entirely dependent on your regional failover architecture
- Failover trigger
- N/A
- Relative cost
- High cost premium
A fully separate NAT gateway, public IPs, and subnet attachment per region — full duplication, nothing shared.
Shows Unknown at every tier — there's no fixed RPO/RTO for this option; it depends entirely on an architecture you'd have to design and build.
Gotchas
Zone configuration is permanent
You cannot change a NAT gateway's Availability Zone configuration — zonal vs. zone-redundant, or which zone — after deployment. Fixing an under-protected NAT gateway means creating a new one (with a new, SKU-matched public IP) and re-pointing subnets to it.
"No zone specified" is not the safe default
Skipping zone selection on the Standard SKU doesn't give you zone redundancy — it gives you a nonzonal placement in a single zone Azure chooses, with the same all-or-nothing exposure as an explicit zonal deployment. Zone redundancy is opt-in via the StandardV2 SKU, not automatic.
The NAT gateway's resiliency doesn't cover the VMs behind it
A zone-redundant NAT gateway keeps outbound connectivity alive, but if the VMs using it aren't themselves spread across zones, a zone failure still takes down the workload — just not because of NAT Gateway. Assess the compute tier's zone posture separately.