Apply suggestions from proofread

Co-authored-by: Courtney Wales <[email protected]>

Author: v-stsavell

articles/app-service/environment/creation.md

@@ -37,7 +37,7 @@ You can select *single zone*, *zone redundant*, or *host group* for the deployme
 
 In a zone-redundant App Service Environment, your apps are distributed across the maximum number of available zones, up to three, within the same region. Zone redundancy is available in regions that support availability zones. With this deployment type, your App Service plan must include at least two instances to ensure redundancy across zones. You can scale up App Service plans by adding one or more instances at a time. Scaling doesn't have to be in units of two or three. However, the app is only balanced across all availability zones when the total number of instances are multiples of two or three, depending on the number of available zones. To view the number of available zones for your App Service Environment, see the *Maximum available zones* property in the **Configuration** blade of the Azure portal. If the value is two or three, your App Service Environment is zone redundant.
 
-A zone-redundant deployment provides three or four times the infrastructure, depending on the maximum number of available zones. This redundancy ensures that workloads remain available even if one zone experiences an outage. There's no added charge to have a zone-redundant App Service Environment. For more information about zone redundancy, see [Regions and availability zones](../../reliability/reliability-app-service.md?pivots=isolated).
+A zone-redundant deployment provides three or four times the infrastructure, depending on the maximum number of available zones. This redundancy ensures that workloads remain available even if one zone experiences an outage. There's no added charge to have a zone-redundant App Service Environment. For more information about zone redundancy, see [Reliability in App Service](../../reliability/reliability-app-service.md?pivots=isolated).
 
 In a host group deployment, your apps are deployed onto a dedicated host group. The dedicated host group isn't zone redundant. In a host group deployment, you can install and use your App Service Environment on dedicated hardware. There's no minimum instance charge for using App Service Environment on a dedicated host group. However, you must pay for the host group when you provision the App Service Environment. You also pay a discounted App Service plan rate as you create your plans and scale out.
 
@@ -49,7 +49,7 @@ To create an App Service Environment in the Azure portal, complete the following
 
 1. Search Azure Marketplace for *App Service Environment v3*.
 
-1. From the **Basics** tab, for **Subscription**, select the subscription. For **Resource Group**, select or create the resource group, and enter the name of your App Service Environment. For **Virtual IP**, select **Internal** if you want your inbound address to be an address in your subnet. Select **External** if you want your inbound address to face the public internet. For **App Service Environment Name**, enter a name. The name must be no more than 36 characters. The name that you choose will also be used for the domain suffix. For example, if the name that you choose is *contoso*, and you have an internal VIP, the domain suffix is `contoso.appserviceenvironment.net`. If the name that you choose is *contoso*, and you have an external VIP, the domain suffix is `contoso.p.azurewebsites.net`. 
+1. From the **Basics** tab, for **Subscription**, select the subscription. For **Resource Group**, select or create the resource group, and enter the name of your App Service Environment. For **Virtual IP**, select **Internal** if you want your inbound address to be an address in your subnet. Select **External** if you want your inbound address to face the public internet. For **App Service Environment Name**, enter a name. The name must be no more than 36 characters. The name that you choose is also used for the domain suffix. For example, if the name that you choose is *contoso* and you have an internal VIP, the domain suffix is `contoso.appserviceenvironment.net`. If the name that you choose is *contoso* and you have an external VIP, the domain suffix is `contoso.p.azurewebsites.net`. 
 
    ![Screenshot that shows the App Service Environment basics tab.](./media/creation/creation-basics.png)
 
@@ -65,7 +65,7 @@ To create an App Service Environment in the Azure portal, complete the following
 
    ![Screenshot that shows App Service Environment networking (App Service Environment External) selections.](./media/creation/creation-networking-external.png)
 
-1. From the **Review + create** tab, check that your configuration is correct, then select **Create**. Your App Service Environment can take more than one hour to create. 
+1. From the **Review + create** tab, check that your configuration is correct, and then select **Create**. Your App Service Environment can take more than one hour to create. 
 
 After your App Service Environment is successfully created, you can select it as a location when you create your apps.
 

articles/app-service/environment/overview.md

@@ -41,9 +41,13 @@ An App Service Environment hosts applications for a single customer on one of th
 App Service Environments have many use cases:
 
 - Internal line-of-business applications
+
 - Applications that need more than 30 App Service plan instances
+
 - Single-tenant systems to satisfy internal compliance or security requirements
+
 - Network-isolated application hosting
+
 - Multiple-tier applications
 
 There are many networking features that enable apps in a multitenant App Service to reach network-isolated resources or become network-isolated themselves. These features are enabled at the application level. With an App Service Environment, apps don't require extra configuration to be on a virtual network. The apps are deployed into a network-isolated environment that's already on a virtual network. If you need a complete isolation story, you can also deploy your App Service Environment on dedicated hardware.
@@ -60,7 +64,7 @@ If you require physical isolation down to the hardware level, you can deploy you
 
 The App Service Environment feature is a deployment of Azure App Service into a single subnet within a virtual network. When you deploy an app into an App Service Environment, it's exposed on the inbound address that's assigned to the environment. If your App Service Environment is deployed with an internal virtual IP (VIP) address, the inbound address for all apps is an address within the App Service Environment subnet. If your App Service Environment is deployed with an external VIP address, the inbound address is an internet-accessible address, and your apps are listed in a public Domain Name System.
 
-An App Service Environment v3 in its subnet uses a varying number of addresses, depending on the number of instances and the amount of traffic. Some infrastructure roles are automatically scaled, depending on the number of App Service plans and the load. The recommended size for your App Service Environment v3 subnet is a `/24` Classless Inter-Domain Routing block with 256 addresses in it because that size can host an App Service Environment v3 that's scaled out to its limit.
+An App Service Environment v3 in its subnet uses a varying number of addresses, depending on the number of instances and the amount of traffic. Some infrastructure roles are automatically scaled, depending on the number of App Service plans and the load. A `/24` Classless Inter-Domain Routing block that has 256 addresses in it is the recommended size for your App Service Environment v3 subnet. That size can host an App Service Environment v3 that's scaled out to its limit.
 
 The apps in an App Service Environment don't need any features enabled to access resources on the same virtual network that the App Service Environment is in. If the App Service Environment virtual network is connected to another network, the apps in the App Service Environment can access resources in those extended networks. User configuration on the network can block traffic.
 
@@ -78,7 +82,7 @@ App Service Environment v3 differs from earlier versions in the following ways:
 
 - You can deploy an App Service Environment v3 on a dedicated host group. Host group deployments aren't zone redundant.
 
-- Scaling is faster than with an App Service Environment v2. Scaling is much faster than in the multitenant service, though it isn't immediate.
+- Scaling is faster than with an App Service Environment v2. Scaling is much faster than in the multitenant service, but it isn't immediate.
 
 - 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.
 
@@ -98,7 +102,7 @@ With App Service Environment v3, the pricing model varies depending on the type
 
 - **App Service Environment v3:** If the App Service Environment is empty, there's a charge as though you have one instance of Windows I1v2. The one instance charge isn't an additive charge but is applied only if the App Service Environment is empty.
 
-- **Zone redundant App Service Environment v3:** There's no added charge for availability zone support. The pricing model is the same as a nonzone redundant App Service Environment.
+- **Zone redundant App Service Environment v3:** There's no added charge for availability zone support. The pricing model is the same as an App Service Environment that isn't zone redundant.
 
 - **Dedicated host App Service Environment v3:** With a dedicated host deployment, you pay for two dedicated hosts at the time of App Service Environment v3 creation, based on our pricing. As you scale, you're charged a specialized Isolated v2 rate for each vCore. I1v2 uses two vCores, I2v2 uses four vCores, and I3v2 uses eight vCores for each instance.
 
@@ -198,7 +202,7 @@ The following sections list the regional pricing tiers, or SKUs, availability fo
 > [!NOTE]
 > Windows Container plans don't support memory-intensive SKUs.
  
-### Azure Public:
+### Azure Public
 
 | Region               | Standard     | Large       | Memory intensive  |
 | -------------------- | :----------: | :---------: | :---------------: |
@@ -259,7 +263,7 @@ The following sections list the regional pricing tiers, or SKUs, availability fo
 
 \* Windows Container doesn't support Large SKUs in this region.
 
-### Azure Government:
+### Azure Government
 
 | Region               | Standard     | Large       | Memory intensive  |
 | -------------------- | :----------: | :---------: | :---------------: |

articles/reliability/includes/reliability-transient-fault-description-include.md

@@ -11,4 +11,4 @@
 
 Transient faults are short, intermittent failures in components. They occur frequently in a distributed environment like the cloud, and they're a normal part of operations. Transient faults correct themselves after a short period of time. It's important that your applications handle transient faults, usually by retrying affected requests.
 
-All cloud-hosted applications should follow the Azure transient fault handling guidance when communicating with any cloud-hosted APIs, databases, and other components. For more information, see [Recommendations for handing transient faults](/azure/well-architected/reliability/handle-transient-faults).
+All cloud-hosted applications should follow the Azure transient fault handling guidance when they communicate with any cloud-hosted APIs, databases, and other components. For more information, see [Recommendations for handling transient faults](/azure/well-architected/reliability/handle-transient-faults).

articles/reliability/reliability-app-service.md

@@ -55,7 +55,7 @@ Microsoft-provided SDKs usually handle transient faults. Because you host your o
 
 [!INCLUDE [Availability zone support description](includes/reliability-availability-zone-description-include.md)]
 
-App Service can be configured as *zone redundant*, which means that your resources are distributed across multiple [availability zones](../reliability/availability-zones-overview.md). Distribution 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.
+App Service can be configured as *zone redundant*, which means that your resources are distributed across multiple availability zones. Distribution 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 distribution in a zone-redundant deployment follows specific rules. These rules remain applicable as the app scales in and scales out:
 
@@ -139,7 +139,7 @@ During an availability zone outage, some aspects of App Service might affect per
 
 ::: zone pivot="premium"
 
-When you're using App Service Premium v2, Premium v3, or Premium v4 plans, there's no extra cost associated with enabling availability zones as long as you have three or more instances in your App Service plan. You're charged based on your App Service plan SKU, the capacity you specify, and any instances you scale to based on your autoscale criteria.
+When you use App Service Premium v2, Premium v3, or Premium v4 plans, there's no extra cost associated with enabling availability zones as long as you have three or more instances in your App Service plan. You're charged based on your App Service plan SKU, the capacity you specify, and any instances that you scale to based on your autoscale criteria.
 
 If you enable availability zones but specify a capacity of less than two, the platform enforces a minimum instance count of two. The platform charges you for those two instances.
 
@@ -157,7 +157,7 @@ If you enable availability zones but specify a capacity of less than two, the pl
 
 ::: zone pivot="free-shared-basic"
 
-- **Create a new App Service plan with zone redundancy.** To deploy a new zone-redundant 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, ensure that you select the appropriate tier at the top of this page.
+- **Create a new App Service plan that has zone redundancy.** To deploy a new zone-redundant 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, ensure that you select the appropriate tier at the top of this page.
 
 ::: zone-end
 
@@ -227,7 +227,7 @@ If you enable availability zones but specify a capacity of less than two, the pl
     
     1. Ensure that the App Service Environment has zone redundancy enabled. You can only enable zone redundancy on an Isolated v2 App Service plan when the App Service Environment is zone redundant. 
 
-    1. Select the *Zone redundant* option when you deploy the plan in the Azure portal or set the App Service plan `zoneRedundant` property to `true` in the Azure CLI command, Azure PowerShell command, Bicep file, or Azure Resource Manager template.
+    1. Select the *Zone redundant* option when you deploy the plan in the Azure portal or set the App Service plan `zoneRedundant` property to `true` in the Azure CLI command, Azure PowerShell command, Bicep file, or Resource Manager template.
 
     # [Azure CLI](#tab/azurecli)
 
@@ -365,7 +365,7 @@ The following section describes what to expect when App Service plans are config
     If autoscale is configured and determines that more instances are needed, it issues a request to App Service to add them. Autoscale behavior operates independently of App Service platform behavior, meaning that your instance count specification doesn't need to be a multiple of three. For more information, see [Scale up an app in App Service](../app-service/manage-scale-up.md) and [Autoscale overview](/azure/azure-monitor/autoscale/autoscale-overview).
 
     > [!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 the loss of a zone. You can achieve this by [over-provisioning the capacity of your App Service plan](#capacity-planning-and-management).
+    > There's no guarantee that requests for more instances in a zone-down scenario succeed. The backfilling 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 the loss of a zone. You can achieve this by [over-provisioning 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 an availability zone experiences an outage. However, nonruntime behaviors might be affected during an availability zone outage. These behaviors include App Service plan scaling, application creation, application configuration, and application publishing.