How to deploy an Azure API Management service instance to multiple Azure regions
Azure API Management supports multi-region deployment, which enables API publishers to distribute a single Azure API management service across any number of supported Azure regions. Multi-region feature helps reduce request latency perceived by geographically distributed API consumers and improves service availability if one region goes offline.
A new Azure API Management service initially contains only one unit in a single Azure region, the Primary region. Additional units can be added to the Primary or Secondary regions. An API Management gateway component is deployed to every selected Primary and Secondary region. Incoming API requests are automatically directed to the closest region. If a region goes offline, the API requests will be automatically routed around the failed region to the next closest gateway.
Only the gateway component of API Management is deployed to all regions. The service management component and developer portal are hosted in the Primary region only. Therefore, in case of the Primary region outage, access to the developer portal and ability to change configuration (e.g. adding APIs, applying policies) will be impaired until the Primary region comes back online. While the Primary region is offline, available Secondary regions will continue to serve the API traffic using the latest configuration available to them. Optionally enable zone redundancy to improve the availability and resiliency of the Primary or Secondary regions.
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.
This feature is available only in the Premium tier of API Management.
- If you have not yet 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, subnet, and public IP address in the location that you plan to add.
- In the Azure portal, navigate to your API Management service and select Locations in the menu.
- Select + Add in the top bar.
- Select the location from the drop-down list.
- Select the number of scale Units in the location.
- Optionally enable Availability zones.
- If the API Management instance is deployed in a virtual network, configure virtual network settings in the location. Select an existing virtual network, subnet, and public IP address that are available in the location.
- Select Add to confirm.
- Repeat this process until you configure all locations.
- Select Save in the top bar to start the deployment process.
- In the Azure portal, navigate to your API Management service and click on the Locations entry in the menu.
- For the location you would like to remove, open the context menu using the ... button at the right end of the table. Select the Delete option.
- Confirm the deletion and click Save to apply the changes.
Azure API Management features only one backend service URL. Even though there are Azure API Management instances 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, but contacting the backend across the globe may still cause high latency.
To fully leverage 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.
Navigate to your Azure API Management instance and click on APIs from the left menu.
Select your desired API.
Click Code editor from the arrow dropdown in the Inbound processing.
set-backendcombined with conditional
choosepolicies to construct a proper routing policy in the
<inbound> </inbound>section of the file.
For example, the below 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-us.com/" /> </when> <when condition="@("East Asia".Equals(context.Deployment.Region, StringComparison.OrdinalIgnoreCase))"> <set-backend-service base-url="http://contoso-asia.com/" /> </when> <otherwise> <set-backend-service base-url="http://contoso-other.com/" /> </otherwise> </choose> </inbound> <backend> <base /> </backend> <outbound> <base /> </outbound> <on-error> <base /> </on-error> </policies>
You may also front your backend services with Azure Traffic Manager, direct the API calls to the Traffic Manager, and let it resolve the routing automatically.
API Management routes the requests to a regional gateway based on the lowest latency. Although it is not possible to override this setting in API Management, you can use your own Traffic Manager with custom routing rules.
- Create your own Azure Traffic Manager.
- If you are using a custom domain, use it with the Traffic Manager instead of the API Management service.
- Configure the API Management regional endpoints in Traffic Manager. The regional endpoints follow the URL pattern of
https://<service-name>-<region>-01.regional.azure-api.net, for example
- Configure the API Management regional status endpoints in Traffic Manager. The regional status endpoints follow the URL pattern of
https://<service-name>-<region>-01.regional.azure-api.net/status-0123456789abcdef, for example
- Specify the routing method of the Traffic Manager.