az clarifications

Author: christiankuhtz

articles/virtual-network/nat-gateway-resource.md

@@ -174,26 +174,47 @@ NAT gateways take precedence over outbound scenarios of the subnet. Basic load b
 
 ### Availability Zones
 
-Even without availability zones, NAT is resilient and can survive multiple infrastructure component failures. When availability zones are part of your scenario, you should configure NAT for a specific zone.  The control plane operations and data plane are constrained to the specified zone. Failure in a zone other than where your scenario exists is expected to be without impact to NAT. Outbound traffic from virtual machines in the same zone will fail because of zone isolation.
+#### Zone isolation with zonal stacks
 
 <p align="center">
   <img src="media/nat-overview/az-directions.svg" width="425" title="Virtual Network NAT with availability zones">
 </p>
 
-*Figure: Virtual Network NAT with zone isolation*
+*Figure: Virtual Network NAT with zone isolation, creating multiple "zonal stacks"*
 
-A zone-isolated NAT gateway requires IP addresses to match the zone of the NAT gateway. NAT gateway resources with IP addresses from a different zone or without a zone are unsupported.
+Even without availability zones, NAT is resilient and can survive multiple infrastructure component failures.  Availability zones build on this resiliency with zone isolation scenarios for NAT.
 
-Virtual networks and subnets are regional and not zonal aligned. A VM must be in the same zone as NAT gateway for a zonal promise of outbound connections. Zone isolation is created by creating a zonal "stack" per availability zone. A zonal promise won't exist when crossing zones of a zonal NAT gateway or using a regional NAT gateway with zonal VMs.
+Virtual networks and their subnets are regional constructs.  Subnets are not aligned with a zone.
 
+A zonal promise for zone isolation 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, NAT gateway resources, public IP address and/or prefix resources on a subnet that is assumed to be serving only the same zone.   The control plane operations and data plane are then constrained to the specified zone. 
+
+Failure in a zone other than where your scenario exists is expected to be without impact to NAT. Outbound traffic from virtual machines in the same zone will fail because of zone isolation.  
+
+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 zonal frontend. | Same health model and failure mode for inbound and outbound. Simpler to operate. | Individual IP addresses per zone may need to be masked by a common DNS name. |
+| (2) | **Overlay** the zonal stacks with a cross-zone inbound endpoint. | Create a standard load balancer with zone-redundant frontend. | Single IP address for inbound endpoint. | Varying health model and failure modes for inbound and outbound.  More complex to operate. |
+
+>[!NOTE]
+> A zone-isolated NAT gateway requires IP addresses to match the zone of the NAT gateway. NAT gateway resources with IP addresses from a different zone or without a zone aren't allowed.
+
+#### Cross-zone outbound scenarios not supported
 
 <p align="center">
   <img src="media/nat-overview/az-directions2.svg" width="425" title="zone-spanning Virtual Network NAT">
 </p>
 
 *Figure: Virtual Network NAT not compatible with zone-spanning subnet*
 
-Virtual Network NAT is unable to provide a zonal promise with a zone-spanning subnet.  NAT doesn't support zone-redundancy and doesn't replicate flow state across zones. Use zone-isolation instead.
+You can't achieve a zonal promise with NAT gateway resources when virtual machine instances are deployed in multiple zones within the same subnet.   And even if there were multiple zonal NAT gateways attached to a subnet, the virtual machine instance wouldn't know which NAT gateway resource to select.
+
+A zonal promise does't exist when 
+a) the zone of a virtual machine instance and the zones of a zonal NAT gateway are not aligned, or
+b) a regional NAT gateway resource is used with zonal virtual machine instances.
+
+While the scenario will appear to work, its health model and failure mode is undefined from an availability zone point of view. Consider going with zonal stacks or all regional instead.
 
 >[!NOTE]
 >The zones property of a NAT gateway resource isn't mutable.  Redeploy NAT gateway resource with the intended regional or zone preference.