Azure API Management Disaster Recovery in Standard – Part 2 – Traffic Manager with custom domain and way forward

Abstract

In the first part - https://sanganakauthority.blogspot.com/2019/08/azure-api-management-disaster-recovery.html we have configured below things –

1.      Created required resources in primary and secondary region
2.      Configured the Azure AD application and provided necessary permissions
3.      Configured the backup and restore functionality for Azure API Management and automated the same using Azure Logic Apps. This is crux of our DR solution of API Management in Standard sku.

In this part we will configure below things –

1.      Traffic manager configuration for distributing load to primary always and to secondary in case 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

Traffic Manager configuration

Create traffic manager as per the link described in secondary region resource group – https://docs.microsoft.com/en-us/azure/traffic-manager/quickstart-create-traffic-manager-profile#create-a-traffic-manager-profile .

Provide values as shown below –

Note the URL of API Management standard instances from primary and secondary instances as shown below  and highlighted by green line –

We will use these URLs as an “External endpoint” in traffic manager profile. Configure the traffic manager endpoint as shown below. Secondary API Management as priority 2 and primary API Management as priority 1.

Configure Health Status Page of API Management in Traffic Manager

For traffic manager to perform failover to secondary, it should have a health page configured inside it. Health page is the component which sends 200 [Http-OK] response to traffic manager. This way Traffic manager understands that primary instance of API Management is working and there is no issue. In case of disaster, same health page will send non 200 HTTP response. For any of the response other than 200 the traffic manager will start diverting the incoming traffic automatically to secondary API Management. The health page of API Management is by default configured to send 200 response and non 200 in case of disaster. You don’t have to worry about this. This is the power of Azure Serverless/ PaaS platform.

For Azure API Management the health status page is accessible at the address as “/status-0123456789abcdef”. Configure the same as shown below –

The port number above will change to 443 and protocol will be https in case you are planning for https configuration.

Custom domain configurations for Traffic Manager

Point your CNAME to traffic manager URL with you domain provider.

Kunalapi.co.in IN CNAME mytm.trafficmanager.net

For this blog post I purchased the custom domain from the GoDaddy. I am pointing this custom domain to Traffic manager URL. The domain name I purchased is kunalapi.co.in. Below are the settings I have configured in GoDaddy.

Custom domain configurations for Azure API Management

At this point if we access the API management using your custom domain name we get an error as – 503 service unavailable.

This is because Azure API Management only responds on hostnames registered on it. AS current custom domain we configured on Traffic manager is not added in Azure API Management; it simply denies the request. Therefore we need to configure the same custom domain we configured on Traffic manager also on Azure API Management instances. Below screenshot shows the configuration on DR region API Management instance. Similarly configure for primary region API Management also.

Similarly you should see the same custom domain name at Gateway URL filed on overview tab as shown below –

If you are using certificates then make sure they are mapped to kunalapi.co.in (-your custom domain name) or wild card certificate like *.api.com. For testing purpose you can use the self-signed certificate same as your custom domain and it should work for testing purpose.

Testing the DR scenario of Azure API Management

The bad new is You cannot customize the status of API M to respond non 200 response. In case of real DR situation only status page will respond non 200 response. So how do we test?

Therefore for testing purpose configure an API Page URL as a part of health page in above screenshot under “Path” value; use APIM Policy to mock response of the API to non-200 and check if Traffic Manager is sending request to secondary API M instance. Let me know if you need any help in configuring the API Management mock response policy.

Similarly to make sure that traffic is flowing through primary or DR region from traffic manager you can use nslookup to your custom domain. Below screenshot shows traffic manager flowing traffic to South India DR region post configuration of Mock response from one of the APIs  –

Benefits of the API Management DR in standard sku

You save a lot of cost as you don’t have to go for Premium sku of Azure API Management only for DR requirement. This is awesome benefit!

Another great benefits is – you can get promoted in your organization by showcasing that you helped to save Opex [Operational cost] for your customer/ organization. If you get promoted/ get an award due to this configuration share with me in comments. I would love to hear similar stories.

Word of advice on DR configuration

API Management DR with premium is inbuilt feature and hence it is seamless and recommended way. When you configure API Management DR with Standard you own the maintenance of the solution. While the solution I proposed works well you may want to reconsider the option of API Management premium for your DR needs. Also this is just the DR of API Management instance. In this blog we did not discuss about DR for underlying APIs, Databases and applications, and it is out of scope. However as a best practice you should consider DR at every layer of your application architecture.

In the solution proposed above I am considering there is no DR configured for underlying backend APIs. When you configure the DR for backend APIS as well in that case you will need to use the different API Management policy to transfer the request to respective backend APIs based on their availability status.

Conclusion

Hope these two long posts of step by step guide have helped you to configure the DR of Azure API Management and help you save some Opex [Operational cost] of your organization/ customers.

Happy DRing!!

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.