Skip to main content
Azure Traffic Manager is a DNS-based traffic routing service that distributes client requests across global application endpoints. It acts as a global entry point for your application, resolving DNS queries and directing users to the best available endpoint according to the routing policy and endpoint health. Common scenarios include multi-region deployments, disaster recovery, maintenance windows, hybrid/multi-cloud connectivity, and advanced routing for testing or compliance. Typical scenarios:
  • Multi-region deployments (active-active or active-passive)
  • Disaster recovery and failover
  • Maintenance and staged upgrades with no downtime
  • Hybrid and multi-cloud connectivity (Azure + on-premises or other clouds)
  • Traffic distribution for A/B testing and compliance via geographic routing
Traffic Manager sits above your endpoints (for example, a primary app in East US and a failover app in West Europe) and answers DNS queries to direct users to the appropriate region. Benefits:
  • Increase availability: Automatic failover when health checks detect an unhealthy primary endpoint.
  • Improve performance: Performance routing sends users to the lowest-latency endpoint.
  • Maintenance without downtime: Temporarily disable endpoints for upgrades and Traffic Manager will route traffic away.
  • Hybrid and multi-cloud: Route to Azure, on-premises, or other cloud endpoints (DNS name or IP).
  • Flexible routing strategies: Weighted, priority, performance, geographic, and more. For combined behaviors, use nested Traffic Manager profiles (one profile as an endpoint of another) or multiple profiles.
A diagram titled "Azure Traffic Manager – Use Cases" showing a Traffic Manager profile routing between a primary app service in East US and a failover app service in West Europe. Below are five benefit boxes: increase availability, improve performance, maintenance without downtime, combine hybrid apps, and distribute traffic for complex deployments.
Routing methods overview
Routing methodUse caseExample
PriorityActive-passive failoverPrimary in East US, failover in West Europe
PerformanceRoute users to lowest-latency endpointGlobal app with regional clusters
WeightedA/B testing, gradual rollouts90% production, 10% new version
GeographicData residency, complianceServe EU users from EU endpoints
Multivalue (DNS)Multiple healthy endpoints returnedClient-side load distribution
SubnetRoute specific client subnetsSplit traffic by corporate vs public ISPs
Now let’s see how Traffic Manager works. Traffic Manager is a DNS-based traffic director — it does not sit in the network data path. Instead, it answers DNS queries and returns the best endpoint based on the configured routing method and endpoint health. Typical resolution sequence:
  1. A client (browser) looks up the application domain, for example www.kodekloud.com.
  2. The client’s recursive DNS resolver (ISP DNS, Google DNS, etc.) queries the Traffic Manager DNS name.
  3. Traffic Manager evaluates the configured routing method (performance, weighted, priority, geographic, etc.) and checks endpoint health via health probes.
  4. Traffic Manager returns a CNAME/A record pointing the resolver to the selected endpoint (for example, myapp.eastus.cloudapp.azure.com).
  5. The resolver returns that endpoint to the client (and may cache it according to the DNS TTL).
  6. The client connects directly to the chosen endpoint — application traffic flows between the client and that endpoint (Traffic Manager does not proxy traffic).
Example DNS lookup (local test):
# Query the CNAME for an application that uses Traffic Manager
dig +short www.example.com CNAME

# Example output (placeholder):
# myapp.trafficmanager.net.
Key technical details
  • Health probes: Traffic Manager continuously probes endpoints and excludes unhealthy endpoints from DNS responses based on probe results and status.
  • DNS caching / TTL: Decisions are returned via DNS and are subject to resolver and client caching. Short TTLs let Traffic Manager react faster to topology changes, but increase DNS query volume.
  • No data plane proxy: Traffic Manager only participates in name resolution and therefore does not create a data-plane bandwidth bottleneck.
  • Supported endpoint types: Azure App Service, Virtual Machine, Cloud Service, Public IP, and External endpoints (on-premises or other clouds reachable by DNS name or IP).
A diagram titled "How Traffic Manager Works" showing how a user's browser and recursive DNS interact with Azure Traffic Manager to resolve a CNAME and receive the selected endpoint IP. Traffic Manager performs health checks across endpoints (Web App, Virtual Machine, Cloud Service, External Application) and the client then connects directly to the chosen endpoint.
Traffic Manager changes the DNS response, not the application traffic flow. Plan your TTL and health-probe settings to balance failover responsiveness with DNS query load.
Keep in mind recursive resolver behavior: some public resolvers and clients may ignore very short TTLs or cache negative responses, which can delay failover behavior. Test failover scenarios and tune probe intervals and TTLs accordingly.
Links and references