Azure Front Door vs Application Gateway

An online retailer adds a second Azure region after a holiday outage. The team already has Application Gateway, so it expects automatic cross-region recovery. During testing, however, customers still reach the failed region because the gateway only handles traffic within its regional deployment.

The decision between Azure Front Door vs Application Gateway comes down to where traffic enters your application and what must happen next. Front Door handles global web entry, acceleration, and cross-region routing. Application Gateway handles regional application delivery with direct virtual network integration.

This comparison explains when to choose either service, when combining them makes sense, and how to validate security, availability, performance, and cost before deployment.

Azure Front Door vs Application Gateway: The Main Differences

Choose Azure Front Door for an internet-facing application that needs global routing, edge caching, or a common entry point across regions. Choose Application Gateway when the main requirement is regional web routing to applications reached through Azure virtual networks. Use both only when the regional gateway adds a capability your application needs.

Both services act as reverse proxies: they receive client requests and forward them to backend applications. Both understand application-layer traffic, including hostnames and URL paths. Their scopes are different.

An origin is the application endpoint Front Door forwards requests to. Application Gateway uses backend pools to identify its destination servers or services.

For new deployments, evaluate Front Door Standard or Premium and Application Gateway Standard_v2 or WAF_v2. Application Gateway v1 retired on April 28, 2026; old deployment examples should not guide a new architecture.

Pro Tip: I start with two questions: “Are the users on the public internet?” and “Does routing need to cross regions?” Those answers usually narrow the design faster than a feature checklist.

How Azure Front Door Handles Global Web Traffic

Front Door gives customers a public entry point on Microsoft’s distributed edge network. An edge location is an entry location closer to users than your application’s hosting region might be.

A typical request follows this path:

1. A customer requests your website.
2. Front Door accepts the connection at an edge location.
3. Routing rules select the appropriate origin group.
4. Origin health, priority, weight, and latency influence origin selection.
5. Front Door forwards the request or serves an eligible cached response.

An origin group contains endpoints that can serve the same application workload. For example, a retailer might configure application deployments in East US and West US as members of one origin group.

Front Door does not make an application multi-region by itself. Each region still needs adequate application capacity, configuration, dependencies, and access to appropriate data.

Where caching helps

Caching stores reusable responses at the edge. Product images, versioned JavaScript, and public style sheets are strong candidates because many users request identical content.

Personalized account pages and authenticated API responses need more caution. Define cache behavior explicitly, including query-string handling and application response headers. A cache hit improves performance only when serving that response to another requester is correct.

For an application hosted on App Service, Front Door can often route directly to the app without an intermediate gateway. Review the underlying Azure App Service architecture before adding another proxy.

Pro Tip: I establish separate routing and caching rules for public assets and authenticated traffic. One broad caching rule can turn a performance improvement into a data-exposure incident.

How Application Gateway Handles Regional Application Traffic

Application Gateway runs in a dedicated subnet inside an Azure virtual network. A virtual network provides private addressing and connectivity for Azure resources.

Its main configuration elements work together:

• A listener accepts traffic for a frontend address, port, protocol, and hostname.
• A routing rule connects the listener to a backend destination.
• A backend pool identifies application endpoints.
• Backend settings define protocol, port, hostname handling, and related behavior.
• Health probes determine whether individual backends can receive requests.

For example, a regional business application might route /orders to one backend pool and /reports to another. The application servers can remain privately addressed.

A private frontend also supports internal web applications reached through approved private connectivity. Employees might connect through a corporate network, VPN, or ExpressRoute rather than an internet-facing endpoint.

Application Gateway does not provide an edge content cache. Placing it in front of an application does not automatically accelerate static assets for distant users.

Its network placement also creates operational responsibilities. Subnet sizing, network security groups, routing, DNS resolution, and backend reachability must support the intended configuration. A network security group controls allowed network traffic; it does not replace application authentication.

Pro Tip: I sketch the frontend and backend network paths separately. A working public listener does not prove the gateway can resolve or reach its private backends.

Azure Front Door vs Application Gateway: Choose by Workload

The strongest architecture is the simplest one that meets the actual requirement.

Global website or public API

Choose Front Door when users connect from different geographic areas and the application needs global routing, edge security, or caching.

For a SaaS platform with independent deployments in two regions, Front Door can direct requests toward healthy origins. That design still requires a strategy for tenant data, sessions, background processing, and regional capacity.

Single-region application with private backends

Choose Application Gateway when the application needs regional Layer 7 routing and virtual network integration. Layer 7 refers to application-aware decisions, such as selecting a destination by hostname or path.

A regional customer portal on private virtual machines is a common fit. Add Front Door only if global entry, caching, or another edge requirement justifies it.

Internal employee application

A private Application Gateway frontend is generally the better fit when the application must remain privately reachable.

Front Door Premium can connect privately to supported origins, but that does not make its customer-facing endpoint a private corporate endpoint. Private origin connectivity and private user access are different requirements.

Global application with regional ingress

Combining the services can be appropriate:

Internet users
    → Azure Front Door
    → Application Gateway in each region
    → Private application backends

This design makes sense when each region needs its own gateway for backend routing, private application access, or regional policy enforcement.

It is unnecessary when Front Door can reach the application directly and the regional gateway contributes no distinct value.

Pro Tip: I require a written reason for every proxy in the request path. “Another security layer” is not enough without an owner, policy, and measurable purpose.

Secure the Edge, Origins, and Management Plane

A web application firewall, or WAF, inspects HTTP requests for suspicious patterns and applies allow, block, or other configured actions. It does not replace identity checks or secure application code.

Front Door Standard supports custom WAF rules. Premium provides the broader managed WAF capabilities, including managed rule sets. Application Gateway requires WAF_v2 for its WAF capabilities.

Start policy evaluation in detection mode where appropriate, inspect legitimate traffic, then move to prevention after tuning. Avoid broad exclusions just to silence false positives.

Prevent direct origin bypass

A protected frontend is insufficient if attackers can reach the backend directly.

For supported origins, Front Door Premium Private Link provides private origin connectivity. A private endpoint is a network interface that makes a supported service privately reachable. Confirm the supported origin type and Private Link location before designing around it.

Current Front Door Premium support includes private connectivity to Application Gateway through its supported integration. Configure the gateway’s Private Link settings, create the Front Door origin connection, approve the pending request, and validate routing before restricting other access.

For public origins, combine network restrictions with validation of your Front Door profile’s X-Azure-FDID header. The AzureFrontDoor.Backend service tag identifies Front Door backend traffic, but the header helps distinguish your profile from other profiles. Neither a freely spoofable header alone nor a broad IP allow rule provides the complete boundary.

Use these controls carefully:

• Restrict origin access to the intended path.
• Reject unexpected hostnames.
• Retain necessary health-probe access.
• Confirm that direct origin requests fail.

Protect certificates and administrative access

Transport Layer Security, or TLS, encrypts connections. Configure HTTPS from clients to the entry service and from proxies to origins. Validate backend certificate names and trust chains rather than bypassing checks.

Use Azure Key Vault for supported certificate integrations and unavoidable secrets. A managed identity lets a service authenticate without an embedded password. Grant only the certificate or secret permissions required by the integration.

Apply Azure RBAC to administrative access. Role-based access control assigns permissions through scoped roles rather than shared administrator accou