Traffic Manager vs Application Gateway vs Front Door

If you have spent any time with Azure networking, you have likely seen Traffic Manager, Application Gateway, and Front Door mentioned in the same breath. They all steer traffic in some way, and the marketing materials rarely make it clear which one you actually need.

A previous post covered what Front Door is in detail: its tiers, how it pairs with Application Gateway, and when it earns its cost. This post takes a step back and looks at the three services together, with the goal of making the choice clear rather than repeating what is already written there.

The One Frame That Matters

The clearest way to understand these services is to ask two questions: where does the routing decision happen, and what information does that decision have access to?

Traffic Manager answers at DNS. Application Gateway answers at the HTTP layer inside a region. Front Door answers at the HTTP layer at a global edge point of presence. Each service can only act on what it can see at the layer it operates.

The diagram above shows two common multi-component paths. Traffic Manager influences where the client connects next by returning a different DNS answer. Front Door actually terminates the connection at the edge and then forwards requests onward. Application Gateway sits in the region at the end of either path.

Traffic Manager

Traffic Manager is a DNS-based global traffic router. When a client resolves a hostname that Traffic Manager manages, it returns a different target depending on the routing policy you have configured.

The supported policies cover most common needs. Priority routing sends all traffic to a primary endpoint and fails over to secondary entries if the primary goes unhealthy. Weighted routing distributes traffic across endpoints in proportions you define, which is useful for gradual rollouts or A/B splits. Performance routing sends each client to the endpoint with the lowest measured latency from their location. Geographic routing assigns clients to specific endpoints based on DNS client location.

What Traffic Manager can see: the DNS client IP address (often a resolver, not the end user's IP), the endpoint health check results, and nothing else. It cannot read HTTP headers, inspect paths, or look at TLS handshakes.

Failover and TTL reality: Traffic Manager performs health checks against your endpoints and will stop returning an unhealthy endpoint in DNS answers. But DNS failover is not instant. The TTL on a Traffic Manager record defaults to 60 seconds, and once a client has resolved the address, resolver caches and OS-level caches can hold it longer. In practice, DNS-based failover takes minutes, not seconds. If your SLA requires fast, connection-level failover, DNS is the wrong mechanism.

Where it fits well:

• Multi-region workloads where DNS-level regional steering is sufficient and the workload is not pure HTTPS (for example, non-web endpoints, or scenarios where each region independently handles TLS and routing).
• Simple geographic or priority failover where you accept DNS propagation time as part of your recovery window.

Where it falls short: Any scenario that requires HTTP-aware routing (path rules, host headers, WAF), certificate management at scale, or failover faster than DNS propagation allows. For those, a Layer 7 service is needed.

Application Gateway

Application Gateway is a regional Layer 7 load balancer. It terminates TLS, understands HTTP, and distributes requests across a backend pool according to rules you configure.

The feature set covers the things you would expect from a reverse proxy inside a region: path-based and host-based routing rules, backend health probes, session affinity, custom error pages, and header rewriting. The WAF SKU adds a Web Application Firewall, which applies rule sets for common attack categories (OWASP CRS, bot protection, and Microsoft-managed rules depending on tier).

What Application Gateway can see: the full HTTP request as it arrives after TLS termination. This means host headers, URL paths, query strings, and request bodies if you configure WAF inspection. It can make granular routing and filtering decisions that Traffic Manager cannot.

Where it fits well:

• Single-region public-facing applications where you need path routing, WAF, or TLS termination in a VNet-attached configuration.
• The regional ingress layer in a multi-tier stack where something global (Front Door or Traffic Manager) sits in front and Application Gateway handles the application-layer concerns for backends in a specific region.

Where it falls short:

• Application Gateway is scoped to a single region. It does not distribute traffic across Azure regions on its own. If you need global load balancing or failover across regions, something needs to sit in front of it.
• Certificate management gets operationally heavy as the number of custom hostnames grows. Each custom listener requires a certificate, and renewal management accumulates. This is the argument for Front Door covered in the previous post, so it is not repeated at length here.

Front Door

Front Door is Azure's globally distributed HTTP and HTTPS reverse proxy. Connections terminate at the nearest Microsoft point of presence, and from there Front Door applies routing rules and forwards the request to your origin.

The detailed product breakdown, including tiers, managed certificates, health probes, caching, and the Premium Private Link origin feature, is in the Front Door post. The short summary for comparison purposes: Front Door does what Application Gateway does at Layer 7, but globally and at the edge of Microsoft's network rather than inside a single region.

The key differentiator over Traffic Manager: Traffic Manager instructs the client to connect somewhere. Front Door is where the client connects. Those are meaningfully different. Front Door can inspect and act on each HTTP request in real time, at the edge, before it reaches any of your infrastructure.

The key differentiator over Application Gateway: scope. Application Gateway handles a region. Front Door handles the world. If you have a single region and a modest number of hostnames, Application Gateway can be the entire public ingress story. Once you need global failover, edge caching, or managed certificates at volume, Front Door is the right layer.

A Comparison on Four Axes

Failure behaviour

Front Door performs HTTP health probes against your origins and routes around unhealthy ones in real time. Failover at the connection level is fast, measured in seconds to a minute.

Application Gateway performs health probes against its backend pool members and marks them in or out of rotation. Failover is regional and similarly fast within the pool.

Traffic Manager performs health checks against endpoints and adjusts DNS answers. Failover is bounded by TTL and resolver caching. Clients already connected or holding a cached DNS answer are not automatically redirected.

TLS termination

In a combined Front Door plus Application Gateway stack, TLS terminates at the Front Door edge. The connection between Front Door and Application Gateway can be plain HTTP within a private network, or HTTPS if your security posture requires it end-to-end.

In a Traffic Manager plus Application Gateway stack, TLS terminates at Application Gateway (or at the first Layer 7 entry in each region). Traffic Manager has no involvement in TLS; it only returned the address of that gateway.

Certificate management

Front Door manages certificates for your custom domains automatically. Attach the domain, verify ownership, and Front Door handles provisioning and renewal. At scale, this is a material operational advantage.

Application Gateway requires you to manage certificates on the gateway. Manageable for a small number of hostnames, increasingly error-prone as the count grows.

Traffic Manager does not manage certificates at all. It operates below the TLS layer.

HTTP-aware routing

Front Door and Application Gateway both understand HTTP. Path rules, host header matching, and WAF are available in both. The difference is scope: Front Door applies these globally at the edge, Application Gateway applies them regionally inside a VNet.

Traffic Manager does not have HTTP-aware routing.

Common Stack Patterns

Front Door in front of Application Gateway is the most common production pattern for public HTTPS workloads. Front Door handles the stable public hostname, managed certificates, global health routing, and edge caching. Application Gateway handles regional WAF rules, path routing to backend pools, and VNet-attached ingress. The boundary is clean: everything before the region is Front Door, everything inside the region is Application Gateway.

Traffic Manager in front of regional Application Gateways is a reasonable pattern when you need multi-region DNS-level failover and accept the TTL tradeoff. Each region runs its own Application Gateway for local path routing and WAF. Traffic Manager points at the public address of each regional gateway and fails over at the DNS layer when a region goes unhealthy.

Application Gateway alone is often the right answer for single-region applications with no near-term global requirement. There is no obligation to add a global layer if the workload does not need it. Front Door costs money, and a layer that does nothing for you is not a good trade.

Front Door to backends directly, without Application Gateway, works when the per-region application layer is simple enough that a full regional reverse proxy is unnecessary. The caution here is that your origin servers are then exposed to inbound connections from Front Door service tags, and the per-host routing and WAF capabilities you gave up by removing Application Gateway need to be provided some other way or accepted as a gap.

Traffic Manager pointing at Front Door is rarely useful. You lose the DNS failover edge that Traffic Manager offers (Front Door already handles HTTP-level failover), and you add a DNS hop that adds latency and TTL complexity without a clear benefit. If you encounter a design that stacks these two, ask what problem it is solving that Front Door alone does not.

Which One Do You Need

Start with scope. If you have a single region and no imminent multi-region plans, Application Gateway is usually the right place to begin. Add Front Door when certificate volume or global requirements make a compelling case for it.

If you need multi-region failover or load balancing, the next question is whether HTTP-level or DNS-level failover suits your recovery time requirements. Front Door gives you HTTP-level: fast, connection-aware, and HTTP-smart. Traffic Manager gives you DNS-level: coarser, slower to propagate, but simpler and applicable beyond HTTP.

For most new HTTPS public workloads:

1. Single region, straightforward routing needs: Application Gateway.
2. Multi-region HTTPS with connection-level failover: Front Door, usually with Application Gateway behind it in each region.
3. Multi-region where DNS failover is acceptable, or non-HTTP endpoints need global steering: Traffic Manager, with a regional ingress per region.

The services are not in competition. Traffic Manager does something Application Gateway and Front Door do not: it operates below HTTP entirely. Application Gateway does something Front Door does not: it anchors regional WAF and routing inside a VNet. Front Door does something neither of them does: it is the global HTTP edge, handling connections before they reach any region. The right stack uses each one where it belongs.