Traffic Manager: DNS-Based Routing
Master Azure Traffic Manager's six routing methods, endpoint types, nested profiles, and health monitoring for DNS-based global traffic distribution.
Traffic Manager: DNS-Based Routing
Traffic Manager works at the DNS layer. When a client queries a Traffic Manager FQDN, it returns the IP of the best endpoint based on the routing method. Traffic Manager doesn’t proxy traffic — it redirects at the DNS level.
🎬 Video coming soon
Traffic Manager Routing Methods
Traffic Manager Routing Methods
~12:00Traffic Manager is a smart DNS directory — when a user types your website address, DNS asks Traffic Manager which server to send them to. Traffic Manager answers based on your rules (closest, least busy, specific region). The user connects directly to that server — Traffic Manager doesn’t touch the actual traffic.
The Six Routing Methods
| Method | How It Works | Best For |
|---|---|---|
| Priority | Routes to the highest-priority (lowest number) healthy endpoint. Failover to next if primary is down. | Active-passive DR. Primary in one region, backup in another. |
| Weighted | Distributes traffic based on weights (1-1000). Weight 300 gets 3x more traffic than weight 100. | Gradual migration, canary deployments, capacity-based distribution. |
| Performance | Returns the endpoint with lowest latency from the client’s DNS resolver location. | Multi-region apps where users should reach the closest region. |
| Geographic | Routes based on the geographic origin of the DNS query. Users in a region always go to the assigned endpoint. | Data sovereignty, regional content, compliance requirements. |
| Multivalue | Returns multiple healthy endpoint IPs in a single DNS response. Client chooses. | Simple redundancy — client-side failover. Only works with external endpoints with IPs. |
| Subnet | Maps specific client IP ranges to specific endpoints. | Testing, VIP routing, per-customer endpoints. |
| Method | How It Works | Best For |
|---|---|---|
| Priority | Routes to the highest-priority healthy endpoint; fails over to next | Active-passive disaster recovery |
| Weighted | Distributes by weight (1-1000); weight 300 gets 3x traffic vs weight 100 | Canary deployments, gradual migration |
| Performance | Returns endpoint with lowest latency from client DNS resolver | Multi-region apps needing closest region |
| Geographic | Routes based on geographic origin of the DNS query | Data sovereignty and compliance requirements |
| Multivalue | Returns multiple healthy IPs in one DNS response; client picks | Simple client-side redundancy (external endpoints only) |
| Subnet | Maps specific client IP ranges to specific endpoints | Per-customer routing, VIP access, testing |
Character Scenarios
☁️ Elena — Performance routing: Skyline Logistics’ customer portal is deployed in Australia East and West Europe. Traffic Manager with Performance routing sends Australian customers to the AU East endpoint and European customers to West Europe — lowest latency for each.
🏪 Sam — Priority routing: Harbour Retail has a primary web app in Australia East and a standby in Southeast Asia. Priority routing sends all traffic to AU East (priority 1). If it fails health checks, traffic automatically shifts to Southeast Asia (priority 2).
Endpoint Types
| Endpoint Type | What It Points To | Example |
|---|---|---|
| Azure endpoint | Azure resources (App Service, Public IP, Cloud Service) | Sam’s web app in AU East |
| External endpoint | Non-Azure resources (IP address or FQDN) | Partner’s API at api.partner.com |
| Nested endpoint | Another Traffic Manager profile | Elena’s geographic parent with performance children |
Nested Profiles — Combining Routing Methods
Nested profiles let you combine routing methods. A common pattern:
Parent profile: Geographic routing
- Europe → Child profile (Performance routing between West Europe and North Europe)
- Asia-Pacific → Child profile (Performance routing between AU East and Southeast Asia)
- Americas → Child profile (Performance routing between East US and West US)
This ensures:
- Users are routed to the correct geographic region (compliance/sovereignty)
- Within that region, they reach the lowest-latency endpoint (performance)
Configuration:
- Create child profiles with Performance routing and their regional endpoints
- Create parent profile with Geographic routing
- Add child profiles as “Nested” endpoints in the parent
- Set minimum child endpoints for the nested endpoint to be considered healthy
Health Monitoring
Traffic Manager continuously probes endpoints to determine health:
| Setting | Description | Default |
|---|---|---|
| Protocol | HTTP, HTTPS, or TCP | HTTP |
| Port | Port to probe | 80 |
| Path | URL path for HTTP/HTTPS probes | / |
| Probing interval | How often to check | 30 seconds (10 seconds for fast interval) |
| Tolerated failures | Failures before marking unhealthy | 3 |
| Probe timeout | Time to wait for response | 10 seconds (5 seconds for fast interval) |
Expected probe response: HTTP 200 OK. Any other response (or timeout) counts as a failure.
Fast interval probing: Reduces detection time from ~90 seconds (3 failures at 30s) to ~15 seconds (3 failures at 5s). Costs more but provides faster failover.
Custom health checks: For HTTPS probes, Traffic Manager validates the certificate chain. For HTTP probes, the response body can be checked with an expected status code range.
Key Takeaways
- Traffic Manager is DNS-based — it returns IPs, doesn’t proxy traffic
- Six routing methods cover DR (Priority), migration (Weighted), performance, geo, multivalue, and subnet
- Nested profiles combine routing methods for complex scenarios
- Health monitoring checks every 30 seconds by default; fast interval does 10 seconds
- DNS TTL affects failover time — lower TTL means faster client updates
Test Your Knowledge
Elena needs users in Europe to always reach European endpoints (data sovereignty), but within Europe, traffic should go to the fastest endpoint. Which routing pattern achieves this?
Sam's Traffic Manager health probe checks every 30 seconds with 3 tolerated failures. How long before a failed endpoint is marked unhealthy?
Next up: Application Gateway: Layer 7 — HTTP-aware load balancing with URL routing, TLS termination, and web application features.