You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/api-management/api-management-howto-deploy-multi-region.md
+14-13Lines changed: 14 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ description: Learn how to deploy a Premium tier Azure API Management instance to
5
5
author: dlepow
6
6
ms.service: azure-api-management
7
7
ms.topic: how-to
8
-
ms.date: 07/29/2024
8
+
ms.date: 07/07/2025
9
9
ms.author: danlep
10
10
---
11
11
@@ -19,7 +19,7 @@ When adding a region, you configure:
19
19
20
20
* The number of scale [units](upgrade-and-scale.md) that region will host.
21
21
22
-
*Optional [availability zones](../reliability/migrate-api-mgt.md), if that region supports it.
22
+
*[Availability zones](enable-availability-zone-support.md), if that region supports it. By default, API Management automatically configures availability zones for the added region, which is recommended. You can also manually configure availability zones for the added region.
23
23
24
24
*[Virtual network](virtual-network-concepts.md) settings in the added region, if networking is configured in the existing region or regions.
25
25
@@ -35,37 +35,38 @@ When adding a region, you configure:
35
35
36
36
## Prerequisites
37
37
38
+
* 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).
38
39
* 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.
39
40
* 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).
40
41
41
-
## <aname="add-region"> </a>Deploy API Management service to an additional region
42
+
## Deploy API Management service to an additional region
42
43
43
44
1. In the Azure portal, navigate to your API Management service and select **Locations** from the left menu.
44
45
1. Select **+ Add** in the top bar.
45
46
1. Select the added location from the dropdown list.
46
47
1. Select the number of scale **[Units](upgrade-and-scale.md)** in the location.
47
-
1.Optionally select one or more [**Availability zones**](../reliability/migrate-api-mgt.md).
48
-
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 (if enabling availability zones).
48
+
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.
49
+
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.
49
50
1. Select **Add** to confirm.
50
51
1. Repeat this process until you configure all locations.
51
52
1. Select **Save** in the top bar to start the deployment process.
52
53
53
-
## <aname="remove-region"> </a>Remove an API Management service region
54
+
## Remove an API Management service region
54
55
55
56
1. In the Azure portal, navigate to your API Management service and select **Locations** from the left menu.
56
57
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**.
57
58
1. Confirm the deletion and select **Save** to apply the changes.
58
59
59
60
60
-
## <aname="route-backend"> </a>Route API calls to regional backend services
61
+
## Route API calls to regional backend services
61
62
62
63
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.
63
64
64
65
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.
65
66
66
67
1. Navigate to your Azure API Management instance and select **APIs** from the left menu.
67
68
2. Select your desired API.
68
-
3.Select **Code editor**from the arrow dropdown in the **Inbound processing**.
69
+
3.On the **Design**tab, in the **Inbound processing** section, select **Code editor**.
@@ -109,7 +110,7 @@ You may also front your backend services with [Azure Traffic Manager](https://az
109
110
110
111
* For traffic control during maintenance operations, we recommend using the Priority routing method.
111
112
112
-
## <aname="custom-routing"> </a>Use custom routing to API Management regional gateways
113
+
## Use custom routing to API Management regional gateways
113
114
114
115
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.
115
116
@@ -167,7 +168,7 @@ This section provides considerations for multi-region deployments when the API M
167
168
* 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.
168
169
* Virtual networks in the different regions don't need to be peered.
169
170
> [!IMPORTANT]
170
-
> When configured in internal VNet 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 tag 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.
171
+
> 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.
171
172
172
173
### IP addresses
173
174
@@ -185,10 +186,10 @@ This section provides considerations for multi-region deployments when the API M
185
186
186
187
## Related content
187
188
188
-
* Learn more about configuring API Management for [high availability](high-availability.md).
189
-
190
-
* Learn more about configuring [availability zones](../reliability/migrate-api-mgt.md) to improve the availability of an API Management instance in a region.
189
+
* Learn more about [reliability in API Management](../reliability/reliability-api-management.md)
191
190
191
+
* Learn more about enabling [availability zone support](enable-availability-zone-support.md) for an API Management instance.
192
+
192
193
* For more information about virtual networks and API Management, see:
193
194
194
195
* [Connect to a virtual network using Azure API Management](api-management-using-with-vnet.md)
title: Azure API Management - Managed certificates suspension for new custom domains (August 2025)
3
+
description: Azure API Management is temporarily suspending managed certificates for new custom domains from August 15, 2025 to March 15, 2026 due to industry-wide changes in domain validation.
4
+
services: api-management
5
+
author: dlepow
6
+
ms.service: azure-api-management
7
+
ms.topic: reference
8
+
ai-usage: ai-assisted
9
+
ms.date: 07/18/2025
10
+
ms.author: danlep
11
+
---
12
+
13
+
# Managed certificates suspension for new custom domains (August 2025)
Azure managed certificates for new custom domains in API Management will be temporarily turned off from August 15, 2025 to March 15, 2026. Existing managed certificates will be autorenewed and remain unaffected.
18
+
19
+
In the classic service tiers, Azure API Management offers [free, managed TLS certificates for custom domains](../configure-custom-domain.md#domain-certificate-options), allowing customers to secure their endpoints without purchasing and managing their own certificates. Because of an industry-wide deprecation of CNAME-based Domain Control Validation (DCV), our Certificate Authority (CA), DigiCert, will migrate to a new validation platform to meet Multi-Perspective Issuance Corroboration (MPIC) requirements. This migration requires a temporary suspension of managed certificates for new custom domains.
20
+
21
+
## Is my service affected by this?
22
+
23
+
You're affected if you plan to create new managed certificates for new custom domains in Azure API Management between August 15, 2025 and March 15, 2026. Existing managed certificates will be autorenewed before August 15, 2025 and will continue to function normally. There's no impact to existing managed certificates or custom domains already using them.
24
+
25
+
## What is the deadline for the change?
26
+
27
+
The suspension of managed certificates for new custom domains will be enforced from August 15, 2025 to March 15, 2026. The capability to create managed certificates will resume after the migration to the new validation platform is complete.
28
+
29
+
## What do I need to do?
30
+
31
+
No action is required if you already have managed certificates for your custom domains. If you need to add new managed certificates, plan to do so before August 15, 2025 or after March 15, 2026. During the suspension period, you can still configure custom domains with certificates you manage from other sources.
32
+
33
+
## Help and support
34
+
35
+
If you have questions, get answers from community experts in [Microsoft Q&A](https://aka.ms/apim/azureqa/change/captcha-2022). If you have a support plan and need technical help, create a [support request](https://portal.azure.com/#view/Microsoft_Azure_Support/HelpAndSupportBlade/~/overview).
36
+
37
+
## Related content
38
+
39
+
See all [upcoming breaking changes and feature retirements](overview.md).
0 commit comments