Last updated: May 2026
Azure Networking Intermediate AZ-104 ⏱ 11 min read

Azure Traffic Manager

Azure Traffic Manager is a DNS-based global traffic routing service that distributes traffic across Azure regions and endpoints worldwide. Unlike Front Door or Load Balancer, Traffic Manager doesn't sit in the data path — it only responds to DNS queries, directing users to the best endpoint based on routing rules. This makes it protocol-agnostic — it works with any internet-accessible endpoint, not just HTTP.

What you'll learn How Traffic Manager works (DNS-based routing) · Traffic Manager profiles and endpoints · All six routing methods explained · Health monitoring · Nested profiles · Limitations of DNS-based routing · Traffic Manager vs Front Door · Real-world use cases

How Traffic Manager Works

Traffic Manager is pure DNS routing — it never sees your actual traffic. Here's what happens:

  1. User types app.contoso.com in their browser
  2. DNS resolves app.contoso.com to Traffic Manager's DNS name
  3. Traffic Manager evaluates its routing policy and health of endpoints
  4. Traffic Manager returns the DNS name of the best endpoint (e.g., contoso-eastus.azurewebsites.net)
  5. User's browser connects directly to that endpoint
  6. Traffic Manager is no longer involved — all traffic goes directly to the endpoint
ℹ️
Traffic Manager is NOT in the Data Path Traffic Manager only handles DNS — it never touches your actual traffic. All HTTP/HTTPS traffic flows directly between the user and the endpoint. This is the fundamental difference from Front Door, which acts as a proxy and is in the data path.

Profiles and Endpoints

A Traffic Manager profile defines the routing method and contains endpoints. Endpoints are the destinations traffic is routed to. Three endpoint types:

Endpoint TypeWhat It Points To
Azure endpointsAzure resources — VMs, App Services, Load Balancers, Cloud Services
External endpointsAny internet endpoint — on-premises or other clouds
Nested endpointsAnother Traffic Manager profile (for complex multi-tier routing)

Six Routing Methods

1. Priority

All traffic goes to the primary endpoint. If it fails health checks, traffic fails over to the secondary. Best for active-passive disaster recovery.

Example Priority routing
Priority 1: East US (primary — all normal traffic)
Priority 2: West Europe (secondary — only if East US fails)

2. Weighted

Traffic is distributed across endpoints based on assigned weights. Used for gradual rollouts, A/B testing, or distributing load proportionally.

Example Weighted routing
East US — Weight 90 (90% of traffic)
West US — Weight 10 (10% of traffic — canary)

3. Performance

Routes users to the endpoint with the lowest network latency — typically the closest geographic region. Best for globally distributed applications where performance matters most.

4. Geographic

Routes users based on their geographic location. Users in India → India endpoints, users in Europe → European endpoints. Used for data sovereignty, content localisation, and compliance requirements.

5. Multivalue

Returns multiple healthy endpoint IPs in a single DNS response. The client picks one. Only works with IPv4/IPv6 endpoints (not nested profiles). Increases availability — even if one endpoint fails, the client has alternatives.

6. Subnet

Maps specific source IP address ranges to specific endpoints. Useful for directing traffic from your corporate network to a specific backend, or A/B testing by IP range.

Routing MethodBest For
PriorityActive-passive failover between regions
WeightedGradual rollout, A/B testing, load distribution
PerformanceGlobal apps — route to lowest latency region
GeographicData sovereignty, content localisation
MultivalueHigher availability — multiple IPs in DNS response
SubnetRoute specific IP ranges to specific endpoints

Health Monitoring

Traffic Manager monitors endpoint health by sending periodic HTTP/HTTPS/TCP probes to a configured path. If an endpoint fails health checks, Traffic Manager stops returning it in DNS responses until it recovers.

⚠️
DNS TTL and Failover Speed Traffic Manager's failover speed is limited by DNS TTL (Time to Live). Even after an endpoint is marked unhealthy, clients with the old DNS response cached continue connecting to the failed endpoint until the TTL expires. The default TTL is 60 seconds. For faster failover, lower the TTL — but this increases DNS query volume and cost.

Nested Profiles

Nested profiles allow complex routing scenarios — a parent profile routes between regions, and child profiles handle routing within each region:

Example Nested profile — geographic + performance
Parent profile (Geographic routing):
  Asia users → Asia child profile (Performance routing between India/Singapore)
  Europe users → Europe child profile (Performance routing between UK/Germany)

Limitations of DNS Routing

  • No SSL termination — Traffic Manager doesn't touch HTTP/HTTPS
  • No WAF — No web application firewall capability
  • No CDN caching — Only DNS routing, no content delivery
  • Failover limited by DNS TTL — Not instant failover like Front Door
  • No URL path routing — Routes at the domain level, not URL path level
  • Client DNS caching — Clients may cache DNS responses beyond TTL

Traffic Manager vs Front Door

FeatureTraffic ManagerFront Door
MechanismDNS onlyLayer 7 HTTP proxy
ProtocolsAny (DNS-based)HTTP/HTTPS only
Failover speedDNS TTL dependentSeconds (proxy-based)
CDN❌ No✅ Yes
SSL termination❌ No✅ Yes
WAF❌ No✅ Yes (Premium)
URL routing❌ No✅ Yes
Non-HTTP protocols✅ Yes (DNS only)❌ No
CostLowerHigher

Real-World Use Cases

ScenarioRouting Method
DR failover between East US (primary) and West Europe (secondary)Priority
Global web app — route to nearest region for low latencyPerformance
GDPR compliance — European users must stay in EuropeGeographic
Gradually roll out v2 to 10% of trafficWeighted
Route corporate VPN users to internal endpointSubnet
💡
AZ-104 Exam Tip Know all six routing methods and their use cases. Know that Traffic Manager is DNS-based and NOT in the data path. Know that failover speed depends on DNS TTL. Know when to use Traffic Manager vs Front Door — Traffic Manager for non-HTTP protocols and simple DNS routing; Front Door for HTTP/HTTPS with CDN, WAF, and SSL.
📝 Practice Questions
Click an option to check your answer. AZ-104 style questions.
Q1. Azure Traffic Manager is a DNS-based service. What does this mean for actual user traffic?
A All user traffic passes through Traffic Manager's infrastructure
B Traffic Manager only resolves DNS — actual traffic flows directly between user and endpoint
C Traffic Manager encrypts all traffic between users and endpoints
D Traffic Manager caches responses for faster delivery
Q2. A company needs European users to be served exclusively from European data centres for GDPR compliance. Which Traffic Manager routing method should they use?
A Performance routing
B Priority routing
C Geographic routing
D Weighted routing
Q3. Why is Traffic Manager failover not instantaneous like Azure Front Door?
A Traffic Manager health probes run less frequently than Front Door probes
B DNS TTL caching — clients continue using cached DNS responses until TTL expires
C Traffic Manager uses slower routing algorithms than Front Door
D Traffic Manager requires Azure support to approve failover decisions
Q4. Which Traffic Manager routing method routes all traffic to the primary endpoint and only switches to secondary when the primary fails?
A Priority routing
B Performance routing
C Weighted routing
D Geographic routing
Q5. Can Azure Traffic Manager route non-HTTP protocols (like custom TCP applications)?
A Yes — Traffic Manager is DNS-based so it works with any protocol
B No — Traffic Manager only supports HTTP and HTTPS
C Only TCP protocols — not UDP
D Only with a special non-HTTP routing configuration
Comments
Disclaimer: RedKite Cloud is an independent educational resource and is not affiliated with Microsoft Corporation.