Are you worried about the DNS routing of your application? Don’t know how to balance the load for the application? Do matters like downtime, latency, availability, and performance stress you out?
The solution to these issues is Azure Traffic Manager. Azure Traffic Manager is a DNS-based load balancer which is easy to use and configure. It sends the DNS responses directly to the clients’ appropriate service endpoint. And then the client connects to the service endpoint directly, not through the Traffic Manager, but the service DNS is masked with Traffic Manager DNS. Traffic Manager provides DNS level traffic routing, load balancing, and failover capabilities to the application.
How Is it Different to Route 53 on AWS?
Whilst Route 53 on AWS provides both DNS management and load balancing capabilities under one roof, in Azure there are two different services. For DNS management, it is necessary to configure or use Azure DNS service, whereas for traffic routing and load balancing, you can use Traffic Manager. We can say Traffic Manager provides a subset of abilities that Route 53 can do, but with more control and in an easy-to-understand and user-friendly way. Don’t worry if you are used to control the DNS level traffic routing the AWS way, it won’t be any harder for you to understand the Azure Traffic Manager way.
Easy to Set up!
All you need is a Traffic Manager profile for your application. It can be treated as DNS traffic load balancing policy that can be created with a few simple clicks and you are ready to go.
Prerequisites:
As for any Azure service, you need a few basic things:
- Azure subscription
- Resource group
- Region information
- Web app
Of course, you need a web app, otherwise, where would you route your application to? 😉
You can follow the basic steps to create a web app from here. For the purpose of this post, we use the ASP.NET web app but you can use any web app you like. Or if you already have one, you can configure that.
Set up the Traffic Manager Profile
As mentioned before, the Traffic Manager profile is like a policy that tells your Traffic Manager what to do in a very abstract way. To create a profile, follow these steps:
- On the Azure portal, select create a resource from the menu in the upper-left corner of the screen.
- Then select Traffic Manager profile.
- Fill in the data as requested, like:
- Name → a unique name
- Routing method → you can select priority as per the official Azure docs or you can choose your own as per your needs.
- Subscription and resource group name
- Location
- Select create,
and the profile will be created. Magic, isn’t it?
Set up the Endpoints
The last and final step is to set up the routing for your web app, or I should say, configure the endpoint for your app. To configure, again, just a few clicks and it can be done in the following ways as described by the official documentation as well:
- Go to Endpoints on the left-side menu in the Traffic Manager profile you just created.
- On the top of the screen, select add, and on the new screen that will appear, select the following values:
- Type: Azure endpoint, you can select the other as well, depending on your application. For us, we have the Azure web app as our Azure endpoint.
- Name: again, a unique name.
- Target resource type: app service
- Target resource: choose app service in your location.
- Priority: 1
- Select add and an endpoint will be added.
- To create a failover endpoint, follow the steps above again and you will have another one created, but this time select priority 2.
Now, this priority is very crucial, for it will tell the Traffic Manager where to redirect next on the list when one route is fully loaded. So, if priority 2 is not available, Traffic Manager will go to priority 3 and so on to the next one in the sequence. This way, you can set different endpoints with different priorities pointing to applications in different resource groups. You can also control the traffic by telling Traffic Manager to redirect only a certain percentage, say 15% of the traffic to one certain endpoint and the rest to another endpoint. This way, you can test the deployment on the production environment without damaging the flow of the application. Say you redirected 1% of the traffic to a certain endpoint, which I believe will have the monitoring configured, so you can monitor if the request is successfully passed or not. And if not, you can bring down the new deployment and try again.
How Does it Work?
Now, the entire game of Traffic Manager is based on the priorities that we have set earlier. It also adds if the endpoint is enabled or not. The Traffic Manager will always point to the endpoint with the next highest priority in the enabled or online band of the endpoints. You can have multiple endpoints with multiple levels of priorities depending on application requirements and budget.
So, when the next request comes in, that request will go to Traffic Manager and Traffic Manager will do the rest. Check out the diagram below to get a better understanding.
And that’s how simple it is. No issues with balancing the load, if one endpoint fails to handle the other, it will be queued in right away. A failover mechanism has been provided which works with absolute charm. Now, the application can be accessed from the Traffic Manager DNS and you can also prevent actual DNS from getting exposed.
How Much Does it Cost?
The Azure Traffic Manager is not that costly either. For the first billion queries you pay €0.487/ million queries of the month and every subsequent million queries of the month for €0.338. So, the secured and load balanced response of your web app for a billion requests will cost you roughly €487 per month and €0.338 per million queries thereafter.
In this post, we discussed how to set up the Traffic Manager for our web app, how to set up the endpoints to different resources in case of failover, and how the Traffic Manager hides the original DNS. All in all, it is a good feature that can provide additional benefits.
Photo by Denys Nevozhai on Unsplash