edits

anaharris-ms · anaharris-ms · commit 644ce8a61dda · 2022-09-15T12:35:07.000-04:00
diff --git a/articles/availability-zones/migrate-workload-aks-mysql.md b/articles/availability-zones/migrate-workload-aks-mysql.md
@@ -12,9 +12,9 @@ ms.custom: references_regions
  
 # Migrate Azure Kubernetes Service (AKS) and MySQL Flexible Server workloads to availability zone support 
 
-This guide describes how to migrate a Azure Kubernetes Service and MySQL Flexible Server workload to complete availability zone support across all dependent services. For complete list of all workload dependencies, see [Workload service dependencies](#workload-service-dependencies).  
+This guide describes how to migrate an Azure Kubernetes Service and MySQL Flexible Server workload to complete availability zone support across all dependent services. For complete list of all workload dependencies, see [Workload service dependencies](#workload-service-dependencies).  
 
-Availability zone support for this workload must be enabled during the creation of your AKS cluster or MySQL Flexible Server. This means that a redeployment of these resources is required if you want availability zone support for an existing AKS cluster and MySQL Flexible Server. 
+Availability zone support for this workload must be enabled during the creation of your AKS cluster or MySQL Flexible Server. If you want availability zone support for an existing AKS cluster and MySQL Flexible Server, you'll need to redeploy those resources. 
 
 This migration guidance focuses mainly on the infrastructure and availability considerations of running the following architecture on Azure:
 
@@ -33,46 +33,46 @@ The AKS and MySQL workload architecture consists of the following component depe
 
 ### Azure Kubernetes Service (AKS)
 
-- *Zonal* : The system node pool and user node pools are zonal when you pre-select the zones in which the node pools are deployed during creation time. We recommend that you pre-select all three zones for better resiliency. Additional user node pools that support availability zones can be added to an existing AKS cluster and by supplying a value for the `zones` parameter. 
+- *Zonal* : The system node pool and user node pools are zonal when you pre-select the zones in which the node pools are deployed during creation time. We recommend that you pre-select all three zones for better resiliency. More user node pools that support availability zones can be added to an existing AKS cluster and by supplying a value for the `zones` parameter. 
 
 - *Zone-redundant*: Kubernetes control plane components such as *etcd*, *API server*, *Scheduler*, and *Controller Manager*  are automatically replicated or distributed across zones.  
 
     >[!NOTE]
-    >To enable zone-redundancy of the AKS cluster control plane components, you must define your default system node pool with zones when you create an AKS cluster. Adding additional zonal node pools to an existing non-zonal AKS cluster won't make the AKS cluster zone-redundant, because that action doesn't distribute the control plane components across zones after-the-fact.  
+    >To enable zone-redundancy of the AKS cluster control plane components, you must define your default system node pool with zones when you create an AKS cluster. Adding more zonal node pools to an existing non-zonal AKS cluster won't make the AKS cluster zone-redundant, because that action doesn't distribute the control plane components across zones after-the-fact.  
 
 ### Azure Database for MySQL Flexible Server 
 
-- *Zonal*: This availability mode means that a standby server is always available within the same zone as the primary server. While this option reduces failover time and network latency, it's less resilient due to a single zone outage impacting both the primary and standby servers. 
+- *Zonal*: The zonal availability mode means that a standby server is always available within the same zone as the primary server. While this option reduces failover time and network latency, it's less resilient due to a single zone outage impacting both the primary and standby servers. 
     
-- *Zone-redundant*: This availability mode means that a standby server is always available within another zone in the same region as the primary server. This means that you have two zones enabled for zone redundancy for the primary and standby servers. We recommend this configuration for better resiliency. 
+- *Zone-redundant*: The zone-redundant availability mode means that a standby server is always available within another zone in the same region as the primary server.  Two zones will be enabled for zone redundancy for the primary and standby servers. We recommend this configuration for better resiliency. 
 
 
 ### Azure Standard Load Balancer or Azure Application Gateway 
 
 #### Standard Load Balancer
-To understand considerations related to Standard Load Balancer resources, see [Load Balancer and Availablity Zones](../load-balancer/load-balancer-standard-availability-zones.md). 
+To understand considerations related to Standard Load Balancer resources, see [Load Balancer and Availability Zones](../load-balancer/load-balancer-standard-availability-zones.md). 
 
-- *Zone-redundant*: Choosing zone-redundancy is the recommended way to configure your Frontend IP with your existing Load Balancer. The zone-redundant front-end corresponds with the AKS cluster back-end pool which is distributed across multiple zones. 
+- *Zone-redundant*: Choosing zone-redundancy is the recommended way to configure your Frontend IP with your existing Load Balancer. The zone-redundant front-end corresponds with the AKS cluster back-end pool, which is distributed across multiple zones. 
 
 - *Zonal*: If you're pinning your node pools to specific zones such as zone 1 and 2, you can pre-select zone 1 and 2 for your Frontend IP in the existing Load Balancer. The reason why you may want to pin your node pools to specific zones could be due to the availability of specialized VM SKU series such as M-series.
 
 #### Azure Application Gateway 
 
 Using the Application Gateway Ingress Controller add-on with your AKS cluster is supported only on Application Gateway v2 SKUs (Standard and WAF). To understand further considerations related to Azure Application Gateway, see [Scaling Application Gateway v2 and WAF v2](../application-gateway/application-gateway-autoscaling-zone-redundant.md).
 
-*Zonal*: To leverage the benefits of availability zones, we recommend that the Application Gateway resource be created in multiple zones, such as zone 1, 2, and 3. Select all three zones for best intra-region resiliency strategy. However, to correspond to your backend node pools, you may pin your node pools to specific zones by pre-selecting zone 1 and 2 during the creation of your App Gateway resource. The reason why you may want to pin your node pools to specific zones could be due to the availability of specialized VM SKU series such as `M-series`.
+*Zonal*: To use the benefits of availability zones, we recommend that the Application Gateway resource be created in multiple zones, such as zone 1, 2, and 3. Select all three zones for best intra-region resiliency strategy. However, to correspond to your backend node pools, you may pin your node pools to specific zones by pre-selecting zone 1 and 2 during the creation of your App Gateway resource. The reason why you may want to pin your node pools to specific zones could be due to the availability of specialized VM SKU series such as `M-series`.
 
 #### Zone Redundant Storage (ZRS) 
 
-- We recommend that your AKS cluster is configured with managed ZRS disks because they are zone-redundant resources. Volumes can be scheduled on all zones.  
+- We recommend that your AKS cluster is configured with managed ZRS disks because they're zone-redundant resources. Volumes can be scheduled on all zones.  
 
 - Kubernetes is aware of Azure availability zones since version 1.12. You can deploy a `PersistentVolumeClaim` object referencing an Azure Managed Disk in a multi-zone AKS cluster. Kubernetes will take care of scheduling any pod that claims this PVC in the correct availability zone. 
 
 - For Azure Database for SQL, we recommend that the data and log files are hosted in zone-redundant storage (ZRS). These files are replicated to the standby server via the storage-level replication available with ZRS. 
 
 #### Azure Firewall 
 
-*Zonal*: To leverage the benefits of availability zones, we recommend that the Application Gateway resource be created in multiple zones, such as zone 1, 2, and 3. We recommend that you select all three zones for best intra-region resiliency strategy.  
+*Zonal*: To use the benefits of availability zones, we recommend that the Application Gateway resource be created in multiple zones, such as zone 1, 2, and 3. We recommend that you select all three zones for best intra-region resiliency strategy.  
 
 #### Azure Bastion 
 
@@ -88,29 +88,29 @@ Using the Application Gateway Ingress Controller add-on with your AKS cluster is
 
 #### Azure Active Directory (AD)
 
-*Global*: Azure AD is a global service with multiple levels of internal redundancy and automatic recoverability. Azure AD is deployed in over thirty datacenters around the world that provide  availability zones where present. This number is growing rapidly as additional regions are deployed. 
+*Global*: Azure AD is a global service with multiple levels of internal redundancy and automatic recoverability. Azure AD is deployed in over 30 datacenters around the world that provide  availability zones where present. This number is growing rapidly as more regions are deployed. 
 
 #### Azure Key Vault 
 
-*Regional*: Azure Key Vault is deployed in a region. To maintain high durability of your keys and secrets, the contents of your key vault are replicated within the region, as well as to a secondary region within the same geography.
+*Regional*: Azure Key Vault is deployed in a region. To maintain high durability of your keys and secrets, the contents of your key vault are replicated within the region and to a secondary region within the same geography.
 
 *Zone-redundant*: For Azure regions with availability zones and no region pair, Key Vault uses zone-redundant storage (ZRS) to replicate the contents of your key vault three times within the single location/region. 
 
 ## Workload considerations
 
 ### Azure Kubernetes Service (AKS)
 
-- Pods can communicate with other pods, regardless of which node or the availability zone in which the pod lands on the node. Your application may experience higher response time if the pods are located in different availability zones. While the extra round-trip latencies between pods is expected to fall within an acceptable range for most applications, there are application scenarios which require low latency, especially for a chatty communication pattern between pods.  
+- Pods can communicate with other pods, regardless of which node or the availability zone in which the pod lands on the node. Your application may experience higher response time if the pods are located in different availability zones. While the extra round-trip latencies between pods are expected to fall within an acceptable range for most applications, there are application scenarios which require low latency, especially for a chatty communication pattern between pods.  
 
 - We recommend that you test your application to ensure it performs well across availability zones.  
 
-- For performance reasons such low latency, pods can be co-located in the same data center within the same availability zone. To do this, you can create user node pools with a unique zone and proximity placement group. You can add a proximity placement group (PPG) to an existing AKS cluster by creating a new agent node pool and specifying the PPG. Use Pod Topology Spread Constraints to control how pods are spread in your AKS cluster across availability zones, nodes and regions.  
+- For performance reasons such low latency, pods can be co-located in the same data center within the same availability zone. To co-locate pods in the same data center within the same availability zone, you can create user node pools with a unique zone and proximity placement group. You can add a proximity placement group (PPG) to an existing AKS cluster by creating a new agent node pool and specifying the PPG. Use Pod Topology Spread Constraints to control how pods are spread in your AKS cluster across availability zones, nodes and regions.  
 
-- After pods that require low latency communication are co-located in the same availability zone, communications between the pods are not direct but are channeled through a service that defines a logical set of pods in your AKS cluster. Pods can be configured to talk to AKS and the communication to the service will be automatically load-balanced to all the pods that are members of the service.  
+- After pods that require low latency communication are co-located in the same availability zone, communications between the pods aren't direct. Instead, pod communications are channeled through a service that defines a logical set of pods in your AKS cluster. Pods can be configured to talk to AKS and the communication to the service will be automatically load-balanced to all the pods that are members of the service.  
 
 - To take advantage of availability zones, node pools contain underlying VMs that are zonal resources. To support applications that have different compute or storage demands, you can create user node pools with specific VM sizes when you create the user node pool.  
 
-    For example, you may decide to use the `Standard_M32ms` under the `M-series` for your user nodes because the microservices in your application require high throughput, low latency, and memory optimized VM sizes that provide high vCPU counts and large amounts of memory. When you select the VM size in the Azure Portal, depending on the region you are deploying this, you may see that this VM size is supported only in zone 1 and 2. You accept this resiliency configuration as a trade-off for high performance.  
+    For example, you may decide to use the `Standard_M32ms` under the `M-series` for your user nodes because the microservices in your application require high throughput, low latency, and memory optimized VM sizes that provide high vCPU counts and large amounts of memory. Depending on the deployment region, when you select the VM size in the Azure portal, you may see that this VM size is supported only in zone 1 and 2. You can accept this resiliency configuration as a trade-off for high performance.  
 
 - You can't change the VM size of a node pool after you create it. For more information on node pool limitations, see [Limitations](../aks/use-multiple-node-pools.md#limitations). 
 
@@ -127,23 +127,23 @@ The implication of deploying your node pools in specific zones, such as zone 1 a
 
 - You can't update an existing Premium cache to use zone redundancy. To use zone redundancy, you must recreate the Azure Cache for Redis. 
 
-- To achieve optimal resiliency, we recommend that you create your Azure Cache for Redis with three or more replicas so that you can distribute the replicas across three availability zones. 
+- To achieve optimal resiliency, we recommend that you create your Azure Cache for Redis with three, or more replicas so that you can distribute the replicas across three availability zones. 
 
 :::image type="content" alt-text="Picture showing three replicas for Azure Cache for Redis" source="./media/migrate-workload-aks-mysql/redis-create-replicas.png":::
 
 
 ## Disaster recovery considerations
 
-*Availability zones* are generally used for better resiliency to achieve high availability of your workload within the primary region of your deployment. 
+*Availability zones* are used for better resiliency to achieve high availability of your workload within the primary region of your deployment. 
 
-*Disaster Recovery* consists of recovery operations and practices defined in your business continuity plan, which is about how your workload recovers during a disruptive event and fully recovers after the event. Consider extending your deployment to an alternative region. 
+*Disaster Recovery* consists of recovery operations and practices defined in your business continuity plan. Your business continuity plan addresses both how your workload recovers during a disruptive event and how it fully recovers after the event. Consider extending your deployment to an alternative region. 
 
 
 :::image type="content" alt-text="Picture showing secondary region deployment architecture" source="./media/migrate-workload-aks-mysql/disaster-recovery.png":::
 
 For your application tier, please review the business continuity and disaster recovery considerations for AKS in this article. 
 
-- Consider running multiple AKS clusters in alternative regions. The alternative region can either use a secondary paired region, or where there is no region pairing for your primary region, you are encouraged to select an alternative region based on your consideration for available services, capacity, geographical proximity, and data sovereignty. Please review this Azure regions decision guide. Also review the deployment stamp pattern. 
+- Consider running multiple AKS clusters in alternative regions. The alternative region can use a secondary paired region. Or, where there's no region pairing for your primary region, you can select an alternative region based on your consideration for available services, capacity, geographical proximity, and data sovereignty. Please review the [Azure regions decision guide](/azure/cloud-adoption-framework/migrate/azure-best-practices/multiple-regions). Also review the [deployment stamp pattern](/azure/architecture/patterns/deployment-stamp). 
 
 - You have the option of configuring active-active, active-standby, active-passive for your AKS clusters. 
 
diff --git a/articles/availability-zones/overview.md b/articles/availability-zones/overview.md
@@ -14,7 +14,7 @@ ms.custom: references_regions
 
 **Resiliency** is a system’s ability to recover from failures and continue to function. It’s not only about avoiding failures but also involves responding to failures in a way that minimizes downtime or data loss. Because failures can occur at various levels, it’s important to have protection for all types based on your service availability requirements. Resiliency in Azure supports and advances capabilities that respond to outages in real time to ensure continuous service and data protection assurance for mission-critical applications that require near-zero downtime and high customer confidence.
 
-Azure includes built-in resiliency services that you can leverage and manage based on your business needs. Whether it’s a single hardware node failure, a rack level failure, a datacenter outage, or a large-scale regional outage, Azure provides solutions that improve resiliency. For example, availability sets ensure that the virtual machines deployed on Azure are distributed across multiple isolated hardware nodes in a cluster. Availability zones protect customers’ applications and data from datacenter failures across multiple physical locations within a region. **Regions** and **availability zones** are central to your application design and resiliency strategy and are discussed in greater detail later in this article.
+Azure includes built-in resiliency services that you can use and manage based on your business needs. Whether it’s a single hardware node failure, a rack level failure, a datacenter outage, or a large-scale regional outage, Azure provides solutions that improve resiliency. For example, availability sets ensure that the virtual machines deployed on Azure are distributed across multiple isolated hardware nodes in a cluster. Availability zones protect customers’ applications and data from datacenter failures across multiple physical locations within a region. **Regions** and **availability zones** are central to your application design and resiliency strategy and are discussed in greater detail later in this article.
 
 ## Resiliency requirements
 
