This chapter covers Azure Front Door and Azure Traffic Manager, two global load balancing solutions that often appear together on the AZ-305 exam. Understanding their differences is critical because exam questions test your ability to choose the correct service based on requirements like HTTP/HTTPS traffic, SSL offloading, URL-based routing, and global failover. Approximately 10-15% of exam questions touch on global load balancing and traffic routing, making this a high-yield topic. You will learn exactly how each service works internally, their key configuration parameters, and the specific scenarios where one is preferred over the other.
Jump to a section
Imagine a global delivery company that needs to route packages to thousands of regional hubs. Azure Front Door is like a sophisticated air traffic control system at a central airport. It doesn't just forward packages; it inspects each package's contents (HTTP headers, URL paths), decides the best runway (closest healthy backend) based on real-time weather (latency) and runway closures (health probes), and can even split a large shipment across multiple planes (URL path-based routing). It maintains persistent connections with planes (TLS termination) and can redirect packages instantly if a runway closes (failover in seconds). In contrast, Azure Traffic Manager is like the postal service's mail sorting facility. It only looks at the destination zip code (DNS name) and stamps the envelope with the address of the nearest regional hub based on a static rule (e.g., geographic location or performance). It doesn't inspect the contents, doesn't maintain connections, and relies on the postal system's periodic updates (DNS TTL) to change routing. If a hub closes, the mail might be misrouted until the next batch of address stamps is printed (TTL expiry). In short, Front Door operates at Layers 4-7 with real-time intelligence, while Traffic Manager operates only at Layer 3-4 via DNS with delayed updates.
What Azure Front Door Is and Why It Exists
Azure Front Door (AFD) is a global, scalable entry point that uses the Microsoft global edge network to route HTTP/HTTPS traffic to your backend services. It operates at Layer 7 (Application Layer) of the OSI model, meaning it understands HTTP requests, headers, cookies, and URL paths. AFD provides capabilities like SSL termination, URL-based routing, session affinity, and Web Application Firewall (WAF) integration. It is designed for scenarios where you need fine-grained control over traffic routing based on application-level attributes and where low-latency global failover is critical.
What Azure Traffic Manager Is and Why It Exists
Azure Traffic Manager (ATM) is a DNS-based traffic load balancer that distributes traffic across global endpoints. It operates at Layer 3-4 (Network and Transport Layers) because it only uses DNS queries to route clients to the best endpoint based on the routing method (e.g., performance, geographic, priority, weighted). ATM does not inspect HTTP headers or content; it simply returns a DNS response pointing to the IP address of the chosen endpoint. It is suitable for scenarios where you need simple global load balancing for any protocol (HTTP, HTTPS, TCP, UDP) and where DNS-based routing with propagation delays is acceptable.
How Azure Front Door Works Internally
When a client makes an HTTP request to myapp.azurefd.net, AFD receives the request at the nearest edge location (PoP). The edge node checks the health of all configured backends based on health probe settings (default: every 30 seconds, HTTP 200 OK). AFD then applies routing rules:
URL Path-based Routing: AFD can inspect the URL path and forward requests to different backend pools. For example, /api/* goes to an API backend pool, while /images/* goes to a static storage pool.
Session Affinity: Using a cookie (ASXSRF), AFD can direct subsequent requests from the same client to the same backend for stateful applications.
SSL Termination: AFD terminates the TLS connection from the client and optionally re-encrypts to the backend. This offloads CPU-intensive TLS processing from backends.
Caching: AFD can cache static content at the edge to reduce load on backends and improve response times.
WAF: Integrated Web Application Firewall inspects requests for common attacks (SQL injection, XSS) before they reach the backend.
AFD uses a proprietary routing algorithm that considers latency, health, and priority. It can failover within seconds because it maintains persistent TCP connections to backends and continuously monitors health.
How Azure Traffic Manager Works Internally
Traffic Manager uses DNS to direct client traffic. When a client queries the DNS name myapp.trafficmanager.net, the Traffic Manager DNS server responds with the IP address of the best endpoint based on the configured routing method:
Performance: Routes to the endpoint with the lowest network latency from the client's DNS resolver location. Uses a latency map built from periodic probes.
Geographic: Routes based on the geographic region of the client's DNS resolver (not the client itself). Requires you to map regions to endpoints.
Priority: Routes to the primary endpoint unless it is unhealthy, then falls back to secondary, etc.
Weighted: Distributes traffic across endpoints based on assigned weights (0-1000).
Subnet: Routes based on the client's IP subnet (requires custom IP ranges).
ATM does not inspect HTTP traffic. It relies on DNS TTL (default: 300 seconds) to control how long clients cache the DNS response. This means failover can take up to TTL seconds, plus time for health probe detection (default: 10-second interval, 2 failures required).
Key Components, Values, Defaults, and Timers
Azure Front Door:
- Health Probe Interval: 30 seconds (default), can be set to 5, 10, 30, or 60 seconds.
- Health Probe Path: Default is /, but you can specify a custom path.
- Health Probe Protocol: HTTP or HTTPS.
- Latency Sensitivity: Additional latency (in ms) that AFD tolerates before considering an alternate backend.
- Session Affinity: Enabled by default? No, must be enabled per route.
- Caching: Enabled by default? No, must be configured per route.
- WAF Policy: Optional, can be associated at the frontend or route level.
- TLS Termination: Supported with custom certificates or Azure-managed certificates.
Azure Traffic Manager: - DNS TTL: 300 seconds (default), can be set from 0 to 2,147,483,647 seconds. - Health Probe Interval: 10 seconds (default), can be set to 10 or 30 seconds. - Health Probe Timeout: 5 seconds (default). - Number of Failures: 2 (default), number of consecutive failures before marking endpoint as degraded. - Routing Methods: Performance, Geographic, Priority, Weighted, Subnet. - Endpoint Types: Azure endpoints (App Service, Cloud Service, VM), external endpoints (any public IP), nested endpoints (other Traffic Manager profiles).
Configuration and Verification Commands
Azure Front Door (using Azure CLI):
# Create a Front Door profile
az network front-door create --resource-group myRG --name myFrontDoor --backend-address mybackend.azurewebsites.net --frontend-name myFrontend --accepted-protocols Http Https
# Add a custom domain
az network front-door frontend-endpoint create --resource-group myRG --front-door-name myFrontDoor --name myCustomDomain --host-name www.example.com
# Add a routing rule
az network front-door routing-rule create --resource-group myRG --front-door-name myFrontDoor --name myRoute --frontend-endpoints myFrontend --backend-pool myBackendPool --accepted-protocols Https --patterns "/*"
# Check health
az network front-door backend-pool health --resource-group myRG --front-door-name myFrontDoor --name myBackendPoolAzure Traffic Manager:
# Create a Traffic Manager profile
az network traffic-manager profile create --resource-group myRG --name myTM --routing-method Performance --unique-dns-name myapp --monitor-protocol HTTP --monitor-port 80 --monitor-path "/"
# Add an endpoint
az network traffic-manager endpoint create --resource-group myRG --profile-name myTM --name myEndpoint --type azureEndpoints --target-resource-id /subscriptions/.../sites/myAppService
# Check endpoint status
az network traffic-manager endpoint show --resource-group myRG --profile-name myTM --name myEndpoint --query endpointStatusHow They Interact with Related Technologies
Both services can be used together in a nested topology. For example, you might have a Traffic Manager profile that routes between two Front Door instances in different regions for disaster recovery. Front Door can also be placed behind Azure Application Gateway for regional load balancing with WAF at the application level. Traffic Manager often works with Azure DNS to provide custom domain names. Both integrate with Azure Monitor for logging and alerts.
Important Distinctions for the Exam
Protocol Support: AFD only supports HTTP/HTTPS. ATM supports any protocol (HTTP, HTTPS, TCP, UDP) because it only does DNS.
SSL Offloading: AFD can terminate SSL, ATM cannot.
URL-based Routing: AFD supports path-based routing, ATM does not.
Session Affinity: AFD supports cookie-based session affinity, ATM does not (though it can use source IP affinity with the Subnet method).
Failover Speed: AFD can failover in seconds (health probes every 5 seconds), ATM can take up to TTL + probe interval (potentially minutes).
Traffic Inspection: AFD can inspect and modify HTTP headers, ATM cannot.
Caching: AFD can cache content at the edge, ATM cannot.
WAF: AFD integrates with WAF, ATM does not.
Global vs Regional: Both are global services, but AFD uses anycast with Microsoft's edge network, while ATM uses DNS anycast.
Common Misconfiguration Scenarios
Using Traffic Manager for HTTP traffic requiring session persistence: Traffic Manager cannot maintain sessions because DNS responses are cached and the next request may go to a different endpoint. Use Front Door with session affinity instead.
Expecting instant failover with Traffic Manager: DNS TTL and health probe intervals cause delays. For sub-second failover, use Front Door.
Putting Traffic Manager behind a front-end like App Gateway: This works but adds unnecessary latency and complexity. Often, Front Door can replace both.
Exam Tip: The 3-Second Rule for Answering
If the question mentions HTTP/HTTPS traffic, URL path, SSL offloading, WAF, or caching, the answer is likely Front Door. If it mentions any protocol (TCP, UDP), DNS-based routing, simple global failover without application awareness, the answer is Traffic Manager.
Client DNS Resolution
For Azure Traffic Manager, the client performs a DNS lookup for the Traffic Manager domain (e.g., myapp.trafficmanager.net). The DNS query reaches the Traffic Manager DNS server, which determines the best endpoint based on the routing method (e.g., Performance, Geographic). The server returns the IP address of the chosen endpoint (e.g., 13.64.0.1) with a TTL (default 300 seconds). The client caches this IP for the TTL duration. For Azure Front Door, the client resolves the Front Door domain (e.g., myapp.azurefd.net) to the IP of the nearest Anycast edge node. The DNS resolution is handled by Azure DNS and returns an IP that is anycasted globally.
Health Probe Monitoring
Both services continuously monitor backend health. Traffic Manager sends HTTP/HTTPS probes to the endpoint's monitor path (default '/') from its probe agents located globally. It expects a 200 response within 5 seconds (timeout). If 2 consecutive probes fail (default), the endpoint is marked degraded. Traffic Manager uses a 10-second probe interval by default. Front Door sends health probes from each edge node to the backend pool with a configurable interval (default 30 seconds). It also expects a 200 response. If a backend fails, Front Door stops routing traffic to it within seconds. Front Door also monitors latency between edge nodes and backends to optimize routing.
Traffic Routing Decision
For Traffic Manager, the routing decision is made at DNS query time. The DNS server uses the configured routing method to select an endpoint. For Performance routing, it uses a latency map built from periodic probes to determine the closest endpoint to the client's DNS resolver. For Geographic routing, it uses the resolver's IP to determine geographic region and routes accordingly. The decision is static until the next DNS query. For Front Door, the routing decision is made at the edge node for each HTTP request. The edge node considers health, latency, priority, and URL path to forward the request to the optimal backend. This decision is dynamic and can change per request.
Connection Establishment
With Traffic Manager, the client connects directly to the backend IP address returned by DNS. The client establishes a TCP connection (and TLS if HTTPS) directly with the backend. Traffic Manager is not involved in the data path after the DNS response. With Front Door, the client connects to the Front Door edge node (TLS terminated at the edge). Front Door then establishes a separate TCP connection (and optionally TLS) to the backend. This means the backend only sees traffic from Front Door's IP range, not the client's IP. The client's IP is preserved in the X-Forwarded-For header.
Failover Behavior
For Traffic Manager, failover is driven by DNS TTL. When a backend becomes unhealthy, Traffic Manager marks it degraded after 2 failed probes (20 seconds default). However, clients will continue to use the cached IP until the TTL expires (up to 300 seconds). To accelerate failover, you can set a low TTL (e.g., 30 seconds) but this increases DNS query load. For Front Door, failover is near-instantaneous. The edge node detects backend failure via health probes and immediately stops routing requests to that backend. Subsequent requests are routed to healthy backends. The failover happens within seconds, often less than 5 seconds.
Enterprise Scenario 1: Global E-commerce Platform
A large e-commerce company with customers worldwide needs to serve both static content (product images, CSS) and dynamic API traffic. They deploy Azure Front Door as the single entry point. Static content is cached at the edge (TTL: 1 hour) to reduce load on backend origin servers. Dynamic API requests are routed to backend App Services in two regions (West US and West Europe) using URL path-based routing (/api/* to API pool, /static/* to storage pool). Session affinity is enabled for shopping cart persistence. WAF policies block SQL injection attempts. Health probes are set to 5-second intervals for fast failover. In production, Front Door handles 50,000 requests per second with sub-100ms latency. Misconfiguration: Initially, caching was not configured, causing high backend load. After enabling caching with appropriate TTLs, backend CPU dropped by 60%.
Enterprise Scenario 2: Multi-Protocol Global Application
A financial services company runs a trading application that uses both HTTP for web interface and TCP for proprietary data feeds. They need global load balancing but cannot change the application to use HTTP for the data feed. They choose Azure Traffic Manager with Performance routing. Two endpoints are configured: one in East US (App Service for web, VM for data feed) and one in West Europe. The DNS TTL is set to 60 seconds to balance between failover speed and DNS load. Health probes monitor both HTTP port 80 and TCP port 443 (custom health check). In production, Traffic Manager routes traders to the nearest region based on their DNS resolver location. Misconfiguration: Initially, geographic routing was used, but traders traveling between regions experienced poor performance because their DNS resolver remained in the home region. Switching to Performance routing solved this.
Scenario 3: Disaster Recovery with Nested Profiles
A multinational corporation needs a global load balancing solution that can survive a regional Azure outage. They deploy Azure Front Door in two regions (East US and West Europe) with identical configurations. They then create an Azure Traffic Manager profile that uses Priority routing to send traffic to the primary Front Door (East US). If the primary Front Door becomes unhealthy (e.g., Azure region failure), Traffic Manager fails over to the secondary Front Door (West Europe). The DNS TTL is set to 30 seconds. This nested approach combines Front Door's application-layer features with Traffic Manager's simple DNS-based failover. In production, the failover time is approximately 30 seconds (TTL) + 20 seconds (health probe detection) = 50 seconds. They accept this for disaster recovery scenarios.
Exactly What AZ-305 Tests on This Topic
AZ-305 objective 4.2: 'Design a solution for routing traffic.' The exam focuses on selecting the appropriate Azure load balancing service based on requirements. Key decision points tested:
Protocol requirements: HTTP/HTTPS only (Front Door) vs any protocol (Traffic Manager).
SSL/TLS termination: Needed? Use Front Door.
URL path-based routing: Needed? Use Front Door.
Session affinity: Needed? Use Front Door (cookie-based).
Caching: Needed? Use Front Door.
WAF: Needed? Use Front Door.
Failover speed: Sub-second? Front Door. Minutes acceptable? Traffic Manager.
Global vs regional: Both are global, but Front Door uses anycast, Traffic Manager uses DNS.
Common Wrong Answers and Why Candidates Choose Them
Choosing Traffic Manager when HTTP traffic needs session persistence: Candidates think Traffic Manager can do this because it has 'affinity' in the Subnet routing method. However, Subnet routing uses client IP subnet, not session cookies. For true session affinity with stateful applications, Front Door is required.
Choosing Front Door for non-HTTP traffic (e.g., TCP gaming protocol): Candidates see 'global load balancing' and pick Front Door. But Front Door only supports HTTP/HTTPS. For TCP/UDP, Traffic Manager is the only choice.
Thinking Traffic Manager provides instant failover: Candidates assume health probes cause immediate rerouting. They forget DNS caching. The TTL must expire before clients get new IP. The exam often includes a scenario where failover speed is critical (e.g., <10 seconds), and the correct answer is Front Door.
Confusing Azure Application Gateway with Front Door: Application Gateway is regional, not global. The exam sometimes describes a global scenario, and candidates pick Application Gateway because it has WAF. But for global, the choice is Front Door or Traffic Manager.
Specific Numbers and Terms That Appear Verbatim
DNS TTL default: 300 seconds (Traffic Manager).
Health probe interval defaults: Traffic Manager 10 seconds, Front Door 30 seconds.
Number of failures before degraded: 2 (Traffic Manager).
Routing methods: Performance, Geographic, Priority, Weighted, Subnet (Traffic Manager).
Front Door tiers: Standard (CDN, WAF, caching) and Premium (more WAF features, private link).
Anycast: Front Door uses anycast IPs.
Session affinity cookie: ASXSRF (Front Door).
Edge Cases and Exceptions
Traffic Manager can be used for HTTP traffic if session persistence is not required and failover delays are acceptable.
Front Door can be used without WAF or caching for simple global HTTP load balancing.
Nested profiles: Traffic Manager can point to another Traffic Manager or Front Door for complex topologies.
Traffic Manager's Geographic routing uses the client's DNS resolver location, not the client's IP. This can be inaccurate for mobile users.
Front Door's health probes can be configured to use HEAD requests to reduce load.
How to Eliminate Wrong Answers Using the Underlying Mechanism
If the question mentions 'SSL offloading' or 'TLS termination', eliminate Traffic Manager (DNS-level, no TLS visibility).
If the question mentions 'URL path' or 'content-based routing', eliminate Traffic Manager.
If the question mentions 'any protocol' or 'non-HTTP', eliminate Front Door.
If the question requires 'sub-second failover', eliminate Traffic Manager.
If the question requires 'global caching', eliminate Traffic Manager.
If the question requires 'WAF', eliminate Traffic Manager.
Azure Front Door is a Layer 7 global load balancer for HTTP/HTTPS traffic only.
Azure Traffic Manager is a DNS-based global load balancer for any protocol.
Front Door supports SSL termination, URL path routing, session affinity, caching, and WAF.
Traffic Manager supports routing methods: Performance, Geographic, Priority, Weighted, Subnet.
Front Door failover is near-instantaneous (seconds); Traffic Manager failover is delayed by DNS TTL (default 300 seconds).
Front Door health probe interval defaults to 30 seconds; Traffic Manager defaults to 10 seconds.
Traffic Manager cannot inspect or modify HTTP traffic.
Front Door uses anycast IPs; Traffic Manager uses DNS responses.
For global load balancing with application awareness, choose Front Door.
For simple global load balancing of any protocol, choose Traffic Manager.
These come up on the exam all the time. Here's how to tell them apart.
Azure Front Door
Operates at Layer 7 (HTTP/HTTPS).
Supports SSL termination and offloading.
Supports URL path-based routing.
Provides session affinity via cookies.
Failover within seconds due to anycast and persistent connections.
Azure Traffic Manager
Operates at DNS level (Layer 3-4).
Cannot terminate SSL; traffic flows directly to backend.
No URL path awareness; routes based on DNS name only.
No session affinity (except limited Subnet routing).
Failover delayed by DNS TTL (default 300 seconds).
Azure Front Door
Supports caching at edge locations.
Integrates with Web Application Firewall (WAF).
Can inspect and modify HTTP headers.
Uses anycast IP for global presence.
Requires HTTP/HTTPS protocol.
Azure Traffic Manager
No built-in caching.
No WAF integration.
No HTTP header inspection.
Uses DNS anycast (routing based on DNS resolver location).
Supports any protocol (TCP, UDP, HTTP, HTTPS).
Mistake
Traffic Manager can route based on URL path.
Correct
Traffic Manager operates at DNS level (Layer 3-4) and has no visibility into HTTP paths. It only routes based on DNS name. URL path-based routing requires a Layer 7 load balancer like Front Door or Application Gateway.
Mistake
Front Door and Traffic Manager are interchangeable for global load balancing.
Correct
They serve different purposes. Front Door is for HTTP/HTTPS traffic with application-layer features (SSL offloading, path routing, caching, WAF). Traffic Manager is for any protocol and simple DNS-based routing. The choice depends on protocol and feature requirements.
Mistake
Traffic Manager provides instant failover.
Correct
Failover is delayed by DNS TTL (default 300 seconds). Clients cache the IP address until TTL expires. Even with low TTL, health probe detection takes at least 10-20 seconds. Actual failover time is TTL + probe interval + failure threshold.
Mistake
Front Door only works with Azure backends.
Correct
Front Door can route traffic to any publicly accessible HTTP/HTTPS endpoint, including on-premises servers, other clouds, or external services. Backends are defined by IP or FQDN.
Mistake
Traffic Manager can terminate SSL.
Correct
Traffic Manager is DNS-based and does not see the traffic. It cannot terminate SSL. SSL termination requires a proxy like Front Door, Application Gateway, or a reverse proxy.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, Traffic Manager can load balance any protocol because it only uses DNS to direct clients to endpoints. The actual traffic flows directly between client and backend. For example, you can use Traffic Manager to distribute SSH connections (TCP port 22) across multiple VMs globally. However, Traffic Manager does not inspect the traffic, so it cannot perform health checks based on application-level responses for non-HTTP protocols. For TCP health checks, you can configure TCP monitoring (port only).
Both operate at Layer 7, but Front Door is global (anycast) while Application Gateway is regional. Front Door is designed for multi-region load balancing with global failover, caching, and WAF at the edge. Application Gateway is for regional load balancing with features like path-based routing, SSL termination, and WAF within a single region. For global scenarios, use Front Door; for regional scenarios, use Application Gateway. They can be used together (Front Door in front of Application Gateway) for layered protection.
Front Door uses a cookie named 'ASXSRF' to maintain session affinity. When a client makes the first request, Front Door sets this cookie with an encrypted identifier of the backend that handled the request. Subsequent requests from the same client include the cookie, and Front Door routes them to the same backend. This is useful for stateful applications like shopping carts. Session affinity is optional and must be enabled per route. Note that if the backend becomes unhealthy, Front Door will route to another backend (breaking affinity).
Yes, you can nest them. For example, you can create a Traffic Manager profile that points to multiple Front Door instances in different regions. This provides DNS-level failover between Front Door instances. However, this adds complexity and failover delay (due to DNS TTL). A simpler approach is to use Front Door alone with multiple backends in different regions, which provides faster failover. Nested profiles are typically used for disaster recovery across global regions.
The default TTL is 300 seconds (5 minutes). You can configure it from 0 to 2,147,483,647 seconds. A lower TTL (e.g., 30 seconds) allows faster failover but increases DNS query load. A higher TTL reduces DNS traffic but delays failover. The exam often tests that failover time is TTL + health probe detection time.
Yes, Azure Front Door supports WebSocket connections. It can forward WebSocket traffic to backends. However, session affinity is not supported for WebSocket connections because the initial handshake is HTTP but subsequent frames are not. For WebSocket, ensure your backends are stateless or use a different persistence mechanism.
Front Door will return a 503 Service Unavailable error to the client. It does not have a 'last resort' backend like Traffic Manager's 'All' endpoint behavior. To avoid this, ensure you have at least one healthy backend or configure a fallback backend pool with a low priority.
You've just covered Azure Front Door vs Traffic Manager — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?