- 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
- 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.

| Routing method | Use case | Example |
|---|---|---|
| Priority | Active-passive failover | Primary in East US, failover in West Europe |
| Performance | Route users to lowest-latency endpoint | Global app with regional clusters |
| Weighted | A/B testing, gradual rollouts | 90% production, 10% new version |
| Geographic | Data residency, compliance | Serve EU users from EU endpoints |
| Multivalue (DNS) | Multiple healthy endpoints returned | Client-side load distribution |
| Subnet | Route specific client subnets | Split traffic by corporate vs public ISPs |
- A client (browser) looks up the application domain, for example www.kodekloud.com.
- The client’s recursive DNS resolver (ISP DNS, Google DNS, etc.) queries the Traffic Manager DNS name.
- Traffic Manager evaluates the configured routing method (performance, weighted, priority, geographic, etc.) and checks endpoint health via health probes.
- Traffic Manager returns a CNAME/A record pointing the resolver to the selected endpoint (for example, myapp.eastus.cloudapp.azure.com).
- The resolver returns that endpoint to the client (and may cache it according to the DNS TTL).
- The client connects directly to the chosen endpoint — application traffic flows between the client and that endpoint (Traffic Manager does not proxy traffic).
- 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).

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.