Azure Front Door: a practical introduction

If you run anything serious on Azure, sooner or later Azure Front Door shows up on your radar. This post explains what it actually is, who should use it, the trade-offs versus Cloudflare and CloudFront, and the specific settings that matter when putting it in front of an Azure App Service. If you're evaluating an edge layer for an Azure-hosted app, this should give you the full picture in one read.

What is Azure Front Door

Azure Front Door is Microsoft's global edge layer. It sits between your users and your origin server (App Service, VM, AKS, whatever) and gives you, in one box:

• Anycast routing — a user in Tokyo hits a Tokyo edge, a user in Frankfurt hits a Frankfurt edge, then Microsoft's backbone carries traffic to your origin. Latency drops, dramatically for users far from your origin region.
• TLS termination at the edge — your origin doesn't need to handshake with every client.
• CDN caching — static assets cached at the edge, served without ever touching your origin.
• Web Application Firewall (WAF) — OWASP-style rule sets, bot management on the Premium tier.
• DDoS protection — Microsoft's network absorbs volumetric attacks before they reach you.
• Global load balancing — multi-region routing with health probes, automatic failover.
• Custom domain + free managed certificates — you bring the domain, Microsoft handles the cert.

It's positioned as "the front door to your app" — literally. Everything a request needs to pass through before reaching your servers.

Two product lines, easy to confuse

"Azure Front Door" today is actually the rebrand of two older products:

• Azure Front Door Standard / Premium — current generation. Combines the older Front Door + Azure CDN into one product. This is what you should use.
• Azure Front Door (classic) — the older standalone Front Door. Microsoft is sunsetting it; new deployments should not use it.

If you see "Azure CDN from Microsoft" in older docs, that's been folded into Front Door Standard. The classic Akamai and Verizon CDN tiers Microsoft used to resell are end-of-life.

Who is it for

Front Door is a strong fit when:

• Your app is on Azure (App Service, AKS, Container Apps, Functions, VMs) and you want one Microsoft invoice.
• You serve users across multiple regions and want anycast routing.
• You want a stable anycast IP or hostname that customers can point apex domains at — without worrying about Azure App Service's inbound IP changing under you.
• You need a WAF in front of a public app and prefer Microsoft's managed rule sets.
• You're running a multi-region active-active deployment and need health-based failover.

It's not the right tool if you only have one region, no public exposure (purely internal), or if you genuinely just need a flat CDN — in those cases Cloudflare's free tier or just App Service's built-in features cover you for $0.

Benefits

Latency drops for distant users

This is the headline benefit. Your origin lives in one Azure region. Without an edge layer, a user 8,000 km away pays the full round-trip on every request, including TLS handshake. With Front Door, the TLS handshake terminates at the user's nearest edge (usually under 30 ms away) and Microsoft's backbone handles the long-haul to your origin. For first-byte time on TLS connections, this is often a 200–500 ms win.

Stable anycast hostname for apex domains

If you run a SaaS where customers point their own domain at your app, you've probably hit the apex CNAME problem: DNS doesn't allow CNAME at the zone root, so a customer can't CNAME customer.com → yourapp.com. The fallback is an A record pointing at your origin's IP — but App Service inbound IPs aren't contractually stable, so if it ever changes, every customer's site breaks at once. Front Door gives you a stable anycast endpoint customers can A-record to (or, on supportive DNS providers, ALIAS to the Front Door hostname).

One invoice

If you're already deep in Azure, Front Door shows up on the same bill as everything else, with the same support contract. No separate vendor procurement, no separate SOC 2 review, no separate incident-response runbook.

Managed certificates, free

Front Door issues and renews TLS certificates for your custom domains automatically. No Let's Encrypt cron job to maintain, no manual renewal, no expired-cert outage at 3 AM.

WAF and DDoS as line items, not architecture decisions

Both are toggles on the Front Door route configuration. You don't redesign anything to get them.

Disadvantages

No free tier

Cloudflare has a real, generous free tier. Front Door Standard starts at roughly $35/month base, plus per-request and per-GB charges. For a project that just wants apex SSL and basic CDN, Cloudflare wins on price by a wide margin.

Premium tier jumps hard

If you need managed WAF rule sets, Private Link to origin, or bot management, you need Premium — which jumps to roughly $330/month base. Most projects don't need this.

Per-request pricing means traffic spikes hurt

Unlike a flat-tier Cloudflare plan, Front Door charges per million requests. A viral spike or a misbehaving crawler can produce a surprising bill. Set up budget alerts.

Slower configuration changes

Cloudflare changes propagate to their edge in seconds. Front Door's deployment model is fast for most updates (under a minute) but route-rule changes can take a few minutes to settle. Not a dealbreaker, just different from the "instant" model.

Less third-party tooling

Cloudflare has a huge ecosystem of Workers, Pages, R2, integrations. Front Door is a focused edge product — if you want serverless edge compute, you'd pair it with Azure Functions, which is more deployment work than a Cloudflare Worker.

Competitors

Cloudflare

The obvious comparison. Cloudflare is conceptually the same thing — anycast edge, TLS, CDN, WAF, DDoS — and arguably better-known. Cloudflare wins on price (real free tier, predictable flat tiers), ecosystem (Workers, R2, Pages), and how-fast-config-changes-propagate. Front Door wins on Azure-native integration and single-invoice billing. For most early-stage projects, Cloudflare is the right call. For Azure-committed shops at scale, Front Door is often the right call.

AWS CloudFront

Amazon's equivalent. If your app is on AWS, CloudFront is the default — same single-invoice argument. If your app is on Azure, putting CloudFront in front means you're paying AWS for cross-cloud egress on every cache miss, which gets expensive fast. Use the edge in the cloud your origin lives in.

Fastly

Edge specialist. Strongest on cache configurability (their VCL config language is very expressive) and developer experience around edge compute. Pricing model is closer to AWS/Azure than to Cloudflare's flat tiers — pay-as-you-go for requests and bandwidth. Often picked by media and e-commerce companies who care intensely about cache logic. Overkill for most SaaS.

Akamai

The original CDN. Excellent network footprint, deep enterprise relationships, complex pricing. If you're a Fortune 500 with enterprise procurement preferring an enterprise vendor, Akamai is on the shortlist. Otherwise not the first choice for new builds.

Doing nothing — App Service alone

Worth naming. Azure App Service has built-in TLS, custom domain binding, and even a managed cert for free. If you're single-region, low traffic, no apex domain requirements, and no WAF need — you genuinely may not need any edge layer. The line where Front Door becomes worth it is usually: multi-region users or apex custom domains for customers or a WAF requirement.

Settings that matter

Here's the concrete walkthrough for putting Front Door in front of a typical single-region Azure App Service. The exact UI labels in the Azure portal shift over time — treat these as the conceptual settings to look for, and check the official Microsoft documentation for the current portal flow.

1. Profile and endpoint

A Front Door profile is the management container. An endpoint within it is the public-facing hostname clients reach.

You can upgrade Standard → Premium later without losing state, so default to Standard.

2. Origin group

The origin group holds one or more origin servers behind a single virtual destination.

The "origin host header" matters more than the UI suggests. By default, Front Door forwards whatever Host header the client sent. Azure App Service does strict hostname validation — if the request arrives with Host: yourapp-abc.z01.azurefd.net, App Service has never heard of that hostname and returns a generic 404 "Web App not found." Setting an explicit origin host header overrides this on every request to the origin, so App Service always sees a hostname it recognizes.

Meanwhile, the original Host header — the one the user actually typed — is preserved in X-Forwarded-Host, which your app code reads to know what hostname the request came in on. See Microsoft's origin host header docs for the canonical reference.

3. Route

The route binds the endpoint to the origin group with rules about what gets forwarded.

Be careful with caching. Any app that mixes public and authenticated routes risks blanket caching serving a logged-in user's dashboard to an anonymous visitor — a catastrophic, hard-to-debug failure mode. The safe path is to enable caching per route, starting with known-static paths (/css/*, /js/*, /images/*) and only graduating to public HTML once you're confident every authenticated route sends Cache-Control: no-store.

Compression is safe to leave on globally — it just gzips/brotlis the response, no correctness risk.

4. Code: trust the forwarded headers

When Front Door fronts a request, your app sees:

Host: yourapp.azurewebsites.net    (because we set the origin host header)
X-Forwarded-Host: customer.com     (the real customer-facing hostname)
X-Forwarded-Proto: https
X-Forwarded-For: <client IP>

If your code reads Request.Host directly (as ASP.NET Core does by default), it now sees the App Service hostname instead of the customer-facing one. Three lines fix this in Program.cs:

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor
                             | ForwardedHeaders.XForwardedProto
                             | ForwardedHeaders.XForwardedHost;
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

// And early in the request pipeline:
app.UseForwardedHeaders();

Clearing KnownNetworks and KnownProxies tells ASP.NET Core to trust all upstream proxies. In production you should narrow this to Microsoft's published IP ranges, but it's a fine starting point once the origin is locked down to only accept Front Door traffic (next step).

5. Lock down the origin

Front Door doesn't enforce that traffic to your App Service only comes via Front Door — App Service is still publicly reachable at its *.azurewebsites.net hostname unless you tell Azure otherwise. Two layers to lock this:

• Access Restrictions on App Service: add an allow rule for the service tag AzureFrontDoor.Backend, then a deny-all rule below. Now App Service only accepts inbound traffic from any Front Door instance.
• X-Azure-FDID header check: every Front Door profile has a unique ID Microsoft sends as X-Azure-FDID on every origin request. Add a second allow rule that requires this header to equal your profile's ID. Now App Service only accepts traffic from your Front Door, not someone else's.

Skipping the second check is a real risk — without it, anyone else's Front Door deployment could technically reach your origin (very low practical exploit risk, but the lock costs nothing to add). Microsoft has a step-by-step in Secure traffic to Azure Front Door origins.

6. DNS cutover

The transition from "App Service serves the custom domain directly" to "Front Door fronts it" is a DNS change. Two-step:

1. Lower the TTL on the existing A/CNAME record to 60 seconds. Wait at least 24 hours for the old TTL to expire from resolvers worldwide. This step is boring but critical — it makes the cutover (and any rollback) propagate in a minute instead of hours.
2. Cut over: in Front Door, add the domain as a custom domain, complete the TXT-record ownership challenge, wait for the managed cert to provision (~10 min), then flip the DNS record to point at the Front Door endpoint hostname.

7. Customer apex domains

For a customer-facing apex domain like customer.com:

• A record at apex → one of Front Door's anycast IPs (stable, won't change under you).
• TXT record for ownership challenge.
• In Front Door: register customer.com as a custom domain, wait for the managed cert.
• In your app: bind the hostname so internal routing knows what to do with the incoming request.

The DNS records the customer adds at their registrar are now stable — they're not tied to your App Service's inbound IP. If you ever migrate App Service to a different plan, region, or even cloud, customers' DNS doesn't change.

Things to set up alongside

Worth doing on day one rather than discovering later:

• Access Restrictions on App Service, immediately. Don't wait for "later" — once production traffic is flowing it's harder to switch on without anxiety.
• Budget alert on the Front Door resource. Standard tier is $35 base plus traffic, so a $50/month alert catches anything weird before it becomes expensive.
• Audit every authenticated route's Cache-Control before enabling any caching. Worth doing twice.
• Logs to Log Analytics or Storage. Front Door's diagnostic logs let you see what hit the edge, what got cached, and what got blocked by WAF. Off by default.

Further reading

Pricing, exact UI flows, and product capabilities evolve. The canonical references:

• Azure Front Door documentation (Microsoft Learn)
• Front Door pricing
• Front Door Standard / Premium overview
• Secure traffic to Front Door origins
• Add a custom domain

When to pick it

Azure Front Door is Microsoft's edge-layer product: anycast routing, TLS at the edge, CDN, WAF, DDoS, managed certs, custom domains. It's a strong fit for Azure-hosted apps that need a stable customer-facing hostname (especially for apex SaaS domains), a WAF, or multi-region failover. It's overkill for single-region, no-WAF, low-traffic apps where Cloudflare's free tier or just App Service alone covers you.

The decision tree is short: do you need apex stability, multi-region, or WAF? If yes, Front Door. If no, save the $35.