Four doors, one decision
A customer opens your web address, but the application might have several healthy servers or even several regions behind it. Something must decide where the request goes. This class compares four common Azure choices: Load Balancer, Application Gateway, Front Door, and Traffic Manager. An app may need one, more than one, or none of them. Start with the traffic and the failure you need to handle.
First ask where the service is deployed. Load Balancer and Application Gateway are regional resources. Front Door is a global HTTP entry point. Traffic Manager is a global DNS service that answers name lookups with a selected endpoint. A regional gateway can still receive users from elsewhere and, if network reachability permits, use remote backends; it simply does not provide a global edge near each user. Measure whether an edge improves this workload enough to justify its cost.
Next ask what it processes. Load Balancer forwards TCP or UDP connections using network addresses and ports: Layer 4. Application Gateway and Front Door process HTTP requests: Layer 7, so they can route by host or path and use a web application firewall when configured. Traffic Manager processes DNS queries before the client connects; it is not a Layer 4 load balancer and never carries the application request. A Layer 4 service cannot route by URL because it does not read HTTP.
- The grid
- Use two prompts: where is the service deployed, and what does it process? The answer to the second is TCP/UDP connections (Layer 4), HTTP requests (Layer 7), or DNS lookups. Traffic Manager belongs to the DNS category, not to Layer 4.
Load Balancer is a candidate for regional TCP/UDP distribution. Application Gateway handles regional HTTP routing and can add a WAF. Front Door handles HTTP at a global edge and can cache suitable static responses. Traffic Manager selects a DNS answer and works with many protocols because it does not carry the traffic. Compare health checks, origin reachability, cost, and failure behavior before choosing. A global audience alone does not prove that every response will be faster through Front Door, especially when the only origin is still in one region.
Each service also needs a useful health check for its destinations. A check that always returns success can hide a broken application. But a check that fails whenever a nonessential dependency slows down can remove healthy capacity. Define what "ready to serve" means for this workload, test the endpoint, and alert when all destinations fail. Traffic Manager checks endpoints for its DNS decisions; it does not probe each client request.
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
Use this table to compare where each service runs and what it actually handles. WAF capability belongs to the HTTP services; it still needs to be configured and tested.
| 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 | Optional WAF SKU | Regional HTTP routing, including private access | 13a |
| Front Door | L7 | Global | Optional edge WAF | Global HTTP entry, routing, or safe static caching | 13b |
| Traffic Manager | DNS | Global | No | Cross-region DNS direction, any protocol | 13b |
A WAF inspects HTTP, so Load Balancer and Traffic Manager cannot provide one in their traffic path. Application Gateway and Front Door can, but WAF protection is not automatic: choose the appropriate SKU and policy, tune rules, and check what they block. Front Door Standard supports custom WAF rules; Premium adds managed rule sets.2
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 is a candidate for Front Door if measurements show that global entry and caching static images and scripts improve the experience. Dynamic and personalized responses stay uncached. If the threat model calls for managed WAF rules, choose and tune Front Door Premium; Standard supports custom rules. A global edge does not create a second origin: with one App Service region, that region remains a failure point.3
The internal admin application may use Application Gateway with a WAF if it needs regional HTTP routing and inspection through a private entry point. Check whether simpler private access would suffice before adding a gateway. Campux has no second-region deployment in this example, so Traffic Manager would not yet provide failover.1
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 notice one of two admin-app VMs failed its Application Gateway health check. The gateway marks it unhealthy and routes new requests to the other VM. Verify that the remaining VM can carry the load, alert the on-call team, and investigate the failed instance. A working probe limits customer impact; it does not replace monitoring or capacity planning.
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 can serve distant visitors and, when reachable, remote backends, but the gateway itself is regional. It does not meet the stated global edge cache and WAF requirement. Front Door is a candidate for that requirement; confirm the expected benefit and cost. Application Gateway does read HTTP and does probe backends, so B and D are false.
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 (global edge cache required) -> 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 and has no global edge cache. Front Door can meet that specific requirement. The admin app may justify a regional gateway if it needs its HTTP routing and WAF. A health endpoint must reflect readiness without making every temporary dependency slowdown take down all backends. Traffic Manager Priority can select a healthy standby endpoint for a future two-region plan, subject to DNS caching and tested recovery.
Measure first. Application Gateway can still accept visitors from another continent. Compare real page latency, static-asset transfer, origin load, and user geography before claiming the current design is broken.
Explain the change. Front Door can provide a nearer HTTP entry point and cache appropriate static assets. Its WAF can inspect at the edge. Keep personalized pages and authenticated APIs uncached. If the app has only one regional origin, adding Front Door does not remove that origin's outage risk.
Decide with the team. Compare the measured benefit, Front Door tier and WAF needs, cost, and origin-security plan. Keep Application Gateway for a separate regional need if it earns its place; do not keep both simply because both exist.
Compare two timelines. Review the gateway probe path, status codes, and thresholds alongside the app's request-error logs during those twenty minutes. A green probe shows only that its own check passed; it does not prove that every user path worked. Also inspect whether the gateway or application emitted alerts that were missed.
Test the failure mode. If checkout failed because a required dependency was unavailable while a static probe still returned 200, design a readiness check that reflects whether this instance can serve its critical requests. Avoid making every brief, shared dependency slowdown mark all instances unhealthy. Test thresholds and alerting with a controlled failure.
Apply the lesson to Front Door too. Front Door also uses origin health checks. A shallow check can leave a broken origin eligible; an overstrict check can remove capacity unnecessarily. The right probe is one part of observability, not proof that users are succeeding.
Five things worth carrying out of this hub
- Ask where a service is deployed and what it processes: TCP/UDP connections, HTTP requests, or DNS lookups. Traffic Manager is DNS, not Layer 4.
- 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.
- Microsoft's Application Gateway FAQ explains that reachable backends can be outside the gateway's VNet. The gateway itself remains regional. ↩
- Microsoft's Front Door WAF guide distinguishes Standard custom rules from Premium managed rules. ↩
- Microsoft's Front Door caching guide recommends caching static assets and warns against caching personalized responses. ↩
Compare four Azure traffic services by deployment scope and whether they handle connections, HTTP requests or DNS lookups.