Front Door and CDN

Azure has offered content delivery through several distinct products over the years, three of which are now retired or in the process of retiring. Understanding this history matters because a reader arriving at an older tutorial, an existing subscription, or a Terraform module may well encounter one of these rather than current Azure Front Door Standard/Premium.

The common thread across all four retirements is the same destination: Azure Front Door Standard or Premium, which is what the rest of this page covers, and which supersedes every one of the above rather than being one more alternative among them.

References: Azure CDN Standard from Microsoft (classic) retirement FAQ, Azure CDN from Edgio retirement FAQ, Azure Front Door (classic) retirement FAQ, Migrate Azure CDN (classic) to Front Door Standard or Premium, Migrate Azure Front Door (classic) to Standard or Premium, Migrate between CDN providers.

Front Door ships as two SKUs of the same underlying product, chosen at profile-creation time with --sku Standard_AzureFrontDoor or --sku Premium_AzureFrontDoor (changeable afterward via az afd profile update --sku, one direction only — Standard can be upgraded to Premium, not the reverse):

Bookshelf’s afd-bookshelf profile in this page’s walkthrough is created as Premium, specifically so the Private Link origin section later on has something real to configure; drop to Standard_AzureFrontDoor if managed WAF rule sets and Private Link origins are not required.

References: Compare Azure Front Door tiers, Tier comparison for Azure Front Door Standard and Premium, Front Door pricing comparison.

Every Front Door deployment is built from the same six resource types, always nested in the same order. A profile is the top-level Front Door resource (afd-bookshelf) and the billing/SKU boundary. Inside it, an endpoint is a logical grouping of domains — it gets Front Door’s own generated hostname (<endpoint>-<hash>.z01.azurefd.net) plus any custom domains later attached to its routes. A route lives under an endpoint and matches incoming request patterns (/, /api/) to one origin group; it also carries the route’s caching configuration and any attached rule set. An origin group is a load-balanced, health-probed pool of one or more origins — the actual backend endpoints (Bookshelf’s storage static website, `catalog-api’s Container Apps ingress). A security policy attaches a WAF policy to one or more domains at the profile level, independently of routes.

References: Front Door overview, Origins and origin groups, Front Door routing architecture.

An origin group is where health probing and load balancing are configured, once, for every origin it contains. Bookshelf needs two origin groups: one for the static site’s storage origin, one for catalog-api.

A route binds an endpoint’s incoming pattern to an origin group and carries its own cache configuration. Bookshelf uses two routes on the bookshelf endpoint: / for the static site, /api/ for catalog-api.

A rule set is a named, reusable collection of ordered if match-condition then action rules, attached to one or more routes. It is where cache overrides, redirects, and header rewrites live — capabilities the classic CDN rules engine also had, but with a richer condition/action vocabulary (regular expressions and server variables among them) on Standard/Premium.

Purging removes cached content from every edge POP immediately, ahead of its TTL — necessary after a Bookshelf release that changes static-site assets without changing their URLs, since otherwise stale content would continue to be served until each POP’s cached copy naturally expires.

A custom domain is created under the profile, validated by DNS TXT record, then attached to whichever route(s) should answer for it — the same free, auto-renewing managed-certificate model Container Apps and Blob Storage use elsewhere in Bookshelf, issued by DigiCert on Front Door’s behalf.

Either way, a TXT record at _dnsauth.<subdomain> holding the domain’s validation token is required before Front Door will issue a certificate for it; propagation of that record is the most common source of a custom-domain validation stuck in Pending (see Troubleshooting).

A WAF policy is created independently of any Front Door profile, then bound to one or more domains through a security policy — the object model’s own dedicated resource type for this, distinct from a rule set.

Premium-tier Front Door can reach an origin over Azure Private Link rather than the public internet: Front Door creates a private endpoint from its own managed regional virtual network into the target resource, which must be approved (portal, CLI, or PowerShell) before traffic flows. Supported origin types include Blob Storage, a storage static website, App Service (Web App/Function App), Azure Container Apps, API Management, Application Gateway, and internal load balancers (including an AKS-fronting one); an origin group cannot mix Private-Link and public origins, and mTLS to the origin is not supported either way.

Front Door emits three kinds of telemetry, all through Azure Monitor:

References: Monitor metrics and logs in Azure Front Door, Front Door reports, Access log schema.

Front Door billing has three independent components, applied per profile. A fixed base fee per profile per month differs by tier (Premium’s base fee is meaningfully higher than Standard’s, reflecting managed WAF rules and Private Link) and includes a bundled allotment of outbound data transfer and requests before additional usage charges apply. Beyond that allotment, outbound data transfer is billed per GB, tiered by volume and by the client’s origin continent/zone, and requests are billed per million, again split into tiers. WAF itself is billed separately: a flat monthly fee per policy plus a per-million-requests charge for policy evaluation, on top of whatever Front Door tier fee already applies — so attaching a WAF policy to afd-bookshelf adds cost independent of the profile’s own SKU. Private Link origin traffic and the private endpoints it creates carry Azure Private Link’s own standard charges in addition to Front Door’s. Rules-engine usage, custom domains, and managed certificates carry no separate charge. Exact current rates vary by currency and region and change over time; treat any number quoted verbally as illustrative, and check the official Front Door pricing page and the WAF pricing notes before budgeting.

References: Azure Front Door pricing, Understand Azure Front Door billing, Front Door pricing comparison across tiers.

A route returning HTTP 502 or 504 almost always traces back to origin health: check az afd origin-group show and the portal’s Origin health blade first, since a route with no healthy origin in its origin group fails every request regardless of how correctly the route itself is configured. The most common root cause is the health-probe path itself — a probe pointed at / on catalog-api when the app has no handler for / (only /api/…​) reports the origin unhealthy even though the app is perfectly fine, so point --probe-path at a real endpoint (an actuator/health-check route) rather than the site root, and confirm the probe’s --probe-protocol matches what the origin actually serves on that port.

A cached response that keeps serving stale content well past its expected TTL, or that serves the wrong variant of a paginated/filtered response to different users, is very often a query-string caching-behavior mismatch: IgnoreQueryString on a route whose backend content genuinely varies by query string will cache the first response seen and keep serving it for every subsequent query string until the TTL lapses. Switch that route to UseQueryString (or the Include/IgnoreSpecifiedQueryStrings modes) and purge the stale entries with az afd endpoint purge rather than waiting out the TTL.

A custom domain stuck in Pending validation for longer than a few minutes almost always means the TXT record hasn’t propagated yet, or was created under the wrong name — nslookup -type=TXT _dnsauth.<subdomain>.<domain> from several resolvers (including a public one like 8.8.8.8, since a corporate DNS server may cache an old empty answer) confirms whether the record is actually visible yet; DNS propagation can take up to 48 hours in the worst case even though it typically completes in minutes, so retry validation rather than recreating the custom-domain resource.

A WAF policy blocking legitimate Bookshelf traffic (a false positive from DRS 2.1, most often on a request body containing something that looks like a SQL/script fragment — a customer review with an apostrophe and a <script>-like string, for instance) should first be confirmed by running the policy in Detection mode and reading the matched rule ID from FrontDoorWebApplicationFirewallLog, then narrowed with a targeted exclusion (a specific request header, cookie, or body field, scoped to that one rule ID) rather than disabling the whole managed rule set, which reopens the exact exposure DRS 2.1 exists to close.

References: Health probes in Azure Front Door, Caching in Azure Front Door, Troubleshoot custom domain validation, WAF exclusion lists, WAF tuning.

Front Door’s own resources (afd-bookshelf, its endpoint, origin groups, origins, routes, rule sets, custom domains, and security policies) all live inside $RG and are removed with it. Two things are not in $RG and need their own cleanup: a WAF policy created with az network front-door waf-policy create in a different resource group must be deleted separately (az network front-door waf-policy delete --name wafbookshelf --resource-group <its-resource-group>) once no security policy references it any more; and a Premium Private Link origin’s approved private endpoint is deleted automatically when the owning Front Door profile is deleted, but the private endpoint connection record on the origin side (the Container App, storage account, and so on) can take a few minutes to disappear from that resource’s own Networking blade — expected, not a sign that cleanup failed.