Merge pull request #303124 from Court72/reliability-hub-edit

Reliability Hub edit: APIM Guide

Author: JamesJBarnett

articles/api-management/api-management-howto-deploy-multi-region.md

@@ -1,5 +1,5 @@
 ---
-title: Deploy Azure API Management instance to multiple Azure regions
+title: Deploy an Azure API Management Instance to Multiple Azure Regions
 titleSuffix: Azure API Management
 description: Learn how to deploy a Premium tier Azure API Management instance to multiple Azure regions to improve API gateway availability.
 author: dlepow
@@ -28,15 +28,16 @@ When adding a region, you configure:
 
 [!INCLUDE [api-management-service-update-behavior](../../includes/api-management-service-update-behavior.md)]
 
-
 ## About multi-region deployment
 
 [!INCLUDE [api-management-multi-region-concepts](../../includes/api-management-multi-region-concepts.md)]
 
 ## Prerequisites
 
-* Thoroughly understand all requirements and considerations for enabling multi-region deployment in API Management by reading [Reliability in API Management](../reliability/reliability-api-management.md). 
+* Thoroughly understand all [requirements and considerations for enabling multi-region deployment in API Management](../reliability/reliability-api-management.md).
+
 * If you haven't created an API Management service instance, see [Create an API Management service instance](get-started-create-service-instance.md). Select the Premium service tier.
+
 * If your API Management instance is deployed in a virtual network, ensure that you set up a virtual network and subnet in the location that you plan to add, and within the same subscription. See [virtual network prerequisites](api-management-using-with-vnet.md#prerequisites).
 
 ## Deploy API Management service to an additional region
@@ -45,7 +46,7 @@ When adding a region, you configure:
 1. Select **+ Add** in the top bar.
 1. Select the added location from the dropdown list.
 1. Select the number of scale **[Units](upgrade-and-scale.md)** in the location.
-1. If the region supports [**Availability zones**](enable-availability-zone-support.md), leave the **Automatic** setting (recommended), or optionally select one or more zones. If you select specific zones, the number of units that you selected must distribute evenly across the availability zones. For example, if you selected three units, you would select three zones so that each zone hosts one unit. 
+1. If the region supports [**Availability zones**](enable-availability-zone-support.md), leave the **Automatic** setting (recommended), or optionally select one or more zones. If you select specific zones, the number of units that you select must distribute evenly across the availability zones. For example, if you select three units, you must select three zones so that each zone hosts one unit.
 1. If the API Management instance is deployed in a [virtual network](api-management-using-with-vnet.md), configure virtual network settings in the location, including virtual network, subnet, and public IP address.
 1. Select **Add** to confirm.
 1. Repeat this process until you configure all locations.
@@ -57,18 +58,17 @@ When adding a region, you configure:
 1. For the location you would like to remove, select the context menu using the **...** button at the right end of the table. Select **Delete**.
 1. Confirm the deletion and select **Save** to apply the changes.
 
-
 ## Route API calls to regional backend services
 
-By default, each API routes requests to a single backend service URL. Even if you've configured Azure API Management gateways in various regions, the API gateway will still forward requests to the same backend service, which is deployed in only one region. In this case, the performance gain will come only from responses cached within Azure API Management in a region specific to the request; contacting the backend across the globe may still cause high latency.
+By default, each API routes requests to a single backend service URL. Even if you configure API Management gateways in various regions, the API gateway still forwards requests to the same backend service, which is deployed in only one region. In this case, improved performance comes only from responses cached within API Management in a region specific to the request. Contacting the backend across the globe might still cause high latency.
 
-To take advantage of geographical distribution of your system, you should have backend services deployed in the same regions as Azure API Management instances. Then, using policies and `@(context.Deployment.Region)` property, you can route the traffic to local instances of your backend.
+To take advantage of geographical distribution of your system, you should deploy backend services in the same regions as API Management instances. Then, by using policies and the `@(context.Deployment.Region)` property, you can route the traffic to local instances of your backend.
 
-1. Navigate to your Azure API Management instance and select **APIs** from the left menu.
+1. Go to your API Management instance and select **APIs** from the left menu.
 2. Select your desired API.
 3. On the **Design** tab, in the **Inbound processing** section, select **Code editor**.
 
-    ![API code editor](./media/api-management-howto-deploy-multi-region/api-management-api-code-editor.png)
+    ![A screenshot that highlights the API code editor in the design tab.](./media/api-management-howto-deploy-multi-region/api-management-api-code-editor.png)
 
 4. Use the `set-backend` combined with conditional `choose` policies to construct a proper routing policy in the `<inbound> </inbound>` section of the file.
 
@@ -104,7 +104,7 @@ To take advantage of geographical distribution of your system, you should have b
 
 ### Use Traffic Manager for routing to regional backends
 
-You may also front your backend services with [Azure Traffic Manager](https://azure.microsoft.com/services/traffic-manager/), direct the API calls to the Traffic Manager, and let it resolve the routing automatically. 
+You can also front your backend services with [Azure Traffic Manager](https://azure.microsoft.com/services/traffic-manager/), direct the API calls to the Traffic Manager, and let it resolve the routing automatically. 
 
 * For traffic distribution and failover, we recommend using Traffic Manager with the [**Geographic**](../traffic-manager/traffic-manager-routing-methods.md#geographic-traffic-routing-method) routing method. We don't recommend using Traffic Manager with the Weighted routing method with API Management backends.
 
@@ -114,8 +114,8 @@ You may also front your backend services with [Azure Traffic Manager](https://az
 
 API Management routes the requests to a regional gateway based on [the lowest latency](../traffic-manager/traffic-manager-routing-methods.md#performance). Although it isn't possible to override this setting in API Management, you can use your own Traffic Manager with custom routing rules.
 
-1. Create your own [Azure Traffic Manager](https://azure.microsoft.com/services/traffic-manager/).
-1. If you're using a custom domain, [use it with the Traffic Manager](../traffic-manager/traffic-manager-point-internet-domain.md) instead of the API Management service.
+1. Create your own [Traffic Manager](https://azure.microsoft.com/services/traffic-manager/).
+1. If you use a custom domain, [use it with Traffic Manager](../traffic-manager/traffic-manager-point-internet-domain.md) instead of the API Management service.
 1. [Configure the API Management regional endpoints in Traffic Manager](../traffic-manager/traffic-manager-manage-endpoints.md). The regional endpoints follow the URL pattern of `https://<service-name>-<region>-01.regional.azure-api.net`, for example `https://contoso-westus2-01.regional.azure-api.net`.
 1. [Configure the API Management regional status endpoints in Traffic Manager](../traffic-manager/traffic-manager-monitoring.md). The regional status endpoints follow the URL pattern of `https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef`, for example `https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef`.
 1. Specify [the routing method](../traffic-manager/traffic-manager-routing-methods.md) of the Traffic Manager.
@@ -124,16 +124,16 @@ API Management routes the requests to a regional gateway based on [the lowest la
 
 Under some conditions, you might need to temporarily disable routing to one of the regional gateways. For example:
 
-* After adding a new region, to keep it disabled while you configure and test the regional backend service 
+* After you add a new region, to keep it disabled while you configure and test the regional backend service 
 * During regular backend maintenance in a region
 * To redirect traffic to other regions during a planned disaster recovery drill that simulates an unavailable region, or during a regional failure 
 
-To disable routing to a regional gateway in your API Management instance, update the gateway's `disableGateway` property value to `true`. You can set the value using the [Create or update service](/rest/api/apimanagement/current-ga/api-management-service/create-or-update) REST API, the [az apim update](/cli/azure/apim#az-apim-update) command in the Azure CLI, the [set-azapimanagement](/powershell/module/az.apimanagement/set-azapimanagement) Azure PowerShell cmdlet, or other Azure tools.
+To disable routing to a regional gateway in your API Management instance, update the gateway's `disableGateway` property value to `true`. You can set the value by using the [Create or update service](/rest/api/apimanagement/current-ga/api-management-service/create-or-update) REST API, the [az apim update](/cli/azure/apim#az-apim-update) command in the Azure CLI, the [set-azapimanagement](/powershell/module/az.apimanagement/set-azapimanagement) Azure PowerShell cmdlet, or other Azure tools.
 
 >[!NOTE]
-> You can only disable routing to a regional gateway when you are using API Management's default routing, not a custom routing solution. 
+> You can only disable routing to a regional gateway when you use default routing in API Management, not a custom routing solution.
 
-To disable a regional gateway using the Azure CLI:
+To disable a regional gateway by using the Azure CLI:
 
 1. Use the [az apim show](/cli/azure/apim#az-apim-show) command to show the locations, gateway status, and regional URLs configured for the API Management instance. 
     ```azurecli
@@ -155,7 +155,7 @@ To disable a regional gateway using the Azure CLI:
     --set additionalLocations[location="West US 2"].disableGateway=true
     ```
 
-    The update may take a few minutes. 
+    The update might take a few minutes. 
 
 1. Verify that traffic directed to the regional gateway URL is redirected to another region. 
 
@@ -165,24 +165,24 @@ To restore routing to the regional gateway, set the value of `disableGateway` to
 
 This section provides considerations for multi-region deployments when the API Management instance is injected in a virtual network.
 
-* Configure each regional network independently. The [connectivity requirements](virtual-network-reference.md) such as required network security group rules for a virtual network in an added region are generally the same as those for a network in the primary region.
+* Configure each regional network independently. The [connectivity requirements](virtual-network-reference.md), such as required network security group rules for a virtual network in an added region, are generally the same as the requirements for a network in the primary region.
 * Virtual networks in the different regions don't need to be peered.
 > [!IMPORTANT]
-> When configured in internal virtual network mode, each regional gateway must also have outbound connectivity on port 1433 to the Azure SQL database configured for your API Management instance, which is only in the *primary* region. Ensure that you allow connectivity to the FQDN or IP address of this Azure SQL database in any routes or firewall rules you configure for networks in your secondary regions; the Azure SQL service endpoint can't be used in this scenario. To find the Azure SQL database name in the primary region, go to the **Network** > **Network status** page of your API Management instance in the portal. 
+> When you configure your API Management instance to use internal virtual network mode, each regional gateway must also have outbound connectivity on port 1433 to the Azure SQL database configured for your API Management instance, which is only in the *primary* region. Ensure that you allow connectivity to the fully qualified domain name (FQDN) or IP address of this Azure SQL database in any routes or firewall rules you configure for networks in your secondary regions; the Azure SQL service endpoint can't be used in this scenario. To find the Azure SQL database name in the primary region, go to the **Network** > **Network status** page of your API Management instance in the portal. 
 
 ### IP addresses
 
 * A public virtual IP address is created in every region added with a virtual network. For virtual networks in either [external mode](api-management-using-with-vnet.md) or [internal mode](api-management-using-with-internal-vnet.md), this public IP address is used for management traffic on port `3443`.
 
-    * **External VNet mode** - The public IP addresses are also required to route public HTTP traffic to the API gateways.
+    * **External VNet mode:** The public IP addresses are also required to route public HTTP traffic to the API gateways.
 
-    * **Internal VNet mode** - A private IP address is also created in every region added with a virtual network. Use these addresses to connect within the network to the API Management endpoints in the primary and secondary regions.
+    * **Internal VNet mode:** A private IP address is also created in every region added with a virtual network. Use these addresses to connect within the network to the API Management endpoints in the primary and secondary regions.
 
 ### Routing
 
-* **External VNet mode** - Routing of public HTTP traffic to the regional gateways is handled automatically, in the same way it is for a non-networked API Management instance.
+* **External VNet mode:** Routing of public HTTP traffic to the regional gateways is handled automatically, in the same way it is for a non-networked API Management instance.
 
-* **Internal VNet mode** - Private HTTP traffic isn't routed or load-balanced to the regional gateways by default. Users own the routing and are responsible for bringing their own solution to manage routing and private load balancing across multiple regions. 
+* **Internal VNet mode:** Private HTTP traffic isn't routed or load-balanced to the regional gateways by default. Users own the routing and are responsible for bringing their own solution to manage routing and private load balancing across multiple regions. 
 
 ## Related content
 
@@ -192,9 +192,9 @@ This section provides considerations for multi-region deployments when the API M
 
 * For more information about virtual networks and API Management, see:
 
-    * [Connect to a virtual network using Azure API Management](api-management-using-with-vnet.md)
+    * [Connect to a virtual network by using API Management](api-management-using-with-vnet.md)
 
-    * [Connect to a virtual network in internal mode using Azure API Management](api-management-using-with-internal-vnet.md)
+    * [Connect to a virtual network in internal mode by using API Management](api-management-using-with-internal-vnet.md)
 
     * [IP addresses of API Management](api-management-howto-ip-addresses.md)
 
@@ -209,6 +209,4 @@ This section provides considerations for multi-region deployments when the API M
 
 [unit]: https://azure.microsoft.com/pricing/details/api-management/
 
-[premium]: https://azure.microsoft.com/pricing/details/api-management/
-
-
+[premium]: https://azure.microsoft.com/pricing/details/api-management/