Azure Traffic Manager Routing Methods Explained

Azure Traffic Manager is a DNS-based traffic load balancer. It works by returning a DNS response that points the client to the endpoint selected by the routing policy, rather than proxying traffic through a central point. This means it adds DNS-level latency (a single round trip) rather than network-path latency, and it works across any internet-accessible endpoint: Azure regions, on-premise datacentres, or third-party hosting.

Six routing methods are available. Each solves a different problem. Choosing the wrong one gives users slower responses, fails to provide the failover behaviour you expect, or ignores geographic requirements that matter.

Priority routing: active-passive failover

Use case: One primary endpoint handles all traffic. A secondary endpoint is on standby for failover. You want all traffic to go to the primary as long as it is healthy.

Priority routing assigns a numeric priority to each endpoint (lower number = higher priority). Traffic Manager sends all traffic to the lowest-priority endpoint. If the health probe on that endpoint fails, traffic shifts to the next lowest priority. This is explicit active-passive failover.

Example configuration: primary endpoint in UK South (priority 1), secondary endpoint in West Europe (priority 2). All traffic goes to UK South. If UK South fails its health probes, Traffic Manager returns the West Europe endpoint to all DNS queries until UK South recovers.

The DNS TTL on the Traffic Manager profile controls failover speed. A 60-second TTL means clients can take up to 60 seconds (plus probe detection time) to switch to the secondary after the primary fails. Set TTL based on your RTO requirement: lower TTL speeds up failover but increases DNS query volume.

Performance routing: lowest latency to the nearest endpoint

Use case: Endpoints in multiple regions. Route each user to the endpoint that will give them the lowest latency response.

Performance routing evaluates each user's query source against a Microsoft-maintained latency table that maps source IP ranges to Azure regions. The query is directed to the endpoint that the table indicates will have the lowest latency for that user's region.

This is not real-time latency measurement: it uses the static latency table rather than measured round-trip times. For most use cases this is sufficient and provides the expected nearest-region routing. For workloads where actual latency must be measured, Azure Front Door's anycast routing is a better fit.

Performance routing distributes load geographically, which means each endpoint must be independently scaled to handle its regional traffic volume. Unlike weighted routing, Traffic Manager does not balance load between endpoints: each user gets the closest one.

Weighted routing: A/B testing and gradual rollout

Use case: Distribute traffic between multiple endpoints in configurable proportions. Gradually shift traffic to a new version, or test two configurations with a specific traffic split.

Weighted routing assigns a weight (1-1000) to each endpoint. Traffic Manager distributes queries proportionally: an endpoint with weight 800 receives 80% of traffic; an endpoint with weight 200 receives 20%.

For a canary release: start with the new version weighted at 50 and the old version at 950, giving the new version approximately 5% of traffic. Monitor error rates and latency on the new version. Gradually increase its weight as confidence grows.

Weighted routing can also provide rough load distribution for endpoints of similar capacity. For precise load distribution with real-time awareness of backend health and connection count, Application Gateway or a layer 7 load balancer is more appropriate.

Geographic routing: data residency and compliance

Use case: Route users from specific countries or regions to specific endpoints, regardless of latency. Required for data residency obligations (GDPR, UK GDPR) where data about users in a given jurisdiction must be processed in that jurisdiction.

Geographic routing maps geographic regions (countries, continents, or the "world" catchall) to endpoints. A query from a user in the UK is always directed to the UK South endpoint, regardless of which endpoint is closest. A query from a user in Germany is always directed to the West Europe endpoint.

If an endpoint is unhealthy and no other endpoint covers the same geographic region, Traffic Manager returns the DNS name anyway (unlike most other routing methods, which fail over to a healthy endpoint). This behaviour exists because geographic routing is typically a compliance requirement rather than a performance optimisation: returning a degraded response in the correct region may be preferable to redirecting to a different region and violating data residency rules.

For this reason, health probe failures with geographic routing should trigger immediate incident response rather than relying on Traffic Manager to handle them transparently.

Subnet routing: IP-based segmentation

Use case: Route traffic based on the source IP address of the DNS query, regardless of geographic location. Route specific IP ranges (office networks, partner networks) to a specific endpoint.

Subnet routing defines IP address ranges mapped to specific endpoints. Queries originating from a defined range are directed to the assigned endpoint; all other queries can be directed to a default endpoint.

Use cases: route corporate VPN users to an internal-facing endpoint while routing public users to an internet-facing endpoint; route a specific partner's IP range to a dedicated integration endpoint; route QA team IPs to a staging endpoint.

Multivalue routing: return multiple endpoints

Use case: Return multiple healthy endpoints in a single DNS response, allowing the client to choose. For DNS-based service discovery where clients have logic to select from multiple addresses.

Multivalue routing returns multiple endpoint addresses in the DNS response rather than a single one. The client can implement selection logic (round-robin, random, preferred) and can fall back to another returned endpoint if the first is unavailable without making a new DNS query.

This is appropriate for clients that implement their own retry and selection logic. For standard HTTP clients, the other routing methods that return a single authoritative endpoint are more appropriate.

Nested Traffic Manager profiles

Any of the routing methods can be combined using nested profiles. A common pattern: a parent profile using Geographic routing directs UK users to a nested child profile covering UK endpoints and EU users to a nested child profile covering European endpoints. The child profiles use Priority routing to handle failover within each region.

Nested profiles allow complex routing logic to be composed from simple building blocks, without creating a single profile with many endpoints and a complex routing rule.

Monitoring and health probes

Traffic Manager health probes test each endpoint at a configurable interval (10-30 seconds). An endpoint that fails a configurable number of consecutive probes (default: 3) is marked unhealthy and removed from routing consideration (except for geographic routing, as noted above).

Configure the health probe path to a genuine health check endpoint, not the root path. A root path that returns 200 regardless of application state gives Traffic Manager a false healthy signal for a broken endpoint.

Monitor Traffic Manager's endpoint health via Azure Monitor. Alert when any endpoint is marked degraded, so the underlying cause is investigated before the failover to a secondary endpoint compounds into a multi-region incident.

Where Critical Cloud comes in

Getting Traffic Manager routing right, particularly the interaction between geographic routing compliance requirements and failover behaviour, is the kind of architectural nuance that costs you at incident time if it was guessed at rather than designed deliberately. We design and operate Azure multi-region networking for regulated businesses. See how Critical Support works.