Route Global Traffic with Azure Traffic Manager (2026)

Azure Traffic Manager is actually a DNS-level load balancer, not an IP-level one, which means it directs traffic before it even hits your Azure resources.

Let’s see it in action. Imagine you have two web apps, webapp-east.azurewebsites.net and webapp-west.azurewebsites.net, deployed in different Azure regions. You want users to hit the closest one for the best performance.

First, you create a Traffic Manager profile in the Azure portal. You give it a name, say my-global-traffic-manager, and choose a routing method. For this scenario, we’ll pick Performance.

{
  "name": "my-global-traffic-manager",
  "type": "Microsoft.Network/trafficmanagerprofiles",
  "location": "global",
  "properties": {
    "profileStatus": "Enabled",
    "trafficRoutingMethod": "Performance",
    "dnsConfig": {
      "fqdn": "my-global-traffic-manager.trafficmanager.net",
      "ttl": 60
    },
    "monitorConfig": {
      "profileMonitoringConfiguration": {
        "protocol": "HTTP",
        "port": 80,
        "path": "/",
        "intervalInSeconds": 30,
        "timeoutInSeconds": 10,
        "toleratedNumberOfFailures": 3,
        "customHeaders": []
      }
    },
    "endpoints": [
      {
        "name": "EastUSWebApp",
        "type": "Microsoft.Network/trafficmanagerprofiles/azureEndpoints",
        "properties": {
          "endpointStatus": "Enabled",
          "endpointWeight": 1,
          "endpointLocation": "eastus",
          "endpointTrafficFromLocation": "EastUS",
          "geoMappings": [
            "WORLD"
          ],
          "priority": 1,
          "targetResourceId": "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/my-rg/providers/Microsoft.Web/sites/webapp-east",
          "minChildEndpoints": 1
        }
      },
      {
        "name": "WestUSWebApp",
        "type": "Microsoft.Network/trafficmanagerprofiles/azureEndpoints",
        "properties": {
          "endpointStatus": "Enabled",
          "endpointWeight": 1,
          "endpointLocation": "westus",
          "endpointTrafficFromLocation": "WestUS",
          "geoMappings": [
            "WORLD"
          ],
          "priority": 2,
          "targetResourceId": "/subscriptions/YOUR_SUBSCRIPTION_ID/resourceGroups/my-rg/providers/Microsoft.Web/sites/webapp-west",
          "minChildEndpoints": 1
        }
      }
    ]
  }
}

Here’s what’s happening under the hood. When a user types my-global-traffic-manager.trafficmanager.net into their browser:

1. Their DNS resolver asks for the IP address for my-global-traffic-manager.trafficmanager.net.
2. Azure Traffic Manager receives this DNS query.
3. It looks at the source IP address of the DNS query (which represents the user’s general location).
4. Based on the Performance routing method, it determines which endpoint (webapp-east or webapp-west) is closest or has the lowest latency from that query’s source IP.
5. Traffic Manager returns the IP address of the chosen Azure web app (e.g., webapp-east.azurewebsites.net) in its DNS response.
6. The user’s browser then makes a direct HTTP request to the IP address of webapp-east.azurewebsites.net.

The monitorConfig section is critical. Traffic Manager actively probes your endpoints (in this case, checking if HTTP://your-app-url/ is responding within 10 seconds). If an endpoint fails three consecutive probes, Traffic Manager marks it as unhealthy and stops sending traffic to it, automatically rerouting users to a healthy endpoint.

The geoMappings is a powerful feature for routing. You can define specific geographic regions that should be directed to a particular endpoint. For example, you could map US to your US-based endpoints and EU to your European endpoints. If you have a WORLD geo-mapping, it essentially means "if no other specific geo-mapping applies, send them here."

A common misunderstanding is that Traffic Manager sits in front of your applications, like a proxy. It doesn’t. It only resolves the DNS name. The actual traffic flows directly from the user to your Azure resource. This is why it’s so performant and cost-effective.

One subtle point: Traffic Manager’s "performance" is based on probe latency from its own probes, which are located in various Azure regions, not directly from the end-user’s location. While it’s a good proxy for user experience, it’s not a perfect 1:1 mapping. The DNS TTL (Time To Live) of 60 seconds means that once a client’s DNS resolver gets an IP address, it caches it for up to 60 seconds. If your Traffic Manager endpoint status changes during that TTL, clients might still be directed to the old, potentially unhealthy endpoint until their cache expires.

The next logical step is to explore how to integrate Azure Front Door for more advanced features like SSL offloading and WAF.