Merge pull request #109610 from christiankuhtz/patch-305

tweak

Author: PRMerger17

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.
@@ -253,9 +274,9 @@ Once a SNAT port releases, it's available for use by any virtual machine on subn
 
 ### Scaling
 
-NAT needs sufficient SNAT port inventory for the complete outbound scenario. Scaling NAT is primarily a function of managing the shared, available SNAT port inventory. Sufficient inventory needs to exist to address the peak outbound flow for all subnets attached to a NAT gateway resource.  You can use public IP addresses or public IP prefixes or both to create SNAT port inventory for usage by the NAT.
+Scaling NAT is primarily a function of managing the shared, available SNAT port inventory. NAT needs sufficient SNAT port inventory for expected peak outbound flows for all subnets attached to a NAT gateway resource.  You can use public IP address resources, public IP prefix resources, or both to create SNAT port inventory.
 
-SNAT maps private addresses to one or more public IP addresses. These public IP addresses can be provided as public IP address resources or public IP prefix resources or both.  A NAT gateway resource will use 64,000 ports (SNAT ports) per configured IP address for this translation.  If a public IP prefix resource is provided, each IP address within the prefix is provided ports to the SNAT port inventory. These SNAT ports become the available inventory for the private to public flow mapping. And adding more IP addresses increases the available inventory SNAT ports. NAT gateway resources can scale up to 16 IP addresses and 1M SNAT ports.  TCP and UDP are separate SNAT port inventories and unrelated.
+SNAT maps private addresses to one or more public IP addresses, rewriting source address and source port in the processes. A NAT gateway resource will use 64,000 ports (SNAT ports) per configured public IP address for this translation. NAT gateway resources can scale up to 16 IP addresses and 1M SNAT ports. If a public IP prefix resource is provided, each IP address within the prefix is providing SNAT port inventory. And adding more public IP addresses increases the available inventory SNAT ports. TCP and UDP are separate SNAT port inventories and unrelated.
 
 NAT gateway resources opportunistically reuse source ports. For scaling purposes, you should assume each flow requires a new SNAT port and scale the total number of available IP addresses for outbound traffic.