Four doors, one decision
An Azure application has four possible front doors, and every project that reaches for one without asking why ends up paying for capability nobody needed, or missing capability the workload actually required. The four are Azure Load Balancer, Application Gateway, Front Door, and Traffic Manager. Read their names in a vacuum and they sound like four unrelated products, each demanding its own memorised list of settings. They are not unrelated. Every one of them is an answer to the same two questions, and once you hold the two questions, the four doors sort themselves.
The first question is scope: does the door work only inside one Azure region, or does it stand at the edge of the whole world? Load Balancer and Application Gateway are regional — each lives in one region, in front of backends in that region, and knows nothing of any other. Front Door and Traffic Manager are global — a request or a lookup can land at whichever of Microsoft's locations is nearest the person making it, then travel on from there. Get this question wrong and the failure mode is specific: a single-region service put in front of a workload that serves three continents leaves two of those continents routing every request back across an ocean before anything useful happens; a global service put in front of a workload that only ever runs in one region buys distance and cost for reach nobody will use.
The second question is layer: how much of the request can the door actually read? Load Balancer and Traffic Manager cannot read the request at all — Load Balancer sees a connection as an address and a port and forwards it blind; Traffic Manager sees a name someone is trying to resolve and answers with an address, before a single packet of the real request exists. Application Gateway and Front Door read the HTTP request itself — the path, the host header, the cookies — and can route on what they find, terminate the encryption, and inspect the content for an attack. Layer decides the ceiling of what a door can ever do for you, and no amount of configuration raises it: a Layer 4 door will never route by URL, however carefully you wire it, because it has never been shown a URL to route by.
- The grid
- Two axes decide almost everything: scope — global or regional — and layer — blind at Layer 4, or reading the request at Layer 7. Every one of Azure's four traffic services sits at exactly one intersection of the two.
Cross the two questions and you get exactly four cells, and each of Azure's four traffic services sits in precisely one. Load Balancer is regional and blind to the request — the fastest, cheapest door, correct when the traffic is not even HTTP or when nothing about the content matters. Application Gateway is regional and reads the request — the door for an audience that never leaves one region but still needs path-based routing, TLS in one place, and a firewall that inspects the payload. Front Door is global and reads the request — the door for public web traffic that benefits from an edge close to the visitor, a cache for the parts of the site that do not change, and that same content-aware firewall applied thousands of kilometres from your application. Traffic Manager is global and blind — a name resolved to whichever region's address currently deserves it, with no opinion about anything the request contains. This grid is the entire subject; everything the two parts ahead teach is detail hung on these two axes.
There is a fifth thing every one of these four doors depends on, and it belongs in this frame as much as scope and layer do: the health probe. Each door sends its own backends a periodic question — are you fit to receive traffic? — and stops sending traffic to whichever backend answers no, or fails to answer at all. A door that never asks, or that asks the wrong question, is not resilient; it only looks resilient until the day it is not. A probe aimed at a page that always answers 200 regardless of what is actually broken behind it will keep routing customers into a machine that cannot serve them, for exactly as long as nobody notices the graph. Scope and layer decide which door fits a workload's shape. The probe decides whether that door is telling the truth about what is on the other side of it.
A door with the right shape and a lying probe opens onto nothing.
The track — two parts
The rest of Class Thirteen is two pages, each a full class with its own drills. The first stays in the regional column — the two doors that never leave a single Azure region. The second crosses to the global column and closes on the one mechanism every door in this class shares, and the one most often built wrong.
- 13a · Choosing the Door
- The two regional doors, worked in full: Load Balancer's four wiring parts and the NSG trap that leaves a healthy pool receiving nothing, then Application Gateway's routing and its Web Application Firewall in Detection versus Prevention.
- 13b · Front Door & Health Probes
- The two global doors — Front Door standing in the request path, Traffic Manager working only at DNS — and the routing methods that decide a failover. Closes on the health probe itself, the single most commonly misconfigured piece of the whole topic.
The one table the two parts fill in
Before the parts teach each door by hand, hold the shape whole. Place the four services on their two axes, and note the one property — a Web Application Firewall — that does not split cleanly along either.
| Door | Layer | Scope | WAF | Campux reaches for it when | Taught in |
|---|---|---|---|---|---|
| Load Balancer | L4 | Regional | No | Raw TCP/UDP across VMs in one region | 13a |
| Application Gateway | L7 | Regional | Yes | In-VNet web routing for one region's audience | 13a |
| Front Door | L7 | Global | Yes, at the edge | Public web traffic worth an edge cache | 13b |
| Traffic Manager | DNS | Global | No | Cross-region DNS direction, any protocol | 13b |
Read the table and the pattern behind the WAF column is worth naming on its own: a firewall that inspects content is a Layer 7 feature, so it only ever shows up on the two doors that can already read the request. Layer 4 Load Balancer and DNS-only Traffic Manager were never candidates for a WAF, not because Microsoft withheld the feature but because neither ever sees enough of the traffic to inspect it. Once you hold the grid, a fact like this stops needing to be memorised — it falls out of the two axes on its own.
Where Campux lands, and why
The running client gives the grid somewhere to bite. Campux Retail — forty stores, one storefront, an internal admin console only staff ever touch — has two workloads that want two different doors, and the mistake most beginners make is putting both behind whichever one they learned first.
Two doors, each chosen by scope and layer, not by fashion
The public storefront gets Front Door. Shoppers scattered across continents enter at the Microsoft edge nearest them, product images and scripts are cached there so the App Service origin is spared repeated load, and the edge WAF turns away the routine flood of injection and scripting attacks before any of it reaches the app. The Azure-managed rule sets that do that work are a Front Door Premium feature; the Standard tier carries a WAF too, but only rules you write yourself. Global audience, content worth caching, a firewall that must inspect the request — every one of those points at the global Layer 7 cell, which is Front Door and nothing else.
The internal admin application — one team, one region, never seen by the public — keeps Application Gateway with a WAF.1 It needs the same kind of request-aware routing and inspection as the storefront, but never leaves the region it runs in, so paying for a global edge would buy reach nobody on that team will ever use. Campux runs no Traffic Manager at all: it operates from a single region, so there are no cross-region endpoints for a DNS-level director to choose between — a door not used on purpose, which is its own kind of design decision.
Both doors probe their backends with real health endpoints, not a static page, because the one thing worse than an outage is a load balancer that cannot see it. The parts ahead build each door by hand; this hub is where you learn to make the call between them.
The graph that stayed flat
You open the admin console's dashboard on a quiet morning, not because anyone reported a fault. One of the two virtual machines behind its Application Gateway stopped answering the health probe an hour ago. The gateway took that machine out of the backend pool and has sent every request to the other one since. No ticket, no page, no member of staff who noticed. The near-miss is the lesson the whole class was building toward — the right door for the workload's shape, and a probe that asked a real question, so one dead machine never became a story anyone had to tell.
Examination
Four drills, then two situations. These test the judgement the whole track is built on; the hands are built in the two parts ahead. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
C. Application Gateway sits at the right layer — Layer 7, reading the request — but the wrong scope. It lives in one region, in front of backends in that region, and has no edge presence anywhere else. A three-continent audience needs the global cell of the grid, which only Front Door occupies: global reach, an edge cache, and a WAF applied at that same edge. B is false — reading the request is exactly what Application Gateway does. D is false — it probes its backend pool just as Load Balancer does; the missing thing is scope, not health checking.
B. Application Gateway and Front Door are the two Layer 7 doors — one regional, one global — and both can read the path, the host header, and the cookies and route on what they find. Both can also hand the whole request, body included, to a Web Application Firewall to inspect, which is why both, and only both, carry one. Load Balancer sees a connection as an address and a port; Traffic Manager sees a name to resolve. Neither has ever been shown the request itself, so neither can route on it, terminate it, or inspect it, however it is configured.
The NSG trap on Load Balancer, Traffic Manager's DNS-only reach, and the WAF's Detection mode. Each is a fact this class hangs its judgement on. The two wrong answers swap services: forwarding raw TCP/UDP blind is Load Balancer's job, not Front Door's, which is Layer 7 throughout; and resolving names at DNS before a packet arrives is Traffic Manager's whole description, not Application Gateway's, which lives inside a VNet reading real requests. Confusing which door does which job is exactly the confusion the grid exists to end.
TRAFFIC PLAN — Campux
1. Public storefront (three continents) -> Application Gateway with WAF.
2. Internal admin app (one team, one region) -> Application Gateway with WAF.
3. Both doors' health probes -> GET /health, checking real dependencies.
4. Future second storefront region, DR failover -> Traffic Manager, Priority routing.
Line one. Application Gateway is regional; it cannot stand at a global edge or serve three continents from one deployment. The storefront needs Front Door — global scope, the edge cache, and the WAF applied at that edge. Line two is sound: one team in one region is exactly Application Gateway's shape. Line three is sound: a real health endpoint on both doors is the point of the whole topic. Line four is sound: Priority routing is the honest choice for an active-passive DR failover between two regions once a second one exists.
Name what the colleague is conflating. Application Gateway and Front Door both read the request and both carry a WAF — they share the layer axis entirely. But they sit on opposite ends of the scope axis: Application Gateway lives in one region, and no configuration moves it to a second continent. Path routing and a firewall are necessary for the storefront; they are not sufficient once the audience stops being regional.
Say what actually breaks. Shoppers on the new continent would route back across an ocean to reach the single regional gateway, on every request, for pages that could otherwise be cached a few kilometres from them. Latency rises, the origin carries load an edge cache would have absorbed, and the "global" expansion is global in marketing only.
The fix, and what stays. Put Front Door in front for the global edge, the cache, and the edge WAF; Application Gateway does not have to disappear — it can keep serving the internal admin app, or sit behind Front Door fronting a specific regional need if one ever arises. Adding a door for the audience that now exists is not redundancy — it is answering the scope question honestly instead of stopping at the layer question because it was already answered.
Distrust the green dashboard first. A door reporting every backend healthy proves only that the backend answered the probe's specific question — not that it can serve a real request. Pull up the probe configuration on the admin app's Application Gateway and read exactly what it checks: a bare path that always returns 200 tells you nothing about whether the app's real dependency, most likely a database or a downstream service, was reachable during those twenty minutes.
Confirm by lining up the timelines. If the probe's uptime graph stays flat green through the window when staff saw errors, that is the proof: the probe was asking the wrong question the whole time. Fix it by pointing the probe at a dedicated health endpoint that actually calls the dependency and fails honestly when it cannot reach it.
Then answer the harder half of the question. This is not a weakness of Application Gateway specifically — every one of the four doors that probes at all trusts whatever answer the endpoint gives it, and a lying probe behind Front Door hides an outage exactly as well as one behind a regional gateway, just for a larger and more distant audience. Scope and layer decide which door fits the workload's shape; only an honest probe decides whether any of the four doors are telling the truth about what is actually behind them.
Five things worth carrying out of this hub
- Every Azure traffic service answers two questions: scope (regional or global) and layer (blind at L4, or reading the request at L7).
- The two regional doors come first — Load Balancer's four wiring parts and its NSG trap, then Application Gateway's routing and its WAF.
- The two global doors cross into a different world: Front Door stands in the request path itself; Traffic Manager only ever answers DNS.
- A Web Application Firewall only ever shows up on the two doors that can read the request — it is a Layer 7 feature, not a fifth option.
- Scope and layer decide which door fits a workload's shape. A health probe that lies means the right door still opens onto nothing.
- "Front Door for new public web projects" is the current industry lean, not a rule for every case. Application Gateway remains right when the traffic is specifically regional and in-VNet — the internal admin app here — and plenty of sound designs run both together, Front Door at the global edge routing on to regional gateways behind it. Default to Front Door for public web; justify the alternatives by the constraint that calls for them. ↩