Understand Azure Traffic Manager

Q: What is Azure Traffic Manager?

A: Azure Traffic Manager provides globally aware DNS resolution to Azure services located in different regions using an intelligent set of processes based on specified configurations and the geographical location of the users local DNS server (LDNS). It's easiest to undestand by looking at an example. Consider the scenario shown below.

In this example, a Traffic Manager profile (which is a specific set of configurations for an address) is created for savtechwebapp1.trafficmanager.net which is configured with 3 endpoints that are separate deployments of the application hosted in Europe, US, and Asia Windows Azure regions.

The Traffic Manager profile name always has trafficmanager.net as the DNS suffix, but you set the prefix part of the name which must be unique within the Traffic Manager service. However, this prefix will not actually be seen by end users.

The organization's actual DNS server has a CName (alias) record created for the public DNS name in the organization's own DNS zone (known as a vanity domain in this case, as it's the public name to make it look nice for end users). The alias record points to the Traffic Manager profile name record (i.e., webapp.savilltech.net is an alias that resolves to savtechwebapp1.trafficmanager.net).

There are several load-balancing options for Traffic Manager profiles that control how requests are distributed. The most common is Performance, which attempts to resolve requests to the Azure service that's closest to the requesting user's local DNS server. This is shown in the example:

Note the ICMP latency; thus, whichever Azure region is considered closest is always based on the user's local DNS server and not where the users are physically located.

Therefore if you have users in Asia who are using a DNS server in the US, then those users would be directed to services in the US even if there was a service physically located in Asia.

Users that use global DNS servers will not be redirected to the closest Azure service with a high degree of confidence. Also the network latency maps are generated based on ICMP echo requests (pings) to DNS servers. This means if the local DNS server blocks ICMP, then the latency information would not be ascertainable (however, this isn't common as this ICMP approach is an industry standard).

I previously mentioned different types of load-balancing options, which are shown below:

To ascertain if an endpoint is online every 30 seconds, the Traffic Manager service performs a request using HTTP or HTTPS that can use a custom port to a specific URL, for example a specific application on the web services.

If four requests go unanswered (or if it takes longer than 10 seconds for each request) then the endpoint is considered unavailable and requests will not be directed there. The requests will continue every 30 seconds, and when the endpoint responds again, it will be considered online and requests will once again be directed to the endpoint as appropriate.

Traffic Manager endpoints are cloud services, which means the actual cloud services used need an endpoint for port 80 or 443 or whatever custom port you are using for the monitoring settings to be defined. This means the endpoints could be pointing to a single VM in each cloud service or a load-balanced set in each cloud service.

Note that a TTL can be configured as part of the profile, which is the time to live of the record in the DNS cache. This is 5 minutes by default. The smaller the TTL, the faster clients will be directed to another endpoint if an endpoint is not available, but this increases the number of requests to Traffic Manager, which might increase your cost.

At time of writing, Traffic Manager can only be used with endpoints for services hosted in Windows Azure, such as web roles, standard Azure websites, and IaaS virtual machines.