Merge pull request #288576 from dlepow/azip

v-regandowner · web-flow · commit 3fafee34aa46 · 2024-10-17T19:26:51.000-04:00
[APIM] Zonal AZs
diff --git a/articles/api-management/TOC.yml b/articles/api-management/TOC.yml
@@ -151,8 +151,8 @@
       href: high-availability.md
     - name: Deploy to multiple Azure regions
       href: api-management-howto-deploy-multi-region.md
-    - name: Enable zone redundancy
-      displayName: Availability zones
+    - name: Enable availability zones
+      displayName: zonal, zone-redundant
       href: ../reliability/migrate-api-mgt.md?toc=%2Fazure%2Fapi-management%2Ftoc.json&bc=/azure/api-management/breadcrumb/toc.json
     - name: Set up DR using backup/restore
       displayName: disaster, recovery
diff --git a/articles/api-management/api-management-howto-deploy-multi-region.md b/articles/api-management/api-management-howto-deploy-multi-region.md
@@ -19,7 +19,7 @@ When adding a region, you configure:
 
 * The number of scale [units](upgrade-and-scale.md) that region will host. 
 
-* Optional [zone redundancy](../reliability/migrate-api-mgt.md), if that region supports it.
+* Optional [availability zones](../reliability/migrate-api-mgt.md), if that region supports it.
 
 * [Virtual network](virtual-network-concepts.md) settings in the added region, if networking is configured in the existing region or regions.
 
@@ -33,7 +33,7 @@ When adding a region, you configure:
 ## Prerequisites
 
 * 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. To enable zone redundancy, also set up a new public IP. See [virtual network prerequisites](api-management-using-with-vnet.md#prerequisites).
+* 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).
 
 ## <a name="add-region"> </a>Deploy API Management service to an additional region
 
@@ -184,7 +184,7 @@ This section provides considerations for multi-region deployments when the API M
 
 * Learn more about configuring API Management for [high availability](high-availability.md).
 
-* Learn more about [zone redundancy](../reliability/migrate-api-mgt.md) to improve the availability of an API Management instance in a region.
+* Learn more about configuring [availability zones](../reliability/migrate-api-mgt.md) to improve the availability of an API Management instance in a region.
 
 * For more information about virtual networks and API Management, see:
 
diff --git a/articles/api-management/high-availability.md b/articles/api-management/high-availability.md
@@ -36,7 +36,7 @@ Enabling [zone redundancy](../reliability/migrate-api-mgt.md) for an API Managem
 When you enable zone redundancy in a region, consider the number of API Management scale [units](upgrade-and-scale.md) that need to be distributed. Minimally, configure the same number of units as the number of availability zones, or a multiple so that the units are distributed evenly across the zones. For example, if you select 3 availability zones in a region, you could have 3 units so that each zone hosts one unit.
 
 > [!NOTE]
-> Use the [capacity](api-management-capacity.md) metric and your own testing to decide the number of scale units that will provide the gateway performance for your needs. Learn more about [scaling and upgrading](upgrade-and-scale.md) your service instance.
+> Use [capacity metrics](api-management-capacity.md) and your own testing to decide the number of scale units that will provide the gateway performance for your needs. Learn more about [scaling and upgrading](upgrade-and-scale.md) your service instance.
 
 ## Multi-region deployment
 
diff --git a/articles/reliability/migrate-api-mgt.md b/articles/reliability/migrate-api-mgt.md
@@ -4,21 +4,25 @@ description: Learn how to migrate your Azure API Management instances to availab
 author: shaunjacob 
 ms.service: azure-api-management
 ms.topic: how-to
-ms.date: 07/07/2022
+ms.date: 10/16/2024
 ms.author: anaharris
 ms.custom: references_regions, subject-reliability
 
 ---
 
 # Migrate Azure API Management to availability zone support
 
-The Azure API Management service supports [zone redundancy](../reliability/availability-zones-overview.md), which provides resiliency and high availability to a service instance in a specific Azure region. With zone redundancy, the gateway and the control plane of your API Management instance (management API, developer portal, Git configuration) are replicated across datacenters in physically separated zones, so they're resilient to a zone failure.
+The Azure API Management service supports [availability zones](../reliability/availability-zones-overview.md) in both zonal and zone-redundant configurations:
 
-This article describes four options for migrating an API Management instance to availability zones. For background about configuring API Management for high availability, see [Ensure API Management availability and reliability](../api-management/high-availability.md).
+* **Zonal** - the API Management gateway and the control plane of your API Management instance (management API, developer portal, Git configuration) are deployed in a single zone you select within an Azure region.
+
+* **Zone-redundant** - the gateway and the control plane of your API Management instance (management API, developer portal, Git configuration) are replicated across two or more physically separated zones within an Azure region. Zone redundancy provides resiliency and high availability to a service instance.
+
+This article describes four scenarios for migrating an API Management instance to availability zones. For more information about configuring API Management for high availability, see [Ensure API Management availability and reliability](../api-management/high-availability.md).
 
 ## Prerequisites
 
-* To configure API Management for zone redundancy, your instance must be in one of the [Azure regions that support availability zones](availability-zones-service-support.md#azure-regions-with-availability-zone-support).
+* To configure availability zones for API Management, your instance must be in one of the [Azure regions that support availability zones](availability-zones-service-support.md#azure-regions-with-availability-zone-support).
 
 * If you don't have an API Management instance, create one by following the [Create a new Azure API Management instance by using the Azure portal](../api-management/get-started-create-service-instance.md) quickstart. Select the Premium service tier.
 
@@ -34,15 +38,15 @@ There are no downtime requirements for any of the migration options.
 
 * Changes can take 15 to 45 minutes to apply. The API Management gateway can continue to handle API requests during this time.
 
-* When you're migrating an API Management instance that's deployed in an external or internal virtual network to availability zones, you must specify a new public IP address resource. In an internal virtual network, the public IP address is used only for management operations, not for API requests. [Learn more about IP addresses of API Management](../api-management/api-management-howto-ip-addresses.md).
+* When you're migrating an API Management instance that's deployed in an external or internal virtual network to availability zones, you can optionally specify a new public IP address resource. In an internal virtual network, the public IP address is used only for management operations, not for API requests. [Learn more about IP addresses of API Management](../api-management/api-management-howto-ip-addresses.md).
 
 * Migrating to availability zones or changing the configuration of availability zones triggers a public and private [IP address change](../api-management/api-management-howto-ip-addresses.md#changes-to-the-ip-addresses).
 
-* When you're enabling availability zones in a region, you configure API Management scale [units](../api-management/upgrade-and-scale.md) that you can distribute evenly across the zones. For example, if you configure two zones, you can configure two units, four units, or another multiple of two units.
+* When you're enabling availability zones in a region, you configure API Management scale [units](../api-management/upgrade-and-scale.md) that you can distribute evenly across the zones. For example, if you configure two zones, you can configure two units, four units, or another multiple of two units. 
 
   Adding units incurs additional costs. For details, see [API Management pricing](https://azure.microsoft.com/pricing/details/api-management/).
 
-* If you configured autoscaling for your API Management instance in the primary location, you might need to adjust your autoscale settings after enabling zone redundancy. The number of API Management units in autoscale rules and limits must be a multiple of the number of zones.
+* If you configured autoscaling for your API Management instance in the primary location, you might need to adjust your autoscale settings after configuring availability zones. The number of API Management units in autoscale rules and limits must be a multiple of the number of zones.
 
 ## Existing gateway location not injected in a virtual network
 
@@ -66,7 +70,7 @@ To migrate an existing location of your API Management instance to availability
 
 To migrate an existing location of your API Management instance to availability zones when the instance is currently injected in a virtual network and is currently hosted on the `stv1` platform, use the following steps. Migrating to availability zones also migrates the instance to the `stv2` platform.
 
-1. Create a new subnet and public IP address in the location to migrate to availability zones. Detailed requirements are in the [virtual networking guidance](../api-management/api-management-using-with-vnet.md?tabs=stv2#prerequisites).
+1. Create a new subnet and optional public IP address in the location to migrate to availability zones. Detailed requirements are in the [virtual networking guidance](../api-management/api-management-using-with-vnet.md?tabs=stv2#prerequisites).
 
 1. In the Azure portal, go to your API Management instance.
 
@@ -78,7 +82,7 @@ To migrate an existing location of your API Management instance to availability
 
 1. In the **Availability zones** box, select one or more zones. The number of units that you selected must be distributed evenly across the availability zones. For example, if you selected three units, select three zones so that each zone hosts one unit.
 
-1. In the respective boxes under **Network**, select the new subnet and new public IP address in the location.
+1. In the respective boxes under **Network**, select the new subnet and optional public IP address in the location.
 
 1. Select **Apply**, and then select **Save**.
 
@@ -88,7 +92,7 @@ To migrate an existing location of your API Management instance to availability
 
 To migrate an existing location of your API Management instance to availability zones when the instance is currently injected in a virtual network and is already hosted on the `stv2` platform:
 
-1. Create a new subnet and public IP address in the location to migrate to availability zones. Detailed requirements are in the [virtual networking guidance](../api-management/api-management-using-with-vnet.md?tabs=stv2#prerequisites).
+1. Create a new subnet and optional public IP address in the location to migrate to availability zones. Detailed requirements are in the [virtual networking guidance](../api-management/api-management-using-with-vnet.md?tabs=stv2#prerequisites).
 
 1. In the Azure portal, go to your API Management instance.
 
@@ -100,17 +104,17 @@ To migrate an existing location of your API Management instance to availability
 
 1. In the **Availability zones** box, select one or more zones. The number of units that you selected must be distributed evenly across the availability zones. For example, if you selected three units, select three zones so that each zone hosts one unit.
 
-1. In the **Public IP Address** box, select the new public IP address in the location.
+1. In the **Public IP Address** box, optionally select the new public IP address in the location.
 
 1. Select **Apply**, and then select **Save**.
 
-:::image type="content" alt-text="Screenshot that shows selections for migrating an existing location of an API Management instance (stv2 platform) that's injected in a virtual network." source ="media/migrate-api-mgt/option-three-stv2-injected-in-vnet.png":::
+:::image type="content" alt-text="Screenshot that shows selections to migrate existing location of API Management instance (stv2 platform) that's injected in a virtual network." source ="media/migrate-api-mgt/option-three-stv2-injected-in-vnet.png":::
 
 ## New gateway location
 
 To add a new location to your API Management instance and enable availability zones in that location:
 
-1. If your API Management instance is deployed in a virtual network in the primary location, set up a [virtual network](../api-management/api-management-using-with-vnet.md?tabs=stv2), subnet, and public IP address in any new location where you plan to enable zone redundancy.
+1. If your API Management instance is deployed in a virtual network in the primary location, set up a [virtual network](../api-management/api-management-using-with-vnet.md?tabs=stv2), subnet, and optional public IP address in any new location where you plan to enable availability zones.
 
 1. In the Azure portal, go to your API Management instance.
 
@@ -122,7 +126,7 @@ To add a new location to your API Management instance and enable availability zo
 
 1. In the **Availability zones** box, select one or more zones. The number of units that you selected must be distributed evenly across the availability zones. For example, if you selected three units, select three zones so that each zone hosts one unit.
 
-1. If your API Management instance is deployed in a virtual network, use the boxes under **Network** to select the virtual network, subnet, and public IP address that are available in the location.
+1. If your API Management instance is deployed in a virtual network, use the boxes under **Network** to select the virtual network, subnet, and optional public IP address that are available in the location.
 
 1. Select **Add**, and then select **Save**.
 
diff --git a/includes/api-management-publicip-internal-vnet.md b/includes/api-management-publicip-internal-vnet.md
@@ -2,10 +2,9 @@
 author: dlepow
 ms.service: azure-api-management
 ms.topic: include
-ms.date: 08/16/2024
+ms.date: 10/16/2024
 ms.author: danlep
 ---
 
 > [!IMPORTANT]
-> * Starting May 2024, a public IP address resource is *no longer needed* when deploying (injecting) an API Management instance in a VNet in internal mode or migrating the internal VNet configuration to a new subnet. In external VNet mode, specifying a public IP address is *optional*; if you don't provide one, an Azure-managed public IP address is automatically configured and used for runtime API traffic. Only provide the public IP address if you want to own and control the public IP address used for inbound or outbound communication to the internet.
-> * Currently, if you enable zone redundancy for an API Management instance in a VNet in either internal mode or external mode, you must specify a new public IP address. 
+> * Starting May 2024, a public IP address resource is *no longer needed* when deploying (injecting) an API Management instance in a VNet in internal mode or migrating the internal VNet configuration to a new subnet. In external VNet mode, specifying a public IP address is *optional*; if you don't provide one, an Azure-managed public IP address is automatically configured and used for runtime API traffic. Only provide the public IP address if you want to own and control the public IP address used for inbound or outbound communication to the internet.
