Choosing Between Traffic Manager and Azure Front Door

Overview and What You Will Learn

In this lab, you will create a Traffic Manager profile routing between two regional endpoints, then compare it against Azure Front Door's application-layer capabilities, understanding exactly why one operates purely at the DNS level while the other can inspect and cache actual HTTP traffic.

Why This Matters in Production

A team running an application across two Azure regions for resilience configures Traffic Manager expecting it to also cache their static content and provide Web Application Firewall protection - capabilities it simply does not have, since it operates purely at the DNS level and never touches the actual HTTP traffic. Azure Front Door was the correct tool for that specific requirement.

Core Principles

Both services route users to the best-performing or nearest healthy region, but they solve it at genuinely different layers.

Traffic Manager only ever answers a DNS query - it tells a client which IP address to connect to, then steps out of the picture entirely. Front Door actually sits in the path of every request, giving it capabilities Traffic Manager structurally cannot have.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group:

2. Create a Traffic Manager profile using performance-based routing:

3. Add two endpoints representing two different regional deployments:

4. Confirm both endpoints are registered and check which one a DNS query currently resolves to:

Note

This dig query only ever returns an IP address - it never shows any HTTP content, headers, or caching behavior, because Traffic Manager has genuinely never touched any HTTP traffic at all. It answered a DNS question and stepped out.

5. Azure Front Door is created through a different workflow, defining an actual routing rule with a frontend, a backend pool, and optionally a caching and WAF configuration - conceptually this looks like:

6. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Expecting Traffic Manager to provide content caching or WAF protection, when it structurally cannot - it only ever answers a DNS lookup and has no visibility into or control over the actual HTTP request and response traffic that follows.

Tip

If the requirement is purely "route users to the best-performing or healthiest region" with no need for caching or WAF, Traffic Manager is the simpler, lower-cost choice. The moment caching or a global WAF becomes a genuine requirement, that points directly to Front Door instead.

• Traffic Manager's DNS-level routing means a client's own DNS cache can delay failover. Even after Traffic Manager detects an endpoint is unhealthy and stops returning its IP, a client that already cached the old answer may keep using it until that cache expires, based on the configured TTL.
• Front Door's application-layer position lets it retry a failed request against a different backend transparently, something DNS-level routing like Traffic Manager cannot do, since it never sees individual requests at all.

Quick Reference & Troubleshooting Commands