Azure Load Balancing Options Explained: Load Balancer vs Application Gateway vs Front Door vs Traffic Manager

Two questions decide most of it. Is the traffic HTTP(S) or not, and does it cross regions or stay inside one? Regional plus HTTP(S) points at Application Gateway; global plus HTTP(S) at Azure Front Door; regional non-HTTP(S) at Azure Load Balancer; global non-HTTP(S) at Traffic Manager. Real designs often use two.

Four services, one question, and almost every article about it prints the same table. The table is real and it comes from Microsoft. What the table leaves out is that two of its four cells have moved, and that a good number of production designs answer the question with two services rather than one.

The two questions Microsoft actually asks

Microsoft sorts its load balancing services along two axes, and the wording is worth being precise about (load balancing options).

Global or regional is about what the service balances between. A global service picks between whole deployments — stamps, scale units, endpoints — that may sit in different regions, different clouds, or on-premises. A regional service picks between the machines, containers or endpoints inside one region's virtual network.

HTTP(S) or non-HTTP(S) is about how deep the service reads. The HTTP(S) group are layer 7 proxies. Because they parse the request, they can offer things that only make sense once you have parsed it: TLS offload, a web application firewall, routing on the URL path, session affinity. The other group covers layer 4 TCP and UDP, plus DNS-based routing.

Notice what the second axis really measures. It is not "does my app speak HTTP". Almost every app does. It is "do I need something in the path to act on HTTP". If nothing in your design depends on reading a request, the answer sits in the non-HTTP(S) column no matter what protocol runs over the wire.

The four-quadrant map

Cross the two axes and you get the map that most of the internet reproduces.

	Non-HTTP(S)	HTTP(S)
Regional	Azure Load Balancer	Azure Application Gateway
Global	Azure Traffic Manager	Azure Front Door

What each of the four actually is, sourced:

• Azure Load Balancer works at layer 4 and is a pass-through device. The client's connection terminates on the backend machine, not on the load balancer, which is where its very low latency comes from (overview, pass-through vs terminating).
• Azure Application Gateway is a terminating proxy at layer 7. Your client connects to the gateway; the gateway opens its own connection to a backend. It picks that backend from HTTP attributes it has read, such as the path or the host header (overview).
• Azure Front Door sits at Microsoft's edge and is described by Microsoft as an advanced content delivery network as well as a global layer 7 balancer. Caching, TLS termination at the edge, a WAF and fast failover all come from that position (overview).
• Azure Traffic Manager answers DNS queries and nothing else. It picks an endpoint by a routing method, returns it, and then takes no further part. Clients connect to that endpoint on their own, so Traffic Manager is neither a proxy nor a gateway, and it never sees your traffic (how it works).

That last one is the single most useful fact in this article, and it explains nearly everything else about Traffic Manager. A service that never touches the request cannot cache it, cannot inspect it, and cannot pull it back once a client has been told where to go.

Two cells the map has already outgrown

Here is the part the generic comparisons miss. Microsoft's current table does not have four rows; it has six, and two of the rows disagree with the tidy quadrant above.

The regional HTTP(S) cell is no longer HTTP-only. Application Gateway's row in Microsoft's table reads "HTTP(S), TCP, & TLS". A dedicated page covers the capability. Alongside its layer 7 features, the gateway now proxies plain TCP and TLS. One frontend IP can therefore serve web and non-web backends from the same resource (TCP/TLS proxy). In that mode it is still a terminating proxy, which remains the real difference from Azure Load Balancer. Microsoft also warns that a WAF v2 gateway does not inspect traffic on TLS or TCP listeners.

The regional non-HTTP(S) cell is no longer regional-only. Standard Load Balancer has a global tier whose backend pool holds regional load balancers rather than machines. It advertises one static anycast IP, routes on geographic proximity, and checks the health of each regional load balancer every five seconds (global load balancer). Microsoft's table therefore lists Load Balancer as "Regional or global", not regional.

The other two rows in that table are Application Gateway for Containers, for Kubernetes workloads, and API Management, which can spread calls across API backends. Microsoft is blunt that API Management is not a general-purpose load balancer and warns against adopting it purely for that.

Our reading, and we own it as ours: the quadrant is still the right first move, because it gets you to the correct neighbourhood in one step. Treat it as a shortlist, then check the two moved cells before you commit.

Application Gateway or Front Door, when you only have one region

The quadrant says regional, so Application Gateway. Yet plenty of single-region teams still put Front Door in front, and they are not wrong. The quadrant answers "what balances my backends", not "what should terminate the internet".

Microsoft's own comparison is a statement about scope. Front Door is global, so it spreads requests over regions. Application Gateway is regional, so it spreads them within one. Put another way, Front Door balances between scale units and stamps; Application Gateway balances between the resources sitting inside a single stamp (Front Door FAQ).

Two things settle it more often than the scope argument does.

Reachability. Front Door needs an origin it can reach over the internet — a public VIP or a publicly resolvable name. If your origin must stay private, the documented route is Private Link with Front Door Premium, including to an internal load balancer (Front Door FAQ). Application Gateway has no such constraint: it lives in your virtual network, and Microsoft documents a private-only deployment for estates that cannot expose anything (Application Gateway overview). For a lot of regulated networks this one fact decides the whole design.

Distance to the user. Front Door's value is largely positional. Microsoft counts more than 118 edge locations, sitting in 100 metro areas and joined to Azure over a private WAN. TLS terminates there, and static and dynamic content alike can be cached there (Front Door overview). None of that changes when you have one region — a single-region app with users on three continents still gets a shorter first hop. Application Gateway cannot offer it, because it is where your servers are.

Traffic Manager or Front Door, when the question is failover speed

This pairing has one honest answer, and Microsoft states it rather than leaving you to infer it. Traffic Manager balances at the level of a domain name, so:

"For that reason, it can't fail over as quickly as Azure Front Door." — Microsoft, load balancing options

The mechanism is worth understanding, because it tells you what you can and cannot tune. A DNS answer carries a time-to-live, and both the recursive resolver and the client's own resolver keep the answer for that long. Until it expires, nothing you change in Traffic Manager reaches those clients. Microsoft puts the tuning range at zero seconds up to 2,147,483,647 seconds, and names the trade plainly. Short values expire sooner, at the price of more lookups. Long values leave traffic arriving at a dead endpoint for longer (how it works). The Architecture Center then adds the part no setting reaches: resolvers that ignore TTL altogether.

Front Door is faster because the decision is not cached anywhere. Requests already pass through the edge, so a failover is a routing change inside the path rather than an announcement waiting to propagate. Microsoft describes the result as near real-time failover (Front Door FAQ).

So why would anyone still pick Traffic Manager? Because stepping out of the path is sometimes the point:

• Any protocol, any endpoint. Traffic Manager routes to any internet-facing service, in Azure or outside it, which makes it the straightforward answer for hybrid, burst-to-cloud and migrate-to-cloud shapes (overview). Front Door is for web workloads.
• No data path to pay for or trust. Nothing of yours is proxied, because there is no proxy.
• Maintenance windows. Point the name elsewhere, work on the endpoint, point it back (overview).
• Composition. Profiles nest, so several routing methods can combine for larger estates.

Our opinion, marked as ours. Sometimes the requirement is written in seconds: an RTO, a health-check budget, a clause about users not seeing errors during a regional outage. DNS is the wrong instrument for those, and no TTL setting rescues it. Sometimes the requirement is written in endpoints instead: five things, not all of them in Azure, that must live behind one name. There, Traffic Manager does something Front Door cannot.

When the answer is two services

Microsoft's guidance here is explicit, and easy to read past. Assess each service in the workload on its own. Expect a good design to use more than one kind of load balancing, in different places and for different jobs.

The combinations that recur:

• Front Door in front of Application Gateway. Microsoft names four situations that call for it (Front Door FAQ):
  • path-based balancing is wanted inside the virtual network, not only globally;
  • connection draining is needed, and Front Door does not have it;
  • TLS processing should finish at the edge, so only HTTP runs internally;
  • session affinity must pin to a server, not merely to a region.
• Front Door in front of Azure Load Balancer. Called out as a common pattern, with Private Link on the Premium tier as the way to keep the load balancer internal (Front Door FAQ).
• Traffic Manager over per-region Application Gateways. The Architecture Center points at this as a worked multi-region design, with inspection layered on for both web and non-web protocols.
• Global Load Balancer over regional load balancers. Same idea, one layer down and without HTTP awareness anywhere.

There is also a combination Microsoft warns about. You can make a regional service front backends in other regions, using cross-region Private Link, global peering or public addresses. Microsoft notes two costs: one region becomes a single point of failure for all of it, and traffic detours through that region on the way to another and back.

One more that is easy to get wrong: Front Door and Azure CDN are not stackable. They share the same edge estate, so their routing and caching rules collide, and Microsoft says to pick one (Front Door FAQ).

Where Microsoft's own pages disagree

We build exam material by reading the vendor's documentation directly. On Azure networking, that reading produces contradictions often enough that we now check every capability claim on the page instead of trusting our memory of it. Four of those contradictions touch this decision. We name them rather than quietly choosing a side, because you will find them yourself, and it helps to know the disagreement is the docs' rather than yours.

1. Is Application Gateway layer 7 only? Its own overview says the service operates at the application layer and describes it as a web traffic load balancer, with no mention of TCP or TLS proxying (last updated 2025-12-16). The Architecture Center's table gives it "HTTP(S), TCP, & TLS" (2025-11-12), and a dedicated page documents the layer 4 mode in detail (2025-11-26). We follow the two pages that agree with each other and are specific. The capability exists. The overview has not been updated to match it.

2. Which layer is Traffic Manager? The Architecture Center files it under non-HTTP(S) because it is DNS-based. The page describing how it works says the opposite in as many words — that DNS sits at the application layer, layer 7. Both are defensible and neither changes a decision. The Architecture Center is sorting by "does this thing read your requests" and Traffic Manager does not; the how-it-works page is sorting by the OSI position of the DNS protocol itself. If an exam question ever depends on this, it is testing the first sense.

3. Anycast or unicast for Front Door? The Front Door overview still credits the service's performance to its anycast network (2026-04-24). The FAQ says the opposite: name resolution and routing moved from anycast to unicast, and the change was made between March and April 2026 (2026-07-27). The load balancing category page also describes unicast routing. We follow the FAQ. It was updated most recently, it is specific about dates, and a second page agrees with it. No service choice depends on this. We flag it because the overview is the page most people read.

4. Where does Traffic Manager belong? Microsoft's "load balancing and content delivery" category page covers three services — Application Gateway, Load Balancer and Front Door — and does not include Traffic Manager at all. The Architecture Center's list does. Nothing is wrong here; the two pages are drawing category boundaries differently. It matters only if you use the category page as a checklist, in which case a whole service is missing from it.

What we would tell a colleague

Our shortlist, owned as our opinion rather than presented as guidance from Microsoft.

Learn the mechanism, not the table. Pass-through against terminating, and in-path against DNS-only, generate the table on demand. The table on its own generates nothing, and it goes stale — as two of its cells just did.

Ask what has to happen to the request, not what protocol it uses. "It is HTTPS" rules almost nothing out. "Something must read the path, or check the certificate, or block SQL injection" rules out half the options immediately.

Treat "which one" as the wrong question for anything of size. Microsoft's advice is to evaluate each service in the workload separately, and the combinations above are documented patterns, not compromises.

Check reachability early. Whether the origin may be publicly resolvable is often the constraint that decides the design, and it is nowhere on either axis of the quadrant.

If you are here for AZ-700

This decision is not an exam trick. It is a design skill that happens to be examined. On the AZ-700 outline it sits in "Design and implement application delivery services", weighted 15–20%. That area names Azure Load Balancer, Traffic Manager, Application Gateway and Front Door in its skill statements. Three of them — Load Balancer, Application Gateway, Front Door — each carry a matching pair: map requirements onto that service's features and capabilities, then identify appropriate use cases for it. Traffic Manager is the exception: it carries only an implementation statement (AZ-700 study guide). Mapping requirements onto features is the quadrant, plus the caveats above.

Our AZ-700 practice exams are written the way this article was. Every question traces to a free, public Microsoft page. Every explanation says why the other options fail, not only which one is right. ciply.io is an independent study provider and is not affiliated with or endorsed by Microsoft.