Skip to main content
This article describes how Azure Traffic Manager makes DNS-level routing decisions and explains the available routing methods (Priority, Weighted, Performance, Geographic). Traffic Manager does not proxy user traffic — it returns an endpoint IP via DNS and the client connects directly to that endpoint. Use the routing method that best matches your goals for availability, performance, and compliance. For further reading, see the official documentation: Common DNS flow (applies to all routing methods)
  1. A user requests a URL; the browser asks a recursive DNS resolver to resolve the domain.
  2. The recursive resolver queries Azure Traffic Manager for the domain.
  3. Traffic Manager evaluates configured endpoints using the chosen routing method and health probes.
  4. Traffic Manager returns the selected endpoint IP to the resolver.
  5. The resolver hands that IP to the client, and the client connects directly to that endpoint.
Because decisions are made at the DNS level, caching (TTL) affects how quickly routing changes propagate.

​
Priority routing (active–passive failover)

How it works:
  1. The client’s DNS resolver queries Traffic Manager for the domain.
  2. Traffic Manager orders endpoints by configured priority (primary = priority 1, then failover A = priority 2, etc.).
  3. Health probes continuously check endpoints.
  4. If the primary endpoint is healthy, Traffic Manager returns its IP. If not, Traffic Manager returns the highest-priority healthy endpoint (failover A, then failover B).
  5. The resolver returns the IP to the client, which connects directly to that endpoint.
Use cases:
  • Disaster recovery (active/passive)
  • Primary/backup scenarios where a single endpoint should carry traffic unless it fails
A diagram of Azure Traffic Manager’s Priority routing method, showing a browser/recursive DNS flow to Traffic Manager which chooses the highest-priority healthy endpoint (Primary, Failover A, Failover B). It also shows health checks and notes that the client connects directly to the selected endpoint rather than through Traffic Manager.

​
Weighted routing (traffic distribution)

How it works:
  1. The resolver forwards the DNS query to Traffic Manager.
  2. Traffic Manager considers all enabled, healthy endpoints and their assigned weights.
  3. An endpoint is chosen randomly, proportional to its weight. Example: Test A weight 5 vs Region B weight 50 -> Region B receives the majority of traffic.
  4. Unhealthy endpoints are excluded from selection.
  5. The resolver receives the chosen endpoint IP and returns it to the client.
Use cases:
  • Gradual rollouts, canary deployments
  • A/B testing
  • Balanced traffic distribution across multiple deployments
A diagram of Microsoft Azure Traffic Manager illustrating the weighted traffic-routing method where a browser's DNS query is handled by a recursive DNS and the Traffic Manager which selects an endpoint based on configured weights. The example shows three endpoints—Region A (weight 50, degraded), Test A (weight 5, online), and Region B (weight 50, online).

​
Performance (latency) routing

How it works:
  1. The resolver queries Traffic Manager for the domain.
  2. Traffic Manager uses the source IP of the DNS query (usually the recursive resolver’s IP) and a latency table to estimate which endpoint provides the lowest network latency for the user.
  3. Traffic Manager verifies endpoint health and returns the healthy endpoint with the lowest estimated latency.
  4. The resolver returns that endpoint’s IP to the client; the client connects directly to it.
Notes:
  • Performance routing helps globally distributed users reach the nearest/lowest-latency endpoint.
  • Accuracy depends on the DNS query source IP. If the resolver is far from the end user (some public resolvers), the selected endpoint may not be the actual lowest-latency server for the client.
A network diagram showing Azure Traffic Manager’s Performance routing: a browser’s DNS query is resolved via a recursive DNS and Traffic Manager, which uses a latency table to send traffic to the closest endpoint (West US, North Europe, or East Asia). The flow is numbered to show query and response steps between user, DNS, Traffic Manager, and endpoints.

​
Geographic routing (region-based routing)

How it works:
  1. The resolver forwards the DNS query to Traffic Manager.
  2. Traffic Manager determines the geographic location of the query from the source IP (typically the resolver IP) and maps that location to a configured endpoint or nested profile.
  3. Traffic Manager returns the endpoint or nested profile assigned to that geographic region. Examples:
    • Queries from Germany → Germany endpoint
    • Queries from Asia → nested profile that routes to Asia-specific endpoints
    • Unmapped regions → global/default endpoint
  4. The resolver returns the selected endpoint IP to the client, which connects directly to it.
Use cases:
  • Data residency and compliance
  • Localization (region-specific content/language)
  • Directing users to region-specific services
A diagram illustrating Azure Traffic Manager's Geographic routing method, showing how DNS queries flow from a user/browser through a recursive DNS service to Traffic Manager which directs traffic to region-assigned endpoints. Endpoints shown include Germany, a nested profile for Mexico/Asia, and other global/East Asia endpoints with priority settings.

​
Comparison table

Routing MethodBest forBehaviorTypical use cases
PriorityActive–passive failoverAlways prefer highest-priority healthy endpointDisaster recovery, primary/backup
WeightedControlled distributionRandom selection proportional to weightCanary releases, A/B testing, staged rollouts
Performance (Latency)Lowest latency for usersChooses endpoint with lowest estimated network latencyGlobal load distribution for improved response times
GeographicRegion-based controlRoutes by geographic mapping of DNS query source IPCompliance, data residency, localized content
Traffic Manager makes routing decisions at the DNS layer. DNS TTL values determine how quickly routing changes propagate — lower TTLs enable faster failover but increase DNS query volume. Configure TTLs according to your failover and traffic requirements.
Traffic Manager does not proxy or inspect application traffic. Ensure health probes (protocol, path, interval, and expected response codes) are configured correctly so unhealthy endpoints are excluded from DNS responses.

​
Key operational considerations

  • Health probes are critical: misconfigured probes can cause healthy endpoints to be considered unhealthy, or vice versa.
  • DNS caching and TTL: resolver and client caching affects failover speed. Test TTLs and probe intervals together to achieve the desired recovery behavior.
  • Public DNS resolvers: some public resolvers may not be topologically close to end users, which can reduce accuracy for Performance and Geographic routing.
  • Nested profiles: Geographic routing supports nested profiles to combine region-specific logic with other routing methods.
Summary
  • Azure Traffic Manager makes all routing decisions at the DNS level; user traffic always flows directly to the selected endpoint.
  • Use Priority for active–passive failover, Weighted for controlled distribution, Performance for low-latency routing, and Geographic for compliance and localization.
  • Configure health probes and TTLs carefully to ensure the expected routing behavior.
Now that you understand each routing method and its DNS-level behavior, choose the method that best fits your availability, performance, and compliance goals.

Watch Video