Updates

Author: johndowns

articles/reliability/reliability-app-service.md

@@ -23,7 +23,7 @@ When you deploy Azure App Service, you can create multiple instances of an *App
 
 ::: zone pivot="free-shared-basic"
 
-- [Enable zone redundancy](#availability-zone-support), which requires that you use Premium v3  or Isolated v2 App Service plans and that you have at minimum three instances of the plan. To view more information, make sure that you select the appropriate tier at the top of this page.
+- [Enable zone redundancy](#availability-zone-support), which requires that you use Premium v3 or Isolated v2 App Service plans and that you have at minimum three instances of the plan. To view more information, make sure that you select the appropriate tier at the top of this page.
 
 ::: zone-end
 
@@ -49,7 +49,7 @@ Microsoft-provided SDKs usually handle transient faults. Because you host your o
 
 [!INCLUDE [AZ support description](includes/reliability-availability-zone-description-include.md)]
 
-Azure App Service can be configured as *zone redundant*, which means that your resources are spread across multiple [availability zones](../reliability/availability-zones-overview.md). Spreading across multiple zones helps your production workloads achieve resiliency and reliability. <!-- Not sure what this means -->Availability zone support is a property of the App Service plan.
+Azure App Service can be configured as *zone redundant*, which means that your resources are spread across multiple [availability zones](../reliability/availability-zones-overview.md). Spreading across multiple zones helps your production workloads achieve resiliency and reliability. You configure zone redundancy on App Service plans, and all apps that use the plan are made zone redundant.
 
 Instance spreading with a zone-redundant deployment is determined using the following rules. These rules apply even as the app scales in and out:
 
@@ -58,8 +58,7 @@ Instance spreading with a zone-redundant deployment is determined using the foll
 - Any instance counts beyond 3*N are spread across the remaining one or two zones.
 
 > [!NOTE]
-> In some cases, your workload is hosted on a [scale unit](/azure/app-service/overview-hosting-plans#how-does-my-app-run-and-scale) (also known as a stamp or VMSS compute cluster) that is deployed across two zones rather than three zones. For these cases, the instances are evenly spread across the two zones if the number of instances is divisible by two. Any instance count beyond 2*n is placed in one of the zones. 
-> 
+> In some cases, your workload is hosted on a scale unit (also known as a stamp, or a compute cluster) that's deployed across two availability zones rather than three zones. For these cases, the instances are evenly spread across the two zones if the number of instances is divisible by two. Any instance count beyond 2*n is placed in one of the zones.
 
 When the App Service platform allocates instances for a zone-redundant App Service plan, it uses best effort zone balancing offered by the underlying Azure virtual machine scale sets. An App Service plan is *balanced* if each zone has either the same number of virtual machines, or plus or minus one, in all of the other zones. For more information, see [Zone balancing](/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-use-availability-zones#zone-balancing).
 
@@ -89,13 +88,17 @@ To see which regions support availability zones for App Service Environment v3,
 
 ::: zone pivot="free-shared-basic"
 
-- You must use either the [Premium v2 or Premium v3 plan types](/azure/app-service/overview-hosting-plans). To view more information, make sure that you select the appropriate tier at the top of this page.
+- You must use the [Premium v2, Premium v3, or Isolated v2 plan types](/azure/app-service/overview-hosting-plans). To view more information, make sure that you select the appropriate tier at the top of this page.
 
 ::: zone-end
 
 ::: zone pivot="premium,isolated"
 
-- Availability zones are only supported on the newer App Service stamps. Even if you're using one of the supported regions, if availability zones aren't supported for your resource group, you receive an error. To ensure that your workloads land on a stamp that supports availability zones, you might need to create a new resource group, App Service plan, and App Service app.
+- You must use the [Premium v2, Premium v3, or Isolated v2 plan types](/azure/app-service/overview-hosting-plans).
+
+- Availability zones are supported only on newer App Service scale units. Even if you're using one of the supported regions, if availability zones aren't supported for the scale unit you use then you receive an error when creating a zone-redundant App Service plan.
+
+    The scale units you're assigned to is based on the resource group you deploy an App Service plan to. To ensure that your workloads land on a scale unit that supports availability zones, you might need to create a new resource group and then create a new App Service plan and App Service app within the new resource group.
 
 - You must deploy a minimum of three instances of your plan.
 
@@ -125,54 +128,61 @@ App Service Environment v3 has a specific pricing model for zone redundancy. For
 
 ::: zone-end
 
-
 ### Configure availability zone support
 
+::: zone pivot="free-shared-standard"
+
+- **Create a new App Service plan with zone redundancy.** To deploy a new zone-redundant Azure App Service plan, you must use either the [Premium v2 or Premium v3 plan types](/azure/app-service/overview-hosting-plans). To view more information, make sure that you select the appropriate tier at the top of this page.
+
+::: zone-end
 
 ::: zone pivot="premium"
 
-To deploy a new zone-redundant Azure App Service plan, select the *Zone redundant* option when you deploy the plan.
+- **Create a new App Service plan with zone redundancy.** To deploy a new zone-redundant Azure App Service plan, select the *Zone redundant* option when you deploy the plan.
 
 ::: zone-end
 
 ::: zone pivot="isolated"
 
-To deploy a new zone-redundant Azure App Service Environment, see [Create an App Service Environment](/azure/app-service/environment/creation).
+- **Create a new App Service plan with zone redundancy.** To deploy a new zone-redundant Azure App Service Environment, see [Create an App Service Environment](/azure/app-service/environment/creation).
 
 ::: zone-end
 
-Zone redundancy can only be configured when you create a new App Service plan. If you have an existing App Service plan that isn't zone-redundant, replace it with a new zone-redundant plan. You can't convert an existing App Service plan to use availability zones. Similarly, you can't disable zone redundancy on an existing App Service plan.
+- **Migration.** Zone redundancy can only be configured when you create a new App Service plan. If you have an existing App Service plan that isn't zone-redundant, replace it with a new zone-redundant plan. You can't convert an existing App Service plan to use availability zones.
 
-::: zone pivot="premium,isolated"
+- **Disable zone redundancy.** You can't disable zone redundancy after you create an App Service plan. Instead, you need to create a new plan with zone redundancy disabled and delete the old one.
 
+::: zone pivot="premium,isolated"
 
 ### Capacity planning and management
 
 To prepare for availability zone failure, consider *over-provisioning* the capacity of your App Service plan. Over-provisioning allows the solution to tolerate some degree of capacity loss and still continue to function without degraded performance. To learn more about over-provisioning, see [Manage capacity with over-provisioning](./concept-redundancy-replication-backup.md#manage-capacity-with-over-provisioning).
 
-
 ### Normal operations
 
-**Traffic routing between zones:** During normal operations, traffic is routed between all of your available App Service plan instances across all availability zones.
+- **Traffic routing between zones:** During normal operations, traffic is routed between all of your available App Service plan instances across all availability zones.
+
+- **Data replication between zones:** During normal operations, any state stored in your application's file system is stored in zone-redundant storage, and is synchronously replicated between availability zones.
 
 ### Zone-down experience
 
-Applications that are deployed in a zone-redundant App Service plan continue to run and serve traffic even if multiple zones in the region suffer an outage. However, nonruntime behaviors might still be impacted during an availability zone outage. These behaviors include App Service plan scaling, application creation, application configuration, and application publishing. 
+The following information describes what happens when you have a zone-redundant App Service plan and there's an availability zone outage:
 
+- **Detection and response:** The App Service platform is responsible for detecting a failure in an availability zone and responding. You don't need to do anything to initiate a zone failover.
 
-**Detection and response.** The App Service platform is responsible for detecting a failure in an availability zone and responding. You don't need to do anything to initiate a zone failover.
+- **Active requests:** When an availability zone is unavailable, any requests in progress that are connected to an App Service plan instance in the faulty availability zone are terminated. They need to be retried.
 
-**Active requests.** When an availability zone is unavailable, any requests in progress that are connected to an App Service plan instance in the faulty availability zone are terminated. They need to be retried.
+- **Traffic rerouting:** When a zone is unavailable, Azure App Service detects the lost instances from that zone. It automatically attempts to find new replacement instances. Then, it spreads traffic across the new instances as needed.
 
-**Traffic rerouting.** When a zone is unavailable, Azure App Service detects the lost instances from that zone. It automatically attempts to find new replacement instances. Then, it spreads traffic across the new instances as needed.
+    If you have autoscale configured, and if it decides more instances are needed, autoscale also issues a request to App Service to add more instances. For more information, see [Scale up an app in Azure App Service](../app-service/manage-scale-up.md).
 
-If you have autoscale configured, and if it decides more instances are needed, autoscale also issues a request to App Service to add more instances. For more information, see [Scale up an app in Azure App Service](../app-service/manage-scale-up.md).
+    > [!NOTE]
+    > [Autoscale behavior is independent of App Service platform behavior](/azure/azure-monitor/autoscale/autoscale-overview). Your autoscale instance count specification doesn't need to be a multiple of three.
 
-> [!NOTE]
-> [Autoscale behavior is independent of App Service platform behavior](/azure/azure-monitor/autoscale/autoscale-overview). Your autoscale instance count specification doesn't need to be a multiple of three.
+    > [!IMPORTANT]
+    > There's no guarantee that requests for more instances in a zone-down scenario succeed. The back filling of lost instances occurs on a best-effort basis. If you need guaranteed capacity when an availability zone is lost, you should create and configure your App Service plans to account for losing a zone. You can do that by [overprovisioning the capacity of your App Service plan](#capacity-planning-and-management).
 
-> [!IMPORTANT]
-> There's no guarantee that requests for more instances in a zone-down scenario succeed. The back filling of lost instances occurs on a best-effort basis. If you need guaranteed capacity when an availability zone is lost, you should create and configure your App Service plans to account for losing a zone. You can do that by [overprovisioning the capacity of your App Service plan](#capacity-planning-and-management).
+- **Nonruntime behaviors:** Applications that are deployed in a zone-redundant App Service plan continue to run and serve traffic even if multiple zones in the region suffer an outage. However, nonruntime behaviors might still be impacted during an availability zone outage. These behaviors include App Service plan scaling, application creation, application configuration, and application publishing.
 
 ### Failback