Front Door & Health Probes

Put a global front door on a site the CLI way

First stand up a tiny origin you control, with a real /health route, and check its answer. Then build one Front Door profile, endpoint, origin group, origin and route in front of it. This one-origin lab teaches configuration and probe inspection; it does not provide failover. Use a working /health endpoint that returns a non-success status when this origin cannot serve core requests. For production with one origin, disable unnecessary Front Door health probes; add a tested, independent second origin before claiming regional recovery.

1. Open Cloud Shell — the >_ icon in the top bar — and choose Bash. Set the origin host you will front:

   export MSYS_NO_PATHCONV=1   # Git Bash on Windows only; harmless elsewhere
   FD_RG="rg-campux-fd-$RANDOM"
   FD_ENDPOINT="campux$(date +%s)$RANDOM"
   APP="campux-origin-$RANDOM"
   LOC=centralus               # where the origin app runs; Front Door itself is global
   az group create --name "$FD_RG" --location "$LOC"

2. Write the origin app: twelve lines of Node.js. The home page answers with a heading; /health answers 200 ok. In a real shop the health route would also check the database; here it only proves the process is up.

   mkdir -p fd-origin && cd fd-origin
   cat > index.js <<'EOF'
   const http = require('http');
   http.createServer((req, res) => {
     if (req.url === '/health') {
       res.writeHead(200, { 'Content-Type': 'text/plain' });
       return res.end('ok');
     }
     res.writeHead(200, { 'Content-Type': 'text/html' });
     res.end('<h1>Campux storefront</h1>');
   }).listen(process.env.PORT || 8080);
   EOF
   cat > package.json <<'EOF'
   { "name": "fd-origin", "version": "1.0.0", "scripts": { "start": "node index.js" } }
   EOF

3. Deploy it to a free App Service plan and check the origin before Front Door exists. Predict the two lines first.

   az webapp up --name "$APP" --resource-group "$FD_RG" \
     --runtime "NODE:22-lts" --sku F1 --location "$LOC"
   ORIGIN="$APP.azurewebsites.net"
   curl -s -o /dev/null -w "%{http_code}\n" "https://$ORIGIN/health"   # 200
   curl -s "https://$ORIGIN/health"; echo                               # ok

   Checkpoint: 200 and ok. The first request after a deploy can take half a minute while the app starts; run it again before deciding it failed. If az webapp up itself fails, read the message: "not accepting new customers" or "Current Limit (F1 VMs): 0" means this region has no free plan for your subscription. Set LOC to another region and rerun the line (in our October 2026 run, westeurope refused and eastus had no F1 quota; centralus worked), deleting the .azure folder first so the command does not reuse the failed region's settings. A paid --sku B1 also works and costs about two cents an hour. Do not continue until both lines match, because Front Door cannot make a broken origin healthy. If you already have an app from Class 11 Part B with its own health route, you may set ORIGIN to that host instead.

4. Create the profile and a public endpoint:

   az afd profile create --resource-group "$FD_RG" \
     --profile-name fd-campux --sku Standard_AzureFrontDoor
   az afd endpoint create --resource-group "$FD_RG" \
     --profile-name fd-campux --endpoint-name "$FD_ENDPOINT" --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.

5. Create the origin group with the health probe — the honest one:

   az afd origin-group create --resource-group "$FD_RG" \
     --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: verify that /health exists and reflects this origin's readiness. With this single origin, Front Door has nowhere else to send a request even if the probe turns red. The probe is for learning here, not a failover demonstration.

6. Add the origin, then a route tying the endpoint to the origin group:

   az afd origin create --resource-group "$FD_RG" \
     --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 "$FD_RG" \
     --profile-name fd-campux --endpoint-name "$FD_ENDPOINT" --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 the endpoint overview. Deployment and propagation can take time. This route leaves caching off so a dynamic page is not cached by accident.

7. Compare the two paths. Ask Front Door for the same health route you checked on the origin:

   FD_HOST=$(az afd endpoint show -g "$FD_RG" --profile-name fd-campux \
     --endpoint-name "$FD_ENDPOINT" --query hostName -o tsv)
   curl -s -o /dev/null -w "%{http_code}\n" "https://$FD_HOST/health"

   Checkpoint: 200, the same answer as the origin. For a while you will see 404 while the new route propagates to the edge: in our run it took about nineteen minutes, so put the kettle on and retry every few minutes. A 404 that lasts more than forty-five minutes usually means the route or origin host name is wrong, so read them back with az afd route show. What you have proven: one request path through Front Door to one origin. What you have not: failover. That needs a second, independent origin in another region, which is a separate exercise and a separate bill.

8. Tear down (Front Door Standard bills while it exists):

   cd ..
   az group delete --name "$FD_RG" --yes --no-wait

   This removes the origin app and its free plan too. Delete only the temporary group you created above. If you start a new Cloud Shell session, find its exact name in Resource groups before deleting.

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.

1. Go to portal.azure.com and sign in.

2. 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.

3. 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: Standard can use caching and a WAF policy, but neither should be assumed enabled or protective until configured and tested.

4. Leave caching off for this dynamic site, then Review + create and create.Later: enable caching only for public static paths after checking cache headers. Do not cache accounts, carts or checkout.

5. Once deployed, open the profile → Origin groups → your group → and find the health probe settings.On screen: inspect the path and status, and remember that one origin cannot fail over. Disable the probe for a continuing single-origin deployment when it serves no routing purpose.

6. 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.

1. 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.

2. 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.

3. Open Security and inspect any associated WAF policy.On screen: verify whether a policy exists, is associated with this endpoint and has the intended rules and mode. A tier choice alone does not prove protection.