Merge pull request #297508 from anaharris-ms/reliability-remove-zone-pivots

[UPDATE] Reliability: Clarify AZ configuration for app service

Author: denrea

articles/reliability/reliability-app-service.md

@@ -6,35 +6,30 @@ ms.author: anaharris
 ms.topic: reliability-article
 ms.custom: subject-reliability
 ms.service: azure-app-service
-ms.date: 01/15/2025
+ms.date: 04/04/2025
 zone_pivot_groups: app-service-sku
 #customer intent: As an engineer responsible for business continuity, I want to understand how Azure App Service works from a reliability perspective.
 ---
 
 # Reliability in Azure App Service
 
-This article describes reliability support in [Azure App Service](../app-service/overview.md). It covers both intra-regional resiliency with [availability zones](#availability-zone-support) and information on [multi-region deployments](#multi-region-support). 
-
-Resiliency is a shared responsibility between you and Microsoft. This article also covers ways for you to build a resilient solution that meets your needs.
+This article describes reliability support in [Azure App Service](../app-service/overview.md), covering intra-regional resiliency with [availability zones](#availability-zone-support), [multi-region deployments](#multi-region-support), and transient fault handling.
 
 Azure App Service is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends. Azure App Service adds the power of Microsoft Azure to your application, with capabilities for security, load balancing, autoscaling, and automated management. To explore how Azure App Service can bolster the reliability and resiliency of your application workload, see [Why use App Service?](../app-service/overview.md#why-use-app-service)
 
 When you deploy Azure App Service, you can create multiple instances of an *App Service plan*, which represents the compute workers that run your application code. For more information, see [Azure App Service plan](/azure/app-service/overview-hosting-plans). Although the platform makes an effort to deploy the instances across different fault domains, it doesn't automatically spread the instances across availability zones.
 
 ## Production deployment recommendations
 
-For production deployments, you should:
-
 ::: zone pivot="free-shared-basic"
 
-- Use premium v3 App Service plans.
-- [Enable zone redundancy](#availability-zone-support), which requires your App Service plan to use a minimum of three instances.
+[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
 
 ::: zone pivot="premium,isolated"
 
-- [Enable zone redundancy](#availability-zone-support), which requires your App Service plan to use a minimum of three instances.
+[Enable zone redundancy](#availability-zone-support), which requires your App Service plan to use a minimum of three instances.
 
 ::: zone-end
 
@@ -54,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. When you configure zone redundancy on App Service plans, 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:
 
@@ -63,21 +58,26 @@ 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).
 
 For App Service plans that aren't configured as zone redundant, virtual machine instances aren't resilient to availability zone failures. They can experience downtime during an outage in any zone in that region.
 
 ### Regions supported
 
-::: zone pivot="free-shared-basic,premium"
+::: zone pivot="free-shared-basic"
 
-Zone-redundant App Service plans can be deployed in [any region that supports availability zones](./regions-list.md).
+Zone-redundant App Service plans require that you use the Premium v2 or v3 tier and can be deployed in [any region that supports availability zones](./regions-list.md). To view more information, make sure that you select the appropriate tier at the top of this page.
 
 ::: zone-end
 
+::: zone pivot="premium"
+
+Zone-redundant App Service plans can be deployed in [any region that supports availability zones](./regions-list.md).
+
+::: zone-end
+ 
 ::: zone pivot="isolated"
 
 To see which regions support availability zones for App Service Environment v3, see [Regions](../app-service/environment/overview.md#regions).
@@ -86,21 +86,29 @@ To see which regions support availability zones for App Service Environment v3,
 
 ### Requirements
 
-::: zone pivot="free-shared-basic,premium"
-
-- You must use either the [Premium v2 or Premium v3 plan types](/azure/app-service/overview-hosting-plans).
+::: zone pivot="free-shared-basic"
 
-- Availability zones are only supported on the newer App Service footprint. 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.
+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"
 
+- 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.
 
+::: zone-end
+
+::: zone pivot="premium,isolated"
+
 ### Considerations
 
-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. 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. Zone redundancy for App Service plans only ensures continued uptime for deployed applications.
+During an availability zone outage, some aspects of Azure App Service might be impacted even though the application continues to serve traffic. These behaviors include App Service plan scaling, application creation, application configuration, and application publishing.
 
 ### Cost
 
@@ -120,55 +128,63 @@ App Service Environment v3 has a specific pricing model for zone redundancy. For
 
 ::: zone-end
 
-::: zone pivot="premium,isolated"
-
 ### Configure availability zone support
 
+::: zone pivot="free-shared-basic"
+
+- **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 pivot="premium,isolated"
-
-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-end
+- **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 integration runtime. 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).
+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
+The following information describes what happens when you have a zone-redundant App Service plan and all availability zones are operational:
 
-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
 
-**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.
+The following information describes what happens when you have a zone-redundant App Service plan and there's an availability zone outage:
 
-**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.
+- **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.
 
-**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.
+- **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.
 
-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).
+- **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.
 
-> [!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.
+    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.
+
+    > [!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