Sunday, August 11, 2019

Azure API Management Disaster Recovery in Standard – Part 1 – Backup and restore configuration


This blog post explains step by step configuration for achieving Azure API Management DR in Standard sku. This bog post is divided in 2 parts series. Links to all parts is as below –

Being intelligent human being you can directly go to any of the part; but I would recommend to go ahead sequentially from Part 1 to Part 2 of the blog post. This will ensure that there are no mistakes. Ask any questions in comments. If I see that question asked is already answered in any of the part of this series; please don’t expect the answer to the question asked.

Till now we have seen two important blog post aboutAzure API Management custom Role Based Access Control and Need of API Gateway in modern architectures as concept.

This blog post takes another deep dive discussion in API Management DR configuration.

Azure API Management Disaster Recovery in Standard – the need?

Azure API Management as of today offered in various pricing sku with various features –1.    Consumption
2.      Developer
3.      Basic
4.      Standard
5.      Premium.

When you onboard API Management as a part of your API story for all of your Enterprise applications; this component becomes mission critical. As a best practice we should also configure Disaster Recovery (DR – multi region deployment) for API Management.
API Management DR is by default provided as a service in Premium sku. However at the same time the capacity or workload support by premium sku is massive. Therefore premium sku also comes with premium price. Sometimes enterprise needs are observed to get satisfied by BASIC or STANDARD pricing tier. As of today as a bench marking of API Management with STANDARD tier support approx. 2500 req/ seconds per unit. STANDARD tier can have up to 4 units. Means total number of requests that can be served by STANDARD API Management can go up to 10000 req/ sec. This is massive scale and may satisfy most of the Enterprise requirements. However STANDARD sku do not provide Disaster Recovery [DR] pre-configured. This may propose bigger challenge for organizations who are betting big on Azure API Management.

This document provides step by step document for configuration of DR for API Management STANDARD sku along with architecture. Hope this document will help to address the concern of API Management DR in Standard/ Basic mode.

List of Azure service used in the API Management DR with Standard

As a part of the solution we will use below services in Azure to implement API Management DR in standard mode.
  1. 2 Logic apps – for automation of backup from primary region and restore in secondary region of API Management
  2. API Management in two regions – Central India(Primary - CI) and South India(Secondary - SI)
  3. Traffic Manager – to distribute the load in case of DR situation
  4. Storage account – for storing backup information of API Management primary
  5. Azure AD application – to allow logic app provide authentication mechanism to make changes in API Management (through ServicePrincipal concept).

High Level Steps

The gist of this article is based on backup and restore feature of “API Management” management REST APIs. The REST API documentation is present below –

These APIs allow backup and restore operation for entire Azure API Management instance and it is crux of our solution. Refer to high level steps for the solution below.

  1. Create two API Management in Standard mode. One in primary [in our case Central India] and other in secondary [in our case South India].
  2.  Configure APIs and related backend in API Management primary. As you API Management standard is not part of VNET, the backend APIs will require public IP to get imported in API Management.
  3. Create Azure AD Application to have necessary permission to make changes in API Management instances in cross region.
  4. Allow rights on resource groups of both API Management in two regions.
  5. Create two logic apps. One to create backup of primary API Management. Second will be used to restore the same backup in secondary region API Management.
  6. Create traffic manager and add API Management IP address/ domains names as endpoint profiles. Configure Traffic manager in Failover/ Priority mode.
  7. Configure status page of API Management in Traffic manager to know health status of API Management for traffic manager so that it can switch to secondary region in case of DR situation.

Architecture for API Management DR in Standard Sku

  1. Logic app uses timer orchestration step to automatically trigger itself. As a next step same logic app sends service principal details to Azure AD and then retrieves the authentication token.
  2. Invoke API Management rest API with operation as backup.
  3. The operation starts copying data to storage account in other region. Depending on the size and number of APIs being used in Azure API Management the backup operation takes approximately 1-2 hours [this may change based on the data present in your API Management instance. Don’t quote me if it takes more/less time than I mentioned].
  4. Post successful copy operation of backup; another logic app is triggered which restores the backup data in another API Management instance created in secondary region.
  5. Post restore operation both API Management instances are now exactly identical. For example, in secondary API Management all policies, subscription key, APIs etc. will be same as primary API Management.
  6. The request from end user/ application is received to traffic manager. Traffic manager is configured in failover mode with primary API Management as active and secondary API Management as passive.
  7. Traffic manager passes on the incoming request to active API Management instance.
  8. The health status page of both API Management instances /status023456789abcdef keeps sending 200 response to traffic manager. In case if primary status page sends non-200 response then Traffic manager will route the traffic to secondary API Management automatically.

Step by step execution

Here onwards we will describe how API Management backup and restore with logic apps configuration can be achieved along with required screenshots.

Resource group creation

Create two resource groups in Azure portal. One with name as APIMPrimaryRG in Central India (or in region of your choice) and APIMDRRG in South India (or in region of your choice).

API Management instance creation

Create one instance of API Management named as APIMPrimary in central india resource group in standard mode and another one as APIMDR in south India resource group.

Create both instances of API Management in Developer sku without Azure VNET integration if you are just doing a POC. If you are actually configuring API Management DR in your Dev/ Prod etc. environment, then create with Standard tier only. For this blogpost and to save my Azure bill, I am creating with Dev tier only.

Add backend APIs

If you already have APIs added in your existing API Management instance then we are good. For my API Management instance I added few APIs as shown through hosting on App services.

Service principal creation

Service principal will be required to authenticate logic apps so that I can perform management operation of backup and restore on both API Management instances. For creating service principal and generate the token refer the below documentation -

Get authentication/secret key and application id as described in the blog post and record it for future use. Then follow the section of “Assign correct permissions to Azure AD App” to provide necessary permissions. This application will be used inside the Logic App to perform backup and restore operation against API Management. Therefore the same application will also require access on Resource group as “API Management Service contributor” so that it can perform backup and restore operation against the Azure API Management.

Note – Remember we are using Logic app only to automate the backup and restore operation so that it happens automatically during off business hours. Logic app do not require any permissions on API Management, neither Azure AD app require permissions on Logic app. Refer to below section for providing access to Azure AD application over resource group.

Assign Azure AD app permissions on Resource groups in primary and DR

Assign permissions as shown in below screenshot. Primary resource group – API Management Service Contributor.

Secondary resource group – Contributor.

Create Storage account

Create storage account named as apimdrstor [or of your choice] as per the steps here in DR region resource group -

Then create container named as “apimbackup” in this storage account as shown below –

Logic App – Backup Operation for API Management

Create Logic app as described on the link. Make sure that you name the Logic App as “APIM_LogicApp”. Create this logic app in South India [secondary region] and NOT in Central India [primary region].

Follow only Create step of Logic app and then click on “Blank Logic App”. Do not follow rest of the article. Now click on “Logic App code view” option and then copy paste the code of file “APIM-Backup-LogicApp-CodeView – Generic.json” from the GitHub repository -

 Also replace the value of below setting with your own values –

"accessKey": "StorageAccountAccessKey-you created in DR region resource group",
"apimInstance": "name of primary region API Management instance",
"applicationId": "Service principal application ID",
"backupName": "Name of the backup file.",
"clientSecret": "Service principal secret Key",
"containerName": "name of the container you added in storage account.",
"operation": "backup", - don’t make any change here.
"resourceGroup": "Resource group name of primary region where primary API Management instance is present",
"storageAccount": "name of the storage account created in DR region resource group",
"subscriptionId": "Your Azure subscription ID",
"tenantId": "Your Azure AD tenant ID"

Now open the designer view. Steps created will be as shown –

Configure the Recurrent step as per your requirement. As a guideline configure the recurrence per day during night time/ off business hours. This completes the configuration backup Logic app. Enable and it should execute automatically based on the schedule.

Logic App – Restore Operation for API Management

Create new Logic app in DR region resource group only; named as “APIM_LogicApp_Restore” same as previous step with Blank template and copy paste the same template JSON code of above backup step on the code view. Make changes in the values as shown below.

accessKey": "StorageAccountAccessKey-you created in DR region resource group",
"apimInstance": "name of secondary region API Management instance",
"applicationId": "Service principal application ID",
"backupName": "Name of the backup file on which backup is created in storage account blob.",
"clientSecret": "Service principal secret Key",
"containerName": "name of the container you added in storage account.",
"operation": "restore", - Change backup operation to restore value. don’t make any other change here.
"resourceGroup": "Resource group name of secondary region where secondary API Management instance is present",
"storageAccount": "name of the storage account created in DR region resource group",
"subscriptionId": "Your Azure subscription ID",
"tenantId": "Your Azure AD tenant ID"

Also make sure that you change the name/ heading of last operation step to Restore instead of backup. Make sure you select DR region resource group. Click on purchase to complete the deployment. This deploys the logic app required for restore operation of API Management.

Your logic app for restore process will be shown as below in designer view –

Change recurrence steps as per your need. General best practice is you should have 2 hours of difference between backup and restore operation. For example you are starting backup at 11PM then start restore at 1AM. The above steps completes/ syncs to API Management instances.

The important part of the DR configuration of Azure API Management in standard is completed. Now we head over to Part 2 of the article to perform below steps –

1.     Traffic manager configuration for distributing load to primary always and to secondary in case of disaster.
2.      Configure the status page of API Management in traffic manager
3.      Configure custom domain and certificate for API Management and traffic manager
4.      Test the failover by downgrading one of backend APIs and mocking the response
5.      Benefits of approach and conclusion

Part 2 link is here -

A humble request!

Internet is creating a lot of digital garbage. If you feel this a quality blog and someone will definitely get benefitted, don't hesitate to hit share button present below. Your one share will save many precious hours of a developer. Thank you.


  1. awesome, finally I have implemented this solution for my client...they are happy :)

  2. very nice blog, a small request - could you please explain the Traffic manager config also which is actually difficult to understand