So Traffic Manager is a service provided by Azure that works essentially as a DNS service that allows you to deploy an app to multiple physical locations on the globe and have all of them share the workload. It has three modes it can function in:

  1. Performance: routes user to instance that gives them the fastest response (usually closest one geographically)
  2. Weighted: distributes traffic to endpoints based on weights assigned to them. Can be used for load-balancing or exposing a new version to some users. (called Round-robin in Traffic Manager Classic, it also lacked the weights)
  3. Priority: routes user to priority number 1 instance if it is available, otherwise to the next priority endpoint. Used for fail-over scenarios. (called Fail-over in Traffic Manager Classic)

But what it can also do is have Traffic Manager profiles nested inside each other.

The official documentation at the time of writing describes nested profiles but doesn't show proper examples of doing it.

I wanted to write a nice concrete example of doing just that: using nested Traffic Manager profiles. What I want is:

  1. One Web App instance in North Europe and one instance in West Europe sharing traffic 50/50 with a Traffic Manager profile running weighted mode
  2. One instance in East US registered to another Traffic Manager profile along with the European Traffic Manager profile. This main Traffic Manager profile would run in Performance mode and be the one users would access.

Unlike the official documentation says today, you can do everything in Azure Portal. No PowerShell needed :)

After creating the Web Apps, I created the European Traffic Manager profile in Weighted mode:

Creating EU profile

And added the two European instances to it with a weight of 1 so they will both receive an equal amount of traffic.

Adding North EU endpoint

Then I created the main Traffic Manager profile in Performance mode:

Creating main profile

Added the East US endpoint in a similar fashion, and then added the European profile as a nested endpoint:

Adding nested endpoint

Note the Minimum child endpoints setting. This sets how many endpoints in the nested profile must be available for the nested endpoint to count as available. By setting it to 1 we will still direct traffic to it even if North or West EU goes down.

Also note the Location setting, which I have set to West Europe. Since the main profile runs in Performance mode, it must decide which endpoint to route the user based on locations. So the main profile will consider the European nested profile as if it was an endpoint in West Europe.

I then switched the main profile to Weighted mode so I could test that it is working and deployed an app which clearly identified which instance it is on the main page.

Here is a screenshot:

East US instance

But there is a problem!

If we hit one of the European instances, we get a 404 site not found. Why is that? Nslookup was showing all of them so I knew Traffic Manager is working. The problem as it turns out, is the Host header. This is sent by the browser so the web server knows what site to show. Now Traffic Manager does register its own domain name in the Web Apps, like this:

Traffic Manager domain name added

But where is the main Traffic Manager profile domain name?? It does not get added :(

Could I just add the main Traffic Manager URL to the Web Apps?... Yes!

Main Traffic Manager domain name added

Great success! :)

I was then able to hit all the instances from the main URL, achieving what I wanted.

Using Traffic Manager for globally highly available applications is now easier than ever. Deploying instances in more data centers as an app grows can ensure it has the resources it needs.