Front Door: the global front door
For a public website, the modern default is Front Door. It is the global Layer 7 service: traffic enters at Microsoft's edge locations around the world — hundreds of them — and is routed to the nearest healthy backend region, with a content cache and a web firewall built in at that same edge.
Three things make it the standard choice for web today. It is global, so a visitor in another continent enters at an edge near them rather than crossing the planet to your region. It caches static content at the edge, so images and scripts are served close to the user and never trouble your origin — the CDN behaviour folded in. And it carries a WAF at the edge, so attacks are absorbed far from your application, along with the platform's DDoS protection.1 A request for a cached product image may be answered entirely at the edge, thousands of kilometres from the storefront, in a few milliseconds.
The distinction from Traffic Manager is the one interviews probe, so hold it precisely. Front Door is in the data path: traffic flows through it, so it can cache, inspect and route on content. Traffic Manager works at DNS: it answers the question "which address should this name resolve to" and then steps out of the way — it never sees the traffic, cannot cache, cannot inspect.2 Traffic Manager is the motorway sign; Front Door is the entrance you actually walk through. Choose Traffic Manager when you need DNS-level direction across endpoints of any protocol; choose Front Door when you want a global HTTP front door that does real work on the request.
Traffic Manager's four ways to choose an endpoint
When you do reach for Traffic Manager — steering across regions, or across services Front Door does not front — the next question is which endpoint its DNS answer should name. That is set by the routing method, and choosing the wrong one is how a design that looks highly available quietly sends every user to a single region anyway. Four are worth committing to memory.
| Method | Answers with | Reach for it when |
|---|---|---|
| Priority | The highest-priority endpoint that is healthy; the rest wait as cold standby | Active-passive failover — one primary region, others held in reserve |
| Weighted | An endpoint chosen at random, in proportion to weights you assign | Gradual rollouts and A/B splits — send ten percent to the new region |
| Performance | The endpoint with the lowest measured network latency for that user | Active-active across regions — put each user on their nearest healthy one |
| Geographic | The endpoint mapped to the user's geographic origin | Data residency and compliance — EU users must land in an EU region |
Two more exist for completeness — Subnet maps source-IP ranges to endpoints, and MultiValue returns several healthy addresses at once — but the four above carry almost every real design. Watch the trap between Performance and Geographic: they sound alike and are not. Performance asks "who is closest"; Geographic asks "where are you from, by law." A requirement that EU data stay in the EU is met only by the second, even when a faster region sits just across the border — and reaching for Performance there is a compliance breach dressed up as a latency win.
Health probes: the part everyone gets wrong
Every one of these services sends health probes to its backends and stops sending traffic to any that fail. This is the mechanism that turns a pool of machines into something resilient — and it is also the single most commonly misconfigured thing in the whole topic.
- Health probe
- A periodic request the load balancer makes to each backend to decide whether it is fit to receive traffic. Its worth depends entirely on whether the thing it checks reflects the thing that matters.
A probe that always says healthy is blind.
Here is the classic failure. A probe is pointed at the site's home page, or a bare / that returns a static "200 OK" no matter what — and it dutifully reports every instance healthy even while the application behind it cannot reach its database and is failing every real order. The load balancer, seeing green, keeps routing customers to a broken machine. The probe was answering "is the web server process running?" when the question that mattered was "can this instance actually serve a request?"
The fix is a probe that tells the truth: a dedicated health endpoint that checks the app's real dependencies — its database, its critical downstream services — and returns unhealthy when any of them is down, so the load balancer pulls the instance out before a customer hits it. Configure the probe to reflect readiness, not mere aliveness, and set the thresholds so a blip does not eject a healthy node nor a real failure linger. A load balancer is only as honest as its probe; a probe that cannot fail is a light that is painted green.
| Service | Scope | Layer | Reach for it when |
|---|---|---|---|
| Load Balancer | Regional | L4 (TCP/UDP) | Spreading raw connections across VMs in a region |
| Application Gateway | Regional | L7 (HTTP) | In-region web routing and a WAF, inside the VNet |
| Front Door | Global | L7 (HTTP) | A global public website: edge caching, routing, WAF |
| Traffic Manager | Global | DNS | DNS-level direction across endpoints, any protocol |
Walking the decision, in order
Table 1 is the map; the tree is the route through it. Faced with a new workload, ask the questions in a fixed order and the four services sort themselves. First: do you need to route or inspect by what the request says — a URL path, a host header, a web firewall? If no, the leanest honest answer is Layer 4 Load Balancer, and you are done. If yes, you need Layer 7, and only then does the second question matter: is the audience global, or would an edge cache earn its keep? Global and public points to Front Door; regional and in-VNet points to Application Gateway. Traffic Manager sits off to the side of this tree entirely — you add it not instead of these but above them, when you must steer across regions or protocols at the DNS layer. Answer in that order and you will not price a global edge to solve a single-region problem, nor hang a turnstile on a job that needed to read the URL.
Campux's front door, and its side door
The public storefront gets Front Door. Shoppers enter at the Microsoft edge nearest them; product images and scripts are cached there, so the App Service origin from Class Eleven is spared the repeated load and pages feel fast far from the region; and the edge WAF turns away the routine flood of injection and scripting attacks before they reach the app. For a seasonal retailer whose traffic is spiky and public, the global edge and the cache are worth exactly what they cost.
The internal admin application — used only by staff, never by the public — keeps the Application Gateway with WAF from Part I, inside the VNet. It needs Layer 7 routing and a firewall, but not a global edge; a regional gateway close to its backends is the honest fit, and keeping it internal is part of its security.3 Campux uses no Traffic Manager: it runs in a single region, so there are no cross-region endpoints for a DNS-level director to choose between — a service not used on purpose, which is its own kind of design decision.
Both front 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. Next class removes the public door from the parts that should never have had one.
Play it through
Four minutes, two decisions. Match a description to its door, then pick the one that keeps a global storefront open the day a whole region goes dark — and give the instance behind it a health check that tells the truth. It plays on its own and stops when it needs your hands.
Put a global front door on a site the CLI way
You placed Front Door in front of the outage above, and gave the pool a probe that tells the truth. Now do it for real. You will stand up an Azure Front Door — profile, endpoint, origin group, origin, route — in front of a public web address. The origin group is where the health probe lives, so this lab is also where you configure the thing everyone gets wrong. Point the origin at the web app from the Class Eleven lab, or any site you own.
Open Cloud Shell — the >_ icon in the top bar — and choose Bash. Set the origin host you will front:
az group create --name rg-campux-lab --location westeurope ORIGIN=<your-app>.azurewebsites.net # a public host you controlCreate the profile and a public endpoint:
az afd profile create --resource-group rg-campux-lab \ --profile-name fd-campux --sku Standard_AzureFrontDoor az afd endpoint create --resource-group rg-campux-lab \ --profile-name fd-campux --endpoint-name campux --enabled-state Enabled
On screen: the endpoint is a global entry name at Microsoft's edge — the front door itself. Nothing is routed anywhere yet; the next steps say where traffic goes and how health is judged.Create the origin group with the health probe — the honest one:
az afd origin-group create --resource-group rg-campux-lab \ --profile-name fd-campux --origin-group-name og-campux \ --probe-request-type GET --probe-protocol Https \ --probe-path /health --probe-interval-in-seconds 30 \ --sample-size 4 --successful-samples-required 3 \ --additional-latency-in-milliseconds 50
The lesson: the probe path is /health, not / — a real readiness endpoint that fails when the app's dependencies fail, so Front Door pulls a broken origin before customers hit it. Probing the home page is how a dead instance keeps serving errors.Add the origin, then a route tying the endpoint to the origin group:
az afd origin create --resource-group rg-campux-lab \ --profile-name fd-campux --origin-group-name og-campux \ --origin-name storefront --host-name $ORIGIN \ --origin-host-header $ORIGIN --https-port 443 \ --priority 1 --weight 1000 --enabled-state Enabled az afd route create --resource-group rg-campux-lab \ --profile-name fd-campux --endpoint-name campux --route-name route \ --origin-group og-campux --supported-protocols Https \ --forwarding-protocol HttpsOnly --link-to-default-domain Enabled \ --https-redirect Enabled
On screen: browse the endpoint's *.azurefd.net hostname (from az afd endpoint show) and your origin answers through the global edge. Propagation takes a few minutes.Tear down (Front Door Standard bills while it exists):
az group delete --name rg-campux-lab --yes --no-wait
Create a Front Door by hand
Now build it by clicking. The quick-create flow bundles endpoint, origin, and route on one page — and the origin section is where the health probe is set. Use the same public origin host.
Go to portal.azure.com and sign in.
In the search bar at the top, type Front Door and CDN profiles, select it, then + Create and choose Quick create.On screen: Quick create asks for the tier (choose Standard), an endpoint name, and an origin — the three pieces you built one command at a time in Lab 1, now on a single form.
Set Tier to Standard, name the profile and endpoint, and add the origin: origin type (App Services or Custom) and the public host name.On screen: choosing Standard folds in the CDN cache and a WAF option; Premium adds managed security rules. This is the modern default the class recommends for public web.
Enable caching if offered, then Review + create and create.On screen: caching at the edge is what serves your images near the user without touching the origin — the behaviour that makes a global site feel fast far from its region.
Once deployed, open the profile → Origin groups → your group → and find the health probe settings.On screen: confirm the probe path points at a real health endpoint, not the home page. This one field is the difference between detecting an outage and serving customers into one.
Tear down: delete the resource group (or the Front Door profile).
Portal wording drifts; if a label here does not match your screen, the anchors are the Front Door and CDN profiles service, Quick create, and the Origin groups / health probe settings.
Read routing, caching, and the probe on the blades
Open the Front Door you built and let each blade confirm a fact from the class.
Open the profile's Origin groups and read the health probe and load-balancing settings.On screen: probe path, interval, and the sample counts that decide healthy vs unhealthy. This is the blade the whole §2 is about — a probe pointed at a static page is the most common self-inflicted outage in the topic.
Open Endpoints and the routes under them.On screen: which paths forward to which origin group, and the HTTPS-redirect and caching rules. This is Layer 7 at work — routing on the request, not just the connection.
Open Security (or the associated WAF policy, if you added one).On screen: the web application firewall applied at the global edge — attacks turned away far from your origin. On Standard it is optional; on Premium it comes with managed rules.
The morning a region stopped answering
Support pings you about a slow morning, not a dead one. You check the storefront's Front Door dashboard: West Europe stopped answering an hour ago, and every shopper has been landing in North Europe since the moment it did, because the edge noticed before anyone paged you. The near-miss is the lesson — a health probe pointed at a real endpoint bought back a night's sleep and cost the business nothing but one flat line on a graph nobody had to watch.
Examination
Four drills, then two situations. Write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
C. Global, edge caching, routing, and a WAF at the edge is the exact description of Front Door. A is regional and Layer 4 — no HTTP awareness, no caching. B is Layer 7 with a WAF but regional, so it gives no global edge or cache. D directs at DNS and never touches the traffic, so it cannot cache or inspect anything. When the words "global," "cache," and "web firewall" appear together, the answer is Front Door.
Global edge routing, edge caching, and an edge WAF. Those are Front Door's defining three. The two wrong answers are other services in disguise: raw TCP/UDP balancing is Load Balancer's Layer 4 job — Front Door is HTTP/HTTPS only — and "purely at DNS, never in the data path" is the precise definition of Traffic Manager. Picking either reveals the confusion this class exists to end: Front Door is in the traffic; Traffic Manager only points at it.
Health probe — storefront backend pool
1. Protocol: HTTPS
2. Path: / (static home page, returns 200 always)
3. Interval: 30s, unhealthy after 3 failures
4. Backend port: 443
Line two. Probing / — a static page that returns 200 regardless of whether the app can actually serve orders — means the probe reports healthy even when the instance's database is unreachable and every real request is failing. The probe measures "is the web server up," not "can this instance do its job," so the load balancer keeps routing customers to a machine that is silently broken. Lines one, three and four are reasonable.
Consider the consequence. During an incident where the database is down, customers keep being sent to dead instances and see errors, while every dashboard shows the backend "healthy" — the outage is invisible to the very system meant to detect it. The fix is a real health endpoint that checks dependencies and returns unhealthy when they fail. A probe that cannot report sick is a smoke detector with the battery removed.
C. Performance answers "who is closest by measured latency" — it can and will send an EU user to a faster non-EU region the moment the numbers favour it, which is exactly the outcome the requirement forbids. Geographic answers a different question, "where is this user from, by policy," and maps that origin to a fixed endpoint regardless of speed. Priority and Weighted solve failover and gradual rollout, neither of which is what a residency rule asks for. Reaching for Performance here is a compliance breach dressed up as a latency win.
Reject the premise first: this is not "down." A site that is down is down for everyone; a site that fails for one ISP in one city is a path problem, not an origin problem. The single most useful move is to stop trusting one vantage point — test from multiple locations and networks (your phone off wifi, an external checker, a colleague elsewhere) to draw the boundary of who is actually affected. The shape of the failure is the diagnosis.
Work the path from the user inward. With a global front door, traffic from that ISP enters at a nearby edge location — so suspect the leg between the user and the edge, or that specific edge, before your origin. Check DNS resolution on the affected network (are they getting the right address, is a stale or poisoned cache sending them wrong?), then whether the edge they land on is healthy, then peering or routing between that ISP and Microsoft's edge. Your origin serving everyone else fine is strong evidence the fault is out there, not in here.
Separate "our problem" from "their path," then act accordingly. If it is a bad edge or a routing issue, you gather evidence and escalate with specifics rather than thrashing your own healthy backend. If it is DNS TTL or a misconfiguration on your side that only some resolvers have picked up, that is yours to fix. Either way, the discipline is the same: measure the blast radius before you touch anything, because "down" was a word that would have sent you debugging the one thing that was working.
Name the category error: Traffic Manager works at DNS, and DNS cannot cache pages. Traffic Manager answers "what address should this name resolve to" and then steps out of the path entirely — it never sees a single request, so it cannot cache content, inspect it, or accelerate it. The teammate has asked a DNS director to do a content-delivery job it is architecturally incapable of.
Point at the tool that actually does this. Global caching and acceleration for a website is Front Door's job — it sits in the data path at the edge, caches static content near users, and routes on the request. If the goal is "faster pages globally," Front Door is the answer, and it is very likely already the storefront's front door, so there may be nothing new to add at all.
Say where Traffic Manager would be right, so the correction teaches. Traffic Manager earns its place directing across endpoints of any protocol — for instance steering between two regions for disaster recovery, or across services Front Door does not front. It is a real tool for a real job; caching pages is simply not that job. Matching the service to the layer is the whole skill this class is training.
Five things worth carrying out of this class
- Front Door is global and Layer 7, in the request path, with an edge cache and a WAF — the modern default for public web.
- Traffic Manager works at DNS only: it names an endpoint and never touches the traffic, so it cannot cache or inspect anything.
- Performance and Geographic sound alike and are not. Performance asks who is closest; Geographic asks where a user is from, by policy.
- A health probe must reflect real readiness, not mere aliveness. A probe that cannot fail keeps sending customers to broken machines.
- Two questions, asked in order — route by content, then reach past one region — place three of the four services; Traffic Manager joins from the side.
- Microsoft has consolidated its edge and content-delivery lineup over time — Front Door now comes in Standard and Premium forms that fold in the CDN and WAF capabilities, and older standalone CDN offerings are being retired. Learn the capability — global edge, caching, WAF, in the data path — rather than the exact SKU name, and check the current product page before you quote a tier or a feature boundary. ↩
- Because Traffic Manager works through DNS, its failover is only as fast as DNS lets it be: clients and resolvers cache the answer for the record's time-to-live, so a failed endpoint can keep receiving traffic until those cached lookups expire. This is the structural reason Traffic Manager reacts in the tens of seconds to minutes, not instantly, and why a data-path service like Front Door fails over faster — it is in the traffic, not merely naming it. ↩
- "Front Door for new projects" is the current industry lean, not a rule for every case. Application Gateway remains right when you specifically need a regional, in-VNet Layer 7 with a WAF and no global edge — the internal admin app here — and plenty of sound designs run both, Front Door at the global edge routing to regional gateways. Default to Front Door for public web; justify the alternatives by the constraint that calls for them. ↩