Change AvZone recommendations

Author: msjuergent

articles/sap/workloads/high-availability-zones.md

@@ -17,9 +17,9 @@ Deployment of the different SAP architecture layers across [Azure Availability Z
 
 As of the typical SAP NetWeaver or S/4HANA architecture, you need to protect three different layers:
 
-- SAP application layer, which can be one to a few dozen Virtual Machines (VM) You want to minimize the chance of VMs getting deployed on the same host server. You also want those VMs in an acceptable proximity to the DBMS layer to keep network latency in an acceptable window
+- SAP application layer, which can be one to a few dozen Virtual Machines (VM) You want to minimize the chance of VMs getting deployed on the same host server. You also want those VMs in an acceptable proximity to the Database (DBMS) layer to keep network latency in an acceptable window
 - SAP ASCS/SCS layer that is representing a single point of failure in the SAP NetWeaver and S/4HANA architecture. You usually look at two VMs that you want to cover with a failover framework. Therefore, these VMs should be allocated in different infrastructure fault domains
-- SAP Database (DBMS) layer, which represents a single point of failure as well. In the usual cases, it consists out of two VMs that are covered by a failover framework. Therefore, these VMs should be allocated in different infrastructure fault domains. Exceptions are SAP HANA scale-out deployments where more than two VMs are can be used
+- SAP DBMS layer, which represents a single point of failure as well. In the usual cases, it consists out of two VMs that are covered by a failover framework. Therefore, these VMs should be allocated in different infrastructure fault domains. Exceptions are SAP HANA scale-out deployments where more than two VMs are can be used
 
 The major differences between deploying your critical VMs through availability sets or Availability Zones are:
 
@@ -34,20 +34,21 @@ As another resiliency deployment functionality, Azure introduced [Virtual machin
 
 Consider the following when you use Availability Zones:
 
-- The maximum network roundtrip latency between Azure Availability Zones is stated in the document [Regions and availability zones](../../availability-zones/az-overview.md).
-- The experienced network roundtrip latency isn't necessarily indicative to the real geographical distance of the datacenters that form the different zones. The network roundtrip latency is also influenced by the cable connectivities and the routing of the cables between these different datacenters.
+- More information about Azure Availability Zones is presented in the document [Regions and availability zones](../../availability-zones/az-overview.md).
+- The experienced network roundtrip latency isn't necessarily indicative to the real geographical distance of the datacenters that form the different zones. The network roundtrip latency is also influenced by the cable connectivities and the routing of the cables between these different datacenters. 
 - Availability Zones aren't an ideal DR solution. Natural disasters can cause widespread damage in world regions, including heavy damage to power infrastructures. The distances between various zones might not be large enough to constitute a proper DR solution.
-- The network latency across Availability Zones isn't the same in all Azure regions. In some cases, you can deploy and run the SAP application layer across different zones because the network latency from one zone to the active DBMS VM is acceptable. But in some Azure regions, the latency between the active DBMS VM and the SAP application instance, when deployed in different zones, might not be acceptable for SAP business processes. In these cases, the deployment architecture needs to be different, with an active/active architecture for the application, or an active/passive architecture where cross-zone network latency is too high.
+- The network latency across Availability Zones isn't the same in all Azure regions. Even within an Azure region, the network latencies between the different zones may vary. Though even in the worst case, synchronous replication on the database level based on HANA System Replication or SQL Server Always On is going to work without impacting the scalability of the workload. 
 - When deciding where to use Availability Zones, base your decision on the network latency between the zones. Network latency plays an important role in two areas:
-  - Latency between the two DBMS instances that need to have synchronous replication. The higher the network latency, the more likely it affects the scalability of your workload.
-  - The difference in network latency between a VM running an SAP dialog instance in-zone with the active DBMS instance and a similar VM in another zone. As this difference increases, the influence on the running time of business processes and batch jobs also increases, dependent on whether they run in-zone with the DBMS or in a different zone.
+  - Latency between the two DBMS instances that need to have synchronous replication. Based on largest NetWeaver and S/4HANA deployments between zones with the largest network latencies (still less than 1.5 milliseconds), this consideration can be neglected
+  - The difference in network latency between a VM running an SAP dialog instance in-zone with the active DBMS instance and a similar VM in another zone. As this difference increases, the influence on the running time of business processes and batch jobs also increases, dependent on whether they run in-zone with the DBMS or in a different zone (see later in this article)
 
 When you deploy Azure VMs across Availability Zones and establish failover solutions within the same Azure region, some restrictions apply:
 
 - You must use [Azure Managed Disks](https://azure.microsoft.com/services/managed-disks/) when you deploy to Azure Availability Zones. 
 - The mapping of zone enumerations to the physical zones is fixed on an Azure subscription basis. If you're using different subscriptions to deploy your SAP systems, you need to define the ideal zones for each subscription. If you want to compare the logical mapping of your different subscriptions, consider the [Avzone-Mapping script](https://github.com/Azure/SAP-on-Azure-Scripts-and-Utilities/tree/main/AvZone-Mapping)
 - You can't deploy Azure availability sets within an Azure Availability Zone unless you use [Azure Proximity Placement Group](/azure/virtual-machines/co-location). The way how you can deploy the SAP DBMS layer and the central services across zones and at the same time deploy the SAP application layer using availability sets and still achieve close proximity of the VMs is documented in the article [Azure Proximity Placement Groups for optimal network latency with SAP applications](proximity-placement-scenarios.md). If you aren't using Azure proximity placement groups, you need to choose one or the other as a deployment framework for virtual machines.
 - You can't use an [Azure Basic Load Balancer](../../load-balancer/load-balancer-overview.md) to create failover cluster solutions based on Windows Server Failover Clustering or Linux Pacemaker. Instead, you need to use the [Azure Standard Load Balancer SKU](../../load-balancer/load-balancer-standard-availability-zones.md).
+- You need to deploy zonal version of [ExpressRoute Gateway](../../expressroute/expressroute-about-virtual-network-gateways.md), [VPN Gateway](../../vpn-gateway/about-gateway-skus.md), and [Standard Public IP addresses](../../virtual-network/ip-services/private-ip-addresses.md) to get the zonal protection you desire
 
 ## The ideal Availability Zones combination