Merge pull request #210205 from jelledruyts/jelledruyts/ase-zones

Clarify min instance count on Zone Redundant ASEv3

Author: prmerger-automator[bot]

articles/app-service/environment/overview.md

@@ -69,7 +69,7 @@ A benefit of using an App Service Environment instead of a multi-tenant service
 App Service Environment v3 differs from earlier versions in the following ways:
 
 - There are no networking dependencies on the customer's virtual network. You can secure all inbound and outbound traffic and route outbound traffic as you want. 
-- You can deploy an App Service Environment v3 that's enabled for zone redundancy. You set zone redundancy only during creation and only in regions where all App Service Environment v3 dependencies are zone redundant. 
+- You can deploy an App Service Environment v3 that's enabled for zone redundancy. You set zone redundancy only during creation and only in regions where all App Service Environment v3 dependencies are zone redundant. In this case, each App Service Plan on the App Service Environment will need to have a minimum of three instances so that they can be spread across zones. For more information, see [Migrate App Service Environment to availability zone support](../../availability-zones/migrate-app-service-environment.md).
 - You can deploy an App Service Environment v3 on a dedicated host group. Host group deployments aren't zone redundant. 
 - Scaling is much faster than with an App Service Environment v2. Although scaling still isn't immediate, as in the multi-tenant service, it's a lot faster.
 - Front-end scaling adjustments are no longer required. App Service Environment v3 front ends automatically scale to meet your needs and are deployed on better hosts.

articles/availability-zones/migrate-app-service-environment.md

@@ -19,12 +19,12 @@ This guide describes how to migrate an App Service Environment from non-availabi
 
 Azure App Service Environment can be deployed across [Availability Zones (AZ)](../availability-zones/az-overview.md) to help you achieve resiliency and reliability for your business-critical workloads. This architecture is also known as zone redundancy.
 
-When you configure to be zone redundant, the platform automatically spreads the instances of the Azure App Service plan across all three zones in the selected region. If you specify a capacity larger than three, and the number of instances is divisible by three, the instances are spread evenly. Otherwise, instance counts beyond 3*N are spread across the remaining one or two zones.
+When you configure to be zone redundant, the platform automatically spreads the instances of the Azure App Service plan across all three zones in the selected region. This means that the minimum App Service Plan instance count will always be three. If you specify a capacity larger than three, and the number of instances is divisible by three, the instances are spread evenly. Otherwise, instance counts beyond 3*N are spread across the remaining one or two zones.
 
 ## Prerequisites
 
 - You configure availability zones when you create your App Service Environment.
-  - All App Service plans created in that App Service Environment will automatically be zone redundant.
+  - All App Service plans created in that App Service Environment will need a minimum of 3 instances and those will automatically be zone redundant.
 - You can only specify availability zones when creating a **new** App Service Environment. A pre-existing App Service Environment can't be converted to use availability zones.
 - Availability zones are only supported in a [subset of regions](../app-service/environment/overview.md#regions).