Welcome to Traffic Manager! In this lesson, we’ll touch on yet another load balancing feature, called Traffic Manager. We’ll look at what it is and what it does.

Azure Traffic Manager is a load balancer that works by distributing traffic using DNS. It’s a bit different from the Azure load balancer offerings that we discussed earlier. You typically use Traffic Manager to distribute traffic to services that are located across different global Azure regions. When you use Traffic Manager, you can ensure that your European users can access your application from and endpoint closest to them, while your North American users can access the same app from a service endpoint closest to them. This provides higher availability of your app and makes it more responsive to end user requests.

The way it works is pretty straightforward. What Traffic Manager will do is use DNS to send access requests to the service endpoint with the least latency for the requester, based on the configured traffic routing method and on the health of the endpoints that have been configured. The configured endpoints can be any Internet-facing service that’s hosted inside or outside of Azure. Its flexibility protects applications against failures, including the failure of an entire Azure region.

Because it works at the DNS level, Traffic Manager will use DNS to route incoming connections to the necessary endpoint, based on how the rules are configured and on the traffic routing method. Speaking of routing methods, there are several available when using Traffic Manager.

You have Priority, Weighted, Performance, Geographic, Multivalue, and Subnet.

If you want to send all incoming traffic to a primary service endpoint, while making backup endpoints available in the event the primary endpoint is not available, you would choose the Priority method.

The Weighted routing method can be used in situations where you need to split traffic out across multiple endpoints, based on weighting that you define. Weighted routing can also be used to evenly split traffic across multiple endpoints.

The Performance routing method is often used with applications that are distributed across multiple geographic locations. Choosing the Performance routing method allows you to direct users to the closest endpoint to them, when they access your application. This reduces latency for those users.

Geographic routing also allows you to force users to an endpoint closest to them, but it works a little differently than Performance routing. Geographic routing is performed based on the geographic location of the original DNS query. You would typically use Geographic routing to ensure a user in Europe access your application from a European endpoint. This is a useful option when you need to comply with sovereignty mandates.

The Multivalue option should be used for Traffic Manager profiles that can only have IPv4 or IPV6 addresses as endpoints.

And lastly, the Subnet routing method allows you to map specific ranges of end-user IP addresses to specific endpoints. This means you can force specific users, based on their IP addresses, to connect to certain endpoints.

Now, I should point out here, because its not always evident when I talk about it, that Traffic Manager is NOT a proxy or gateway. Despite all these routing methods that are available, what Traffic Manager actually does is play traffic cop. No traffic ever passes through Traffic Manager. Instead, Traffic Manager directs clients to the endpoints. The clients then make connections directly to those endpoints. Keep that in mind.

The picture on your screen shows how a client typically connects to an endpoint, using Traffic Manager.

Notice what happens here. The process starts off with a DNS query for the app called app.bluewidgetco.com from the client to the client’s DNS service.

Next, the DNS service reaches out to the name servers for the domain hosting the application, and those name servers return the CNAME record that points to the Traffic Manager implementation for the app. In this case, the CNAME record is called bluewidgetco.trafficmanager.net. The root domain will always be trafficmanager.net for Traffic Manager implementations.

At this point the client’s DNS service finds the name servers for the trafficmanager.net domain. These servers are provided by the Traffic Manager service itself. After finding the name servers for the trafficmanager.net domain, the client’s DNS service sends a request for bluewidgetco.trafficmanager.net.

Once the Traffic Manager name servers receive the request, they determine the correct endpoint, based on the state of the configured endpoints, the health of the endpoints, and the routing method that has been configured.

Traffic Manager then returns the CNAME record of the proper endpoint to the client’s DNS service. In this example, there are two deployments of the app. The app is deployed at bluewidget-us.cloudapp.net and at bluewidget-eu.cloudapp.net. Let’s assume the users is US-based and should hit the US-based deployment of bluewidget-us.cloudapp.net. In this scenario, the endpoint of bluewidget-us.cloudapp.net is returned to the client’s DNS service.

Once it receives the endpoint DNS name, the client’s DNS service finds the DNS name servers for the cloudapp.net domain and requests the DNS record for bluewidget-us.cloudapp.net. The cloudapp.net name servers respond to the client’s DNS service with the IP address of the US-based endpoint.

The client’s DNS service sends this information back to the client requesting access.

Once the client receives the DNS information and IP address for the US-based deployment, the client connects directly to that deployment.

So, as you can see here, Traffic Manager is heavily dependent on DNS. After all, like I mentioned at the outset, it’s a DNS-specific load balancing solution.

Join me in the next lesson, where I’ll show you how to create a Traffic Manager profile.