# Azure Front Door vs Application Gateway vs Traffic Manager

> Compare Azure Front Door, Application Gateway, Traffic Manager and Load Balancer by layer, scope and features, with a decision guide and combinations.

Source: https://www.epifive.com/blog/azure-front-door-vs-application-gateway-vs-traffic-manager · Published 2026-10-26 · EpiFive

## Key takeaways

- Azure Front Door is global Layer 7 with caching, SSL offload and fast failover, while Application Gateway is regional Layer 7 inside your virtual network.
- Traffic Manager is DNS-based and global; it does not handle the traffic itself, so it fails over more slowly than Front Door because of DNS caching.
- Azure Load Balancer is Layer 4 for TCP and UDP, regional or cross-region, and is the choice for non-HTTP traffic and VMs inside a network.
- For an internet-facing web app deployed in multiple regions that needs acceleration, Microsoft's decision tree points to Azure Front Door.
- Combine services when needed, for example Front Door in front of Application Gateway, rather than forcing one service to do everything.

Use Azure Front Door for internet-facing web applications deployed in more than one region that need global routing, caching and fast failover. Use Application Gateway for Layer 7 routing and a web application firewall inside one region. Use Traffic Manager when you only need DNS-based routing and failover for any kind of endpoint, and Azure Load Balancer for Layer 4 TCP and UDP traffic. Real designs often combine two of them.

## Who this is for and what you will have

This guide is for architects, developers and administrators choosing how to route and balance traffic to an application in Azure. By the end you will understand the two dimensions Microsoft uses to categorize these services, what each one does and does not do, how to use the decision tree, and which combinations are common. It does not quote prices; each service has its own pricing page.

## The two dimensions: global vs regional and HTTP(S) vs non-HTTP(S)

Microsoft's load balancing guidance sorts the services along two axes.

**Global or regional.** Global services distribute traffic across regional back ends, clouds or hybrid on-premises services with a single control plane. Regional services distribute traffic within a virtual network across VMs, containers or clusters in one region.

**HTTP(S) or non-HTTP(S).** HTTP(S) services are Layer 7 load balancers for web applications, with features such as SSL offload, WAF, path-based routing and session affinity. Non-HTTP(S) services are Layer 4 TCP and UDP services, or DNS-based services.

| Service | Global or regional | Recommended traffic |
|---|---|---|
| Azure Front Door | Global | HTTP(S) |
| Application Gateway | Regional | HTTP(S), TCP and TLS |
| Traffic Manager | Global | Non-HTTP(S) |
| Load Balancer | Regional or global (cross-region) | Non-HTTP(S) |
| API Management | Regional or global | HTTP(S) APIs only |

Microsoft adds a note: Traffic Manager and Load Balancer can distribute any traffic type, including HTTP(S), but they do not provide Layer 7 capabilities. Unlike Load Balancer, Traffic Manager does not handle the traffic directly; it uses DNS to direct clients to endpoints.

## Azure Front Door

Front Door is described as an application delivery network and an advanced content delivery network (CDN) for the cloud. It delivers static and dynamic content through Microsoft's global edge network, with points of presence close to users.

Capabilities listed in the overview:

- Global load balancing and routing across origins, with health probes for apps hosted in Azure or elsewhere.
- SSL offload at the edge with integrated certificate management and free, auto-rotated managed certificates.
- Caching and traffic acceleration, including split TCP connections.
- Layer 3-4 DDoS protection, a seamlessly attached web application firewall (WAF) and bot manager rules.
- A rules engine, custom domains, HTTP/2 and end-to-end IPv6.
- Private connectivity to origins with Azure Private Link, for a Zero Trust model.
- Logging of every request and failed health probes, and integration with Azure Monitor.

Front Door is offered in Standard, Premium and Classic tiers in Microsoft Azure commercial and Azure Government (US). The tier comparison page lists which features each tier supports, so check it before choosing, particularly for Private Link to origins and the managed WAF rule sets.

Choose Front Door when you want one global entry point for HTTP(S) traffic, performance acceleration, edge caching, and quick failover between regions. It only handles HTTP(S).

## Application Gateway

Application Gateway is a web traffic load balancer that routes on HTTP request attributes such as URL path and host header, not just IP and port. It works at OSI Layer 7 and is a dedicated deployment in your virtual network that requires its own subnet, which cannot contain other resource types.

Features by category from the documentation:

- **Traffic routing:** URL path-based routing, multiple-site hosting, redirection, rewriting HTTP headers and URLs, cookie-based session affinity.
- **Security:** SSL/TLS termination, end-to-end TLS to the back end, and a WAF with bot manager rules; Private Link to back ends and a private-only deployment are options.
- **Scale and resiliency:** autoscaling, zone redundancy, a static VIP and connection draining.
- **Protocol and platform:** WebSocket and HTTP/2 support, custom error pages, and the Application Gateway Ingress Controller for AKS.

Microsoft's architecture guidance also notes that, as a terminating load balancer, it offers Layer 4 load balancing for TCP and TLS protocols.

The documentation covers the v2 SKU family, Standard_v2 and WAF_v2. The v1 SKUs retired on April 28, 2026, so any remaining v1 gateways should be migrated using the v1 to v2 migration guide.

Choose Application Gateway when the back ends are in one region inside a virtual network, you need path-based routing, TLS termination or a WAF there, and you want to move traffic from public network space to web servers in private space.

## Traffic Manager

Traffic Manager is a DNS-based traffic load balancer. Based on a routing method, it answers DNS queries with the address of an appropriate endpoint, and it monitors every endpoint's health. Endpoints can be any internet-facing service inside or outside Azure, which makes it useful for hybrid and migration scenarios.

The six routing methods:

| Method | What it does |
|---|---|
| Priority | Sends all traffic to the primary endpoint and fails over to backups in order |
| Weighted | Distributes traffic by weight; useful for gradual upgrades, migrations and cloud bursting |
| Performance | Sends users to the endpoint with the lowest network latency |
| Geographic | Routes by the geographic location of the DNS query, for data sovereignty and localization |
| MultiValue | Returns all healthy endpoints; works only when all endpoints are IPv4 or IPv6 addresses |
| Subnet | Maps source IP ranges to specific endpoints |

Each profile uses one routing method at a time, and you can combine methods with nested profiles. A routing method change applies within one minute without downtime.

The key limitation: it load balances only at the domain level. Because DNS responses are cached, and some systems ignore DNS time-to-live (TTL) values, Traffic Manager cannot fail over as quickly as Azure Front Door. Weighted distribution can also be skewed when only a few clients or recursive DNS servers are involved. Traffic Manager also does not see or inspect HTTP traffic, so there is no WAF, caching or TLS offload.

Choose Traffic Manager when you need simple DNS-based routing or failover, for any protocol, including non-HTTP workloads or endpoints outside Azure.

## Azure Load Balancer

Load Balancer is a Layer 4 service for all TCP and UDP traffic, designed for high performance and ultra-low latency. It is a passthrough load balancer: the client's connection goes directly to the backend server chosen by the distribution algorithm. It is zone redundant and supports a regional topology and a cross-region topology.

It is the typical choice for load balancing VMs within a virtual network, internal load balancing for IaaS tiers and non-HTTP protocols. It has no Layer 7 features.

## Side-by-side comparison

| Question | Front Door | Application Gateway | Traffic Manager | Load Balancer |
|---|---|---|---|---|
| Layer | 7 | 7 (plus TCP/TLS proxy) | DNS | 4 |
| Scope | Global | Regional | Global | Regional or cross-region |
| Handles traffic itself | Yes, proxy at the edge | Yes, proxy in your VNet | No, answers DNS only | Yes, passthrough |
| WAF | Yes | Yes (WAF_v2) | No | No |
| TLS termination | Yes, at the edge | Yes | No | No |
| Caching | Yes | No | No | No |
| URL path routing | Yes | Yes | No | No |
| Failover speed | Quick, global | Within the region | Slower due to DNS caching | Within the region |
| Non-HTTP protocols | No | TCP and TLS | Yes (DNS based) | Yes, TCP and UDP |
| Endpoints outside Azure | Yes, origins can be anywhere | Back ends in or reachable from the VNet | Yes | Azure resources in its scope |

## Decision guide

Microsoft's decision tree starts with whether the application is a web app (HTTP/HTTPS) and works down:

1. **Not a web application:** Microsoft defines a web application as one that needs Layer 7 routing, payload inspection or TLS handling. For Layer 4 TCP, UDP or TLS traffic, both Load Balancer and Application Gateway can handle it, with different features and behaviors. Traffic Manager is the DNS-level option for non-HTTP endpoints. The flow chart itself does not include Traffic Manager.
2. **Web app, not internet-facing:** the tree points to Load Balancer.
3. **Internet-facing, single region:** Application Gateway.
4. **Internet-facing, global or multi-region, needs performance acceleration:** Azure Front Door.
5. **Global, no acceleration needed, needs SSL offload or application-layer processing per request:** Azure Front Door together with Application Gateway (or Front Door with API Management for API-only hosting).
6. **Global, no acceleration, no per-request processing:** Front Door for PaaS back ends; Front Door plus Load Balancer for IaaS VMs; Front Door plus Application Gateway ingress controller for AKS.

Microsoft cautions that every application has requirements a simple tree does not capture, so treat the result as a starting point. A related caution: using a regional service as the router for globally distributed back ends makes that region a single point of failure and adds latency, because traffic is forced through one region before reaching another.

## Common combinations

| Combination | Why |
|---|---|
| Front Door in front of Application Gateway | Global entry and caching at the edge, with regional Layer 7 routing and WAF in each region |
| Front Door in front of Load Balancer | Global entry for IaaS web VMs that sit behind an internal or public Layer 4 balancer |
| Traffic Manager in front of Application Gateway | DNS-based multiregion failover with a regional WAF in each region; Microsoft documents this for HTTP(S) and non-HTTP(S) protocols |
| Application Gateway in front of API Management | WAF and TLS offload at the gateway, with API Management load balancing across API back ends |

Avoid stacking services that do the same job. For example, you do not usually need both Traffic Manager and Front Door for the same global HTTP(S) entry point.

## Questions to answer before choosing

- Is the traffic HTTP(S) or something else such as SQL, SMTP or a custom TCP protocol?
- Is the app public or private only?
- Does it run in one region or several, and do you need active-active or active-passive?
- Do you need a WAF, TLS termination or path-based routing?
- How fast must failover be, and can you accept DNS cache delays?
- Do you need caching or acceleration for global users?
- Are some back ends outside Azure?

Microsoft also lists other considerations to compare per service: WebSockets, server-sent events, HTTP/2, sticky sessions, health monitoring and the delay between detecting an unhealthy node and removing it from routing. Check the feature and limits pages for each service against your list.

## Basic setup path

Every service needs its own configuration, but the order of work is similar:

1. Deploy the back ends and verify they respond directly.
2. Create the routing service in front of them with a health probe that checks a lightweight, reliable endpoint.
3. Add TLS certificates and custom domains if the service terminates TLS.
4. Turn on the WAF in detection mode first, review the logs for false positives, then switch to prevention.
5. Lock down the back ends so they only accept traffic from the routing layer, using Private Link, NSG rules or origin access restrictions where supported.
6. Point DNS to the new entry point with a low TTL during cutover.
7. Test failover by disabling or blocking a back end and measuring how long traffic takes to move.

For network design around these services, see [Azure hub and spoke network with a firewall](https://www.epifive.com/blog/azure-hub-spoke-network-firewall) and [Azure landing zone for a small business](https://www.epifive.com/blog/azure-landing-zone-small-business).

## Troubleshooting

### Users still hit the failed region after failover with Traffic Manager

DNS caching. Resolvers and clients hold the old answer until the TTL expires, and some ignore TTL. Lower the profile TTL ahead of planned changes, and consider Front Door if you need faster failover for HTTP(S).

### Weighted routing distribution looks uneven

With a small number of clients or recursive DNS servers, caching can skew the split significantly, and the documentation says clearing the DNS cache can help. For a narrow user base behind one resolver, choose another method or a different service.

### Geographic routing returns no answer

If a query comes from a region with no mapping, or the matched endpoint is Stopped, Traffic Manager returns a NODATA response. Microsoft recommends using nested endpoints with at least two endpoints in each child profile and assigning the World region to a fallback.

### Application Gateway deployment fails with subnet errors

An application gateway needs a dedicated subnet that cannot contain other resource types. Create a separate subnet for it.

### A v1 Application Gateway is having problems

v1 retired on April 28, 2026 and unmigrated v1 deployments may see traffic disruption as hardware is decommissioned. Migrate to v2.

### The app works through Front Door but not directly, or the reverse

Check that the origin allows traffic from the routing layer, that the host header the service forwards matches what the back end expects, and that health probes pass. Open the diagnostic logs of the routing service to see probe failures; Front Door logs failed health probes.

## Checklist

- Classify the workload: HTTP(S) or not, public or private, one region or many.
- Pick the main entry service using the decision tree: Front Door for global web, Application Gateway for regional web, Traffic Manager for DNS routing, Load Balancer for Layer 4.
- Add a second service only for a clear reason, such as a regional WAF behind Front Door.
- Put a WAF in front of public web apps and start in detection mode.
- Check each service's pricing page and SLA for your design.
- Test failover and measure the real time to recover.
- Restrict back ends to accept traffic only from the routing layer.

## References

- Load balancing options (Azure Architecture Center): https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview
- Azure Front Door overview: https://learn.microsoft.com/en-us/azure/frontdoor/front-door-overview
- What is Azure Application Gateway: https://learn.microsoft.com/en-us/azure/application-gateway/overview
- Azure Traffic Manager overview: https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-overview
- Traffic Manager routing methods: https://learn.microsoft.com/en-us/azure/traffic-manager/traffic-manager-routing-methods
- Azure Load Balancer overview: https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-overview

## Frequently asked questions

### What is the main difference between Azure Front Door and Application Gateway?

Azure Front Door is a global Layer 7 service that provides load balancing, caching and site acceleration across regions from Microsoft's edge network. Application Gateway is a regional Layer 7 load balancer deployed in your virtual network that routes web traffic to back ends in that region. Many designs use Front Door in front and Application Gateway behind it.

### Is Azure Traffic Manager a load balancer or a DNS service?

It is a DNS-based traffic load balancer. It answers DNS queries with the address of a healthy endpoint chosen by a routing method, and it does not proxy the traffic itself. Because clients cache DNS answers, failover is not as quick as with Azure Front Door.

### Which Azure service should I use for a single-region web app with a WAF?

Application Gateway with the WAF_v2 SKU is the regional choice. It provides Layer 7 routing, TLS termination and a web application firewall for back ends in a virtual network. If the app is global or you want caching and edge acceleration, evaluate Azure Front Door instead or in front of it.

### Can I use Front Door and Traffic Manager or Application Gateway together?

Yes. Microsoft states that an effective setup often uses more than one load balancing solution at different places in the architecture, and its decision guide lists Front Door with Application Gateway as a combination. Traffic Manager with Application Gateway is also a documented pattern for multiregion deployments.