APPLIES TO: Premium
Azure API Management supports multi-region deployment, which enables API publishers to add regional API gateways to an existing API Management instance in one or more supported Azure regions. Multi-region deployment helps reduce request latency perceived by geographically distributed API consumers and improves service availability if one region goes offline.
When adding a region, you configure:
The number of scale units that region will host.
Availability zones, 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.
Virtual network settings in the added region, if networking is configured in the existing region or regions.
Important
The feature to enable storing customer data in a single region is currently only available in the Southeast Asia Region (Singapore) of the Asia Pacific Geo. For all other regions, customer data is stored in Geo.
Important
Changes to your API Management service's infrastructure (such as configuring custom domains, adding CA certificates, scaling, virtual network configuration, availability zone changes, and region additions) can take 15 minutes or longer to complete, depending on the service tier and the size of the deployment. Expect longer times for an instance with a greater number of scale units or multi-region configuration. Rolling changes to API Management are executed carefully to preserve capacity and availability.
While the service is updating, other service infrastructure changes can't be made. However, you can configure APIs, products, policies, and user settings. The service will not experience gateway downtime, and API Management will continue to service API requests without interruption (except in the Developer tier).
About multi-region deploymentOnly the gateway component of your API Management instance is replicated to multiple regions. The instance's management plane and developer portal remain hosted only in the primary region, the region where you originally deployed the service.
If you want to configure a secondary location for your API Management instance when it's deployed (injected) in a virtual network, the VNet and subnet region should match with the secondary location you're configuring. If you're adding, removing, or enabling the availability zone in the primary region, or if you're changing the subnet of the primary region, then the VIP address of your API Management instance will change. For more information, see IP addresses of Azure API Management service. However, if you're adding a secondary region, the primary region's VIP won't change because every region has its own private VIP.
Gateway configurations such as APIs and policy definitions are regularly synchronized between the primary and secondary regions you add. Propagation of updates to the regional gateways normally takes less than 10 seconds. Multi-region deployment provides availability of the API gateway in more than one region and provides service availability if one region goes offline.
When API Management receives public HTTP requests to the traffic manager endpoint (applies for the external VNet and non-networked modes of API Management), traffic is routed to a regional gateway based on lowest latency, which can reduce latency experienced by geographically distributed API consumers. In internal VNet mode, customers must configure their own solution to route and load-balance traffic across the regional gateways. For details, see Networking considerations.
The gateway in each region (including the primary region) has a regional DNS name that follows the URL pattern of https://<service-name>-<region>-01.regional.azure-api.net, for example https://contoso-westus2-01.regional.azure-api.net.
If a region goes offline, API requests are automatically routed around the failed region to the next closest gateway.
If the primary region goes offline, the API Management management plane and developer portal become unavailable, but secondary regions continue to serve API requests using the most recent gateway configuration.
If configured, the rate-limit and rate-limit-by-key policies count calls separately at each regional gateway in the deployment. The policies don't aggregate all call data for the instance. Similarly, the azure-openai-token-limit and llm-token-limit policies count token usage separately at each regional gateway in the deployment.
Thoroughly understand all requirements and considerations for enabling multi-region deployment in API Management.
If you haven't created an API Management service instance, see Create an API Management service instance. 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.
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 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.
Go to your API Management instance and select APIs from the left menu.
Select your desired API.
On the Design tab, in the Inbound processing section, select Code editor.
Use the set-backend combined with conditional choose policies to construct a proper routing policy in the <inbound> </inbound> section of the file.
For example, the following XML file would work for West US and East Asia regions:
<policies>
<inbound>
<base />
<choose>
<when condition="@("West US".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
<set-backend-service base-url="http://contoso-backend-us.com/" />
</when>
<when condition="@("East Asia".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))">
<set-backend-service base-url="http://contoso-backend-asia.com/" />
</when>
<otherwise>
<set-backend-service base-url="http://contoso-backend-other.com/" />
</otherwise>
</choose>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>
You can also front your backend services with Azure 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 routing method. We don't recommend using Traffic Manager with the Weighted routing method with API Management backends.
For traffic control during maintenance operations, we recommend using the Priority routing method.
API Management routes the requests to a regional gateway based on the lowest latency. Although it isn't possible to override this setting in API Management, you can use your own Traffic Manager with custom routing rules.
https://<service-name>-<region>-01.regional.azure-api.net, for example https://contoso-westus2-01.regional.azure-api.net.https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef, for example https://contoso-westus2-01.regional.azure-api.net/status-0123456789abcdef.Under some conditions, you might need to temporarily disable routing to one of the regional gateways. For example:
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, the az apim update command in the Azure CLI, the set-azapimanagement Azure PowerShell cmdlet, or other Azure tools.
Note
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 by using the Azure CLI:
Use the az apim show command to show the locations, gateway status, and regional URLs configured for the API Management instance.
az apim show --name contoso --resource-group apim-hello-world-resource \
--query "additionalLocations[].{Location:location,Disabled:disableGateway,Url:gatewayRegionalUrl}" \
--output table
Example output:
Location Disabled Url
---------- ---------- ------------------------------------------------------------
West US 2 True https://contoso-westus2-01.regional.azure-api.net
West Europe True https://contoso-westeurope-01.regional.azure-api.net
Use the az apim update command to disable the gateway in an available location, such as West US 2.
az apim update --name contoso --resource-group apim-hello-world-resource \
--set additionalLocations[location="West US 2"].disableGateway=true
The update might take a few minutes.
Verify that traffic directed to the regional gateway URL is redirected to another region.
To restore routing to the regional gateway, set the value of disableGateway to false.
This section provides considerations for multi-region deployments when the API Management instance is injected in a virtual network.
Important
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 addressesA public virtual IP address is created in every region added with a virtual network. For virtual networks in either external mode or internal mode, 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.
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.
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.
Learn more about reliability in API Management
Learn more about enabling availability zone support for an API Management instance.
For more information about virtual networks and API Management, see:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4