Do you have a global user base and would like to customize content based on regions where your users are located? Have you felt the need to comply with policy mandates that require the restriction of data access within a Geography?
With the availability of Geographic Routing capability in Azure Traffic Manager, such needs can be easily addressed. You can now direct user traffic to specific endpoints based on the geographic location from where the requests originate. Azure’s global presence enables you to reach a user base that is vast and diverse across nations and regions, and with Geographic Routing you can now enable a variety of use cases that are tied to geography – such as:
- Customizing and localizing content for specific regions, enabling better user experience and engagement. As an example, an e-commerce site can localize the site content and merchandise items to users in a specific region.
- Knowing where the users are coming from makes it easier to implement mandates related to data sovereignty.
Configuring geographic routing
Defining user regions
The first thing to do is to partition your user base according to their geographic location/region. There are different levels of granularity by which you can specify a geographic region:
- World – any region
- Regional Grouping – Africa, Middle East, Australia/Pacific, etc.
- Country/Region – Ireland, Peru, Hong Kong SAR, etc.
- State / Province – USA–California, Australia–Queensland, Canada-Alberta, etc. (Note: This granularity level is supported only for states / provinces in Australia, Canada, UK, and USA)
To get a list of the supported regions and the various choices within each region, you can refer to this list of regions used by Azure Traffic Manager geographic routing method. You can also obtain this information programmatically by calling Azure Traffic Manager’s REST API.
The below table gives you an example of how you can route traffic to your application deployed in specific Azure regions, based on where users are located.
|User Location(s)||Azure Region / Endpoint location|
|Europe, Africa||North Europe|
|Australia, New Zealand||Australia East|
|Mexico, USA-California, USA-Oregon, USA-Washington||West US|
|Rest of the world and any requests that cannot be mapped to a geographic region||Central US|
Sample table directing traffic from user location to specific application deployment Azure regions
Create a Traffic Manger Routing Profile with geographic routing
Go to the Azure portal, navigate to Traffic Manager profiles and click on the Add button to create a routing profile.
Add a Traffic Manager Profile
Provide a Name for your profile, select Geographic to be your Routing method, select the Subscription and Resource group you want to use. Click on OK to create the profile.
Add geographic routing method to profile
Once the create is successful, navigate to the profile. You can now see the details including the DNS name and the Routing method (Geographic) you had specified.
DNS name and routing method
Click on the Endpoints button and then the Add button to add your endpoints, to this profile.
When adding an endpoint, you will be prompted to set the Geo-mapping for this endpoint. Add the four endpoints based on the mapping we had described earlier.
Associate endpoints to geographic routing
Once that is completed, you have an Azure Traffic Manager profile with geographic routing enabled as per your needs! Your users can use the DNS name associated with this profile to connect to your application. During DNS name resolution, Azure Traffic Manager will ensure users are directed to the right endpoint based on where their DNS query originates.
Regarding the accuracy in determining geographic regions, please note that Azure Traffic Manager will be using the source IP address of the DNS query to do the geographic region lookup, which in most cases will be that of the DNS resolver doing the querying on behalf of the user and any client subnet information that may be passed in is not considered. Even though the DNS resolver’s location is a good proxy for the user’s location, this need not be true in all the cases. In addition, we use an internal IP address to geographic region map that, although validated and updated on an ongoing basis, is not guaranteed to be an exact representation of the geographic location of all possible values in the IP address space.
Besides the Portal, you can use Rest API and .NET SDK to provision this capability. PowerShell and CLI support will be available in April 2017.
This feature is available today in all Azure Public cloud regions. This will be available in Azure Government, Azure Germany, and Azure China in May 2017.
How much does it cost?
The price is the same as with all other routing methods. For details, please refer to the Azure Traffic Manager pricing page.
To learn more about the capabilities and best practices related to this feature, please visit the Azure Traffic Manager routing methods and FAQs pages. We look forward to your valuable feedback as you start using this today.