Azure Traffic Manager: How DNS-Based Global Traffic Routing Works

Azure Traffic Manager is a DNS-based traffic load balancer that distributes traffic to service endpoints across different Azure regions and data centres worldwide, improving responsiveness and providing high availability. It works purely at the DNS layer: a client's DNS query resolves to the address of the best available endpoint for the profile's routing method, and the client then connects to that endpoint directly. Because Traffic Manager never sits in the data path, it doesn't provide caching or SSL termination — those responsibilities belong to whatever sits in front of the endpoint itself. It continuously health-checks every endpoint, and an unhealthy endpoint is never returned in a DNS response until it recovers.

How Traffic Manager Works

A client sends a DNS query to resolve the service's domain name.
The query is directed to Traffic Manager.
Traffic Manager applies the profile's routing method to determine the best endpoint.
Traffic Manager returns that endpoint's address to the client.
The client connects directly to the chosen endpoint.

Routing Methods

Traffic Manager supports six traffic-routing methods. Each profile applies exactly one.

Priority Routing

Directs all traffic to a single primary endpoint, defined by a numerical priority — the lower the number, the higher the priority. If the primary endpoint becomes unavailable, traffic fails over to the next-highest-priority endpoint, and so on down the list, giving a chain of fallback endpoints rather than just a single backup.

Weighted Routing

Distributes traffic across a set of endpoints in proportion to a weight assigned to each one — an integer from 1 to 1000, defaulting to 1 if omitted. A higher weight means a larger share of traffic, not higher priority — priority is a separate, unrelated setting used only by Priority routing. Setting every endpoint to the same weight splits traffic evenly; skewing the weights allows a gradual rollout, such as slowly increasing a new endpoint's share over time.

For example: Region A at weight 50, Region B at weight 50, and a Test A endpoint at weight 5 — Region A and Region B each take roughly equal, large shares of traffic, while Test A receives a small fraction. If Region A becomes unhealthy, its share fails over to Region B and Test A.

Performance Routing

Routes each user to the endpoint with the lowest network latency, not the geographically closest one — "closest" is measured in round-trip time, not distance. Traffic Manager maintains an internal Internet Latency Table (ILT) tracking round-trip times between IP address ranges and each Azure data centre; this table isn't visible to the user. On a query, Traffic Manager looks up the source IP's round-trip time to each candidate data centre in the ILT and returns the lowest-latency healthy endpoint — if that endpoint is unhealthy, it moves to the next-lowest.

Geographic Routing

Routes traffic based on the geographic origin of the user's DNS query, not latency. Each endpoint is associated with a geographic profile, and a given location can only be mapped to one endpoint at a time. A catch-all "Rest of the World" endpoint can be defined to catch queries from any location that isn't explicitly mapped: a user in Germany resolves to the Germany endpoint; a user in the US, if no US endpoint is defined, falls through to "Rest of the World". This is the routing method to reach for when data-sovereignty or content-localisation requirements mean a query must always resolve to a specific region.

Multivalue Routing

Returns every healthy endpoint in a single DNS response, rather than just one. It only applies to profiles where every endpoint is defined as a literal IPv4 or IPv6 address, using the External endpoint type — it isn't available for Azure-native endpoint types. Giving the client several healthy addresses to choose from means it can retry against a different one without a second DNS lookup, which is the main reliability benefit over the single-answer methods above.

Subnet Routing

Maps ranges of end-user IP addresses to specific endpoints, defined as CIDR blocks (e.g. 1.2.3.0/24) or address ranges (e.g. 1.2.3.4-5.6.7.8). When a query arrives, Traffic Manager checks the source IP against the configured mappings and returns whichever endpoint that range is assigned to. It's the method to reach for when routing needs to follow a known IP allocation — an ISP's address blocks, or a corporate network's — rather than geography or latency.

Nested Traffic Manager Profiles

Traffic Manager profiles can be nested to combine two routing methods, since a single profile only ever applies one. A "child" profile is added as an endpoint inside a "parent" profile, and each layer applies its own routing method independently — Microsoft's own documentation uses Performance routing at the parent with Weighted routing at the child as its example, but any pairing is possible.

One common pairing is Geographic routing at the parent with Priority routing at the child — useful for routing a whole region to a set of endpoints ranked by preference. For example: a parent profile using Geographic routing, with nested child profiles for Mexico and Asia. Inside the Mexico child profile, Endpoint A has priority 1 and Endpoint B has priority 2. A user in Mexico is first routed to the Mexico child profile by geography, then Traffic Manager applies priority routing within it — Endpoint A is chosen unless unhealthy, in which case traffic falls back to Endpoint B.

Gotchas & Caveats

No caching or SSL termination. Traffic Manager only ever returns a DNS answer — it's never in the data path, so it can't cache responses or terminate TLS. Anything that needs to inspect or manipulate the actual traffic has to sit at the endpoint itself.
Multivalue routing only works with External endpoints. It's restricted to profiles where every endpoint is a literal IPv4/IPv6 address — it isn't available for Azure-native endpoint types like an App Service or a public IP resource.
Geographic routing is exclusive per location. A single country/region or state can only be mapped to one endpoint in a Geographic-routing profile — there's no way to split one location's traffic across two Geographic endpoints.