Azure Front Door Premium vs Application Gateway: Choosing a WAF-Protected Entry Point

You need a layer-7 entry point for an HTTP(S) application, you want a managed web application firewall (WAF), and you want the origin servers shielded from direct internet traffic. Azure offers two managed services that both claim this space: Azure Front Door Premium and Azure Application Gateway (WAF_v2 SKU). They are not interchangeable. The decision hinges on one question first: does your application serve users from more than one Azure region, or is it single-region?

This guide compares the two on supported behavior, walks through the trade-offs, and ends with a concrete validation you can run after deploying either option.

The decision and its constraints

Start by writing down four constraints, because they map directly onto the comparison:

• Geography. Single region or multi-region active-active / active-passive?
• Origin protection. Do origins need to reject any traffic that did not come through the edge service?
• WAF scope. One application, or many frontends that should share a policy?
• Cost shape. Predictable per-hour spend versus per-request and per-GB spend that scales with traffic.

Side-by-side comparison

Capability	Front Door Premium	Application Gateway (WAF_v2)
Scope	Global, anycast edge; users connect to the nearest point of presence	Regional; one deployment per VNet/region
Multi-region failover	Built-in via origin groups with health probes across regions	None natively; requires Front Door or Traffic Manager in front
WAF	Managed rule sets plus custom rules; one policy attachable to many endpoints	Managed rule sets plus custom rules; policy scoped to the gateway or listener
Origin protection	Private Link origins plus the X-Azure-FDID header check	Sits inside your VNet; backends are private by construction
Caching / CDN	Yes, at the edge	No
Cost model	Base fee plus per-request and data transfer; grows with volume	Per-hour capacity units; more predictable at steady high volume
TLS	Managed certificates on custom domains	Managed or Key Vault-referenced certificates

Trade-offs that actually bite

Latency and failover versus simplicity

Front Door's anycast routing terminates TLS at the edge closest to the user, which measurably reduces handshake latency for a geographically spread audience. Origin groups give you health-probe-driven failover between regions without bolting on another service. The cost is operational: failover behavior depends entirely on your probe configuration. A probe interval that is too aggressive can shift traffic to a secondary region during a transient blip; too lenient, and real outages take longer to detect. Decide the probe path (it must exercise the application's real dependencies, not a static 200), interval, and sample count deliberately, and rehearse a region failure before you rely on it.

Application Gateway is the simpler mental model: it lives in your VNet, backends are private IPs, and east-west integration with Azure Firewall or network virtual appliances is straightforward. If your application is single-region and your users are regional, paying for a global edge you do not use buys you nothing.

Shared WAF policy: power and blast radius

Front Door WAF policies can be attached to many endpoints, which is excellent for consistent posture across brands or environments. The flip side is blast radius: a poorly tested custom rule in a shared policy can block legitimate traffic on every attached endpoint at once. Mitigate this by rolling rule changes out in Detection mode (log only) first, reviewing what would have matched, and only then switching to Prevention mode. Application Gateway policies are naturally scoped to one gateway, so the blast radius is smaller but consistency across many gateways becomes your problem.

Cost shape

Front Door Premium charges a base fee plus request volume and data transfer. At high, steady request rates this can exceed the per-hour capacity-unit cost of an equivalently sized Application Gateway. At spiky or modest traffic, the reverse is often true. Model both against your real request counts from existing logs before committing; do not estimate from page views alone, because every static asset is a request.

Concrete validation: prove the origin only answers through Front Door

Whichever service you pick, the origin-protection claim must be verified, not assumed. For Front Door Premium with an App Service origin, the supported pattern is to lock the origin down with Private Link or access restrictions, and have the app check the X-Azure-FDID header against your Front Door profile ID.

After deployment, run these checks from any machine with network access (no Azure permissions needed for the first two):

# 1. Confirm the endpoint resolves to Front Door edge (anycast)
nslookup app.contoso.com

# 2. Direct origin request WITHOUT the header must fail (expect 403)
curl -i https://myapp.azurewebsites.net/

# 3. Through Front Door must succeed (expect 200)
curl -i https://app.contoso.com/

Then verify the WAF actually blocks, using a harmless probe against your own endpoint:

# Expect a 403 with the Front Door WAF block page if prevention mode is on
curl -i "https://app.contoso.com/search?q='%20OR%201=1--"

Check the result in two places: the HTTP status above, and the Front Door WAF logs (FrontDoorWebApplicationFirewallLog category in your Log Analytics workspace), which should show the matched rule ID. If step 2 returns 200, your origin is still publicly reachable and the WAF is decorative — fix the access restriction before anything else. If the SQLi probe returns 200, the policy is still in Detection mode or the managed rule set is not attached to the endpoint.

Limitations to keep in mind

• Front Door is HTTP(S) only; non-HTTP workloads need a different path.
• Application Gateway WAF_v2 autoscaling still caps at regional instance limits; plan capacity for peak, not average.
• Rule-set versions and SKU behavior change over time; confirm against current Azure documentation for your target region before finalizing a design.

The short version: multi-region or globally distributed users point to Front Door Premium; a single-region application with predictable high volume and VNet-native backends points to Application Gateway. Either way, the deployment is not done until you have proven the origin rejects direct traffic and the WAF blocks a known-bad request.