Edit

NAT gateway and availability zones

  • Article

NAT gateway is a zonal resource, which means it can be deployed and operate out of individual availability zones. With zone isolation scenarios, you can align your zonal NAT gateway resources with zonally designated IP based resources, such as virtual machines, to provide zone resiliency against outages. Review this document to understand key concepts and fundamental design guidance.

Diagram of zonal deployment of NAT gateway.

Figure 1: Zonal deployment of NAT gateway.

NAT gateway can either be designated to a specific zone within a region or to no zone. Which zone property you select for your NAT gateway resource informs the zone property of the public IP address that can be used for outbound connectivity as well.

NAT gateway includes built-in resiliency

Virtual networks and their subnets are regional. Subnets aren't restricted to a zone. While NAT gateway is a zonal resource, it's a highly resilient and reliable method by which to connect outbound to the internet from virtual network subnets. NAT gateway uses software defined networking to operate as a fully managed and distributed service. NAT gateway infrastructure includes built-in redundancy. It can survive multiple infrastructure component failures. Availability zones build on this resiliency with zone isolation scenarios for NAT gateway.

Zonal

You can place your NAT gateway resource in a specific zone for a region. When NAT gateway is deployed to a specific zone, it provides outbound connectivity to the internet explicitly from that zone. NAT gateway resources assigned to an availability zone can be attached to public IP addresses either from the same zone or that are zone redundant. Public IP addresses from a different availability zone or no zone aren't allowed.

NAT gateway can provide outbound connectivity for virtual machines from other availability zones different from itself. The virtual machine’s subnet needs to be configured to the NAT gateway resource to provide outbound connectivity. Additionally, multiple subnets can be configured to the same NAT gateway resource.

While virtual machines in subnets from different availability zones can all be configured to a single zonal NAT gateway resource, this configuration doesn't provide the most effective method for ensuring zone-resiliency against zonal outages. For more information on how to safeguard against zonal outages, see Design considerations later in this article.

Nonzonal

If no zone is selected at the time that the NAT gateway resource is deployed, the NAT gateway is placed in no zone by default. When NAT gateway is placed in no zone, Azure places the resource in a zone for you. There isn't visibility into which zone Azure chooses for your NAT gateway. After NAT gateway is deployed, zonal configurations can't be changed. No zone NAT gateway resources, while still zonal resources can be associated to public IP addresses from a zone, no zone, or that are zone-redundant.

Design considerations

Now that you understand the zone-related properties for NAT gateway, see the following design considerations to help you design for highly resilient outbound connectivity from Azure virtual networks.

Single zonal NAT gateway resource for zone-spanning resources

A single zonal NAT gateway resource can be configured to either a subnet that contains virtual machines that span across multiple availability zones or to multiple subnets with different zonal virtual machines. When this type of deployment is configured, NAT gateway provides outbound connectivity to the internet for all subnet resources from the specific zone where the NAT gateway is located. If the zone that NAT gateway is deployed in goes down, then outbound connectivity across all virtual machine instances associated with the NAT gateway goes down. This set up doesn't provide the best method of zone-resiliency.

Diagram of single zonal NAT gateway resource.

Figure 2: Single zonal NAT gateway resource for multi-zone spanning resources doesn't provide an effective method of zone-resiliency against outages.

Zonal NAT gateway resource for each zone in a region to create zone-resiliency

A zonal promise for zone isolation scenarios exists when a virtual machine instance using a NAT gateway resource is in the same zone as the NAT gateway resource and its public IP addresses. The pattern you want to use for zone isolation is creating a "zonal stack" per availability zone. This "zonal stack" consists of virtual machine instances, a NAT gateway resource with public IP addresses or prefix on a subnet all in the same zone.

Diagram of zonal isolation by creating zonal stacks.

Figure 3: Zonal isolation by creating zonal stacks with the same zone NAT gateway, public IPs, and virtual machines provide the best method of ensuring zone resiliency against outages.

Note

Creating zonal stacks for each availability zone within a region is the most effective method for building zone-resiliency against outages for NAT gateway. However, ths configuration only safeguards the remaining availability zones where the outage did not take place. With this configuration, failure of outbound connectivity from a zone outage is isolated to the specific zone affected. The outage won't affect the other zonal stacks where other NAT gateways are deployed with their own subnets and zonal public IPs.

Integration of inbound with a standard load balancer

If your scenario requires inbound endpoints, you have two options:

Option Pattern Example Pro Con
(1) Align the inbound endpoints with the respective zonal stacks you're creating for outbound. Create a standard load balancer with a zonal frontend. Same failure model for inbound and outbound. Simpler to operate. A common Domain Name System (DNS) name needs to mask individual IP addresses per zone.
(2) Overlay the zonal stacks with a cross-zone inbound endpoint. Create a standard load balancer with a zone-redundant front-end. Single IP address for inbound endpoint. Varying models for inbound and outbound. More complex to operate.

Note

Note that zonal configuration for a load balancer works differently from NAT gateway. The load balancer's availability zone selection is synonymous with its frontend IP configuration's zone selection. For public load balancers, if the public IP in the Load balancer's frontend is zone redundant then the load balancer is also zone-redundant. If the public IP in the load balancer's frontend is zonal, then the load balancer will also be designated to the same zone.

Limitations

  • Zones can't be changed, updated, or created for NAT gateway after deployment.

Next steps