In the world of global companies, it's not beyond the realms of possibility to have a need to distribute your web traffic to a location closer to your visitors location. This in essence will speed up the response of the web site and provide a better end user experience. In this post, we look very simply at how to ensure clients are directed to the closest and fastest location when browsing to your website by using Azure App Services and Traffic Manager.

Before we go into this a little more, I want to look at the difference between Traffic Manager and a CDN. I had a conversation about this subject recently and was asked, "why would I use traffic manager instead of just a CDN". Well, let's take a look at the blurb directly from Microsoft.

In online content delivery, user experience is everything. Azure Content Delivery Network (CDN) lets you reduce load times, save bandwidth and speed responsiveness – whether you’re developing or managing websites or mobile apps, or encoding and distributing streaming media, gaming software, firmware updates or IoT endpoints.

As the name suggests the Content Delivery Network or CDN is about content, regardless of what that content is, and you can see some examples shown above. The idea, in a lot of ways similar to traffic manager is to ensure that content is closer to the end user, thus loading quicker.

Traffic Manager however is different, while on the face of it it enables the same result, traffic manager is actually a DNS-based load balancer. Again, as per Microsoft.

Azure Traffic Manager is a DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions, while providing high availability and responsiveness.

Depending on your requirements will determine if Traffic Manager is the right solution for you or not, for example if you are looking for additional capabilities such as SSL offloading then you would need to look at the Application Gateway. For regional load balancing then you would look towards Azure Load Balancer. Many options are available, Microsoft have a great article that discusses the load balancing options available to you in Microsoft Azure.

Benefits of Traffic Manager

If Traffic Manager is the tool of choice for your scenario, then it delivers a number of benefits. These include:

  • Improved performance
  • Ability to maintain without downtime
  • Nested profiles for complex deployments

Preparing our deployment

In order to get this up and running, we need three simple things, which are:

  • 1 x Traffic Manager profile
  • 1 x App Service in your primary region
  • 1 x App Service in your secondary region

To start with, I've created two resource groups. One in North Europe and one in UK South, this is where we will deploy our resources.

Deploying App Services

First of all, let's deploy both of our App Services, you could easily use a template to do this, however to give you an idea of the process, I'll do it manually in the portal. We shall deploy to North Europe first, this is going to act as our primary region, imagine our primary Azure investment is already in North Europe.

You can see from the screenshot below, we have a very basic configuration, we've given a unique name to our instance, for demo purposes, we've just selected .NET Core 3 as the runtime stack. Also note the deployment region is North Europe and the App Service Plan is North Europe and again for demonstration, this is a basic plan.

Deploy the App Service and then head to the second resource group and deploy the same in the other region, be sure to change your region and App Service Plan to be in the same place. The deployment of both resources should take no longer than five minutes.

Once this is completed, we need an easy way to tell which instance we are hitting when we browse to the website. To achieve this simply create a new file with the following content:

Welcome to North Europe

You can do this without the need for CI/CD or FTP for testing purposes. Select your App Service resource from the portal, then scroll down to Advanced Tools, which can be found under Development Tools. Here click Go and you will see a new window open.

From the menu bar at the top, open Debug console and select CMD. Browse through the site and wwwroot folder and you should see a file called hostingstart.html. You can then click the delete icon next to the file name, highlighted below, once this is completed click the plus icon and select New file. Enter index.html and then press Enter.

Finally, press the pencil icon to edit the file, enter the content above and click save. If you want to, navigate to the address of your App Service and verify it's working as expected. Repeat the process for your second region, changing the text inside to show the region you have deployed to. In my example this says Welcome to UK South.

Deploying Traffic Manager

Now both App Services are deployed and configured to our liking, we are ready to deploy Traffic Manager. Most resources you deploy in Azure are specific to a region, however, Traffic Manager is one which bucks that trend. It's a global service, which resource group you deploy it in technically doesn't matter. However you may have specific patterns to deploy to a specific place, I'll put it for demo purposes in my North Europe resource group.

Deploying Traffic Manager could not be simpler. Enter the name of the resource, this is the address your website will be available through. Routing method has a number of options, all of which are described in the documentation.

Before we continue, let me explain both Performance and Geographic routing methods. When you have endpoints in different geographic locations as in our demo here and you would like end users to use the nearest (in a network sense) endpoint in terms of the lowest network latency, you should select Performance.

If for example, you have data sovereignty rules, localisation of content and/or user experience then when selecting Geographic, based on the location of the originating DNS query, this enables Traffic Manager to route to specific endpoints, which enables the scenarios described previously.

In our example, performance would work perfectly well, however Geographic does have some more flexible functionality. So go ahead, select Geographic and create the resource, again this should take no more than a minute or so. A number of caveats exist for how the routing works based on different scenarios, ensure you consult the documentation to understand these in more detail.

Traffic Manager routing works based on a concept of Endpoints. Under Settings, click Endpoints and then click Add.

Although this looks confusing, the configuration is again fairly simple. As we are working with App Services, ensure you set Target resource type to App Service. Select the resource from the Target resource so it appears in the configuration. Then under Geo-mapping, select the Regional grouping as Europe. You can select a country or region as optional, but for now leave as Europe. At the bottom, click OK and this will add the profile. Note, that you cannot add the same location in two endpoints. On the main Endpoints screen, you will see that the endpoint is validated that it's online.

Add another profile, this time add a country in, to enable appropriate testing, make sure you add the country you are testing from. Again save the profile. You should note that unless you have a catch all in for the geographic region "All" then if someone from a region which is not specified in the endpoints hits your website, you will receive a NODATA response.

Final Test

Now everything is configured, go ahead and navigate to the address of your Traffic Manager profile. You should be directed to the closest place based on your configuration, for me this should be UK South.


Thankfully, you can see this is exactly what is happening. You can explore further testing by turning off the App Service and waiting to see what happens to your request. Play with the geographic settings to get the balance right for your website, this will ensure the performance is as expected, make use of telemetry to examine load times and where possible make improvements for your user experience.