Architecture Comparison
Azure Application Gateway vs Azure Front Door: Layer 7 Load Balancing, WAF, Routing, and Use Cases
Both are Layer 7 load balancers with a WAF option. That's roughly where the similarity ends. One lives at Microsoft's global edge and never enters your virtual network by default; the other lives inside your VNet in one specific region and never leaves it. The real question isn't "which is better" — it's whether your architecture needs global entry, regional entry, or — increasingly the right answer — both, layered together.
Both Azure Application Gateway and Azure Front Door inspect and route HTTP/HTTPS traffic at Layer 7, both offer a WAF option, and both get reached for in almost the same breath during an architecture conversation — which is exactly why they get compared as if they're competing for the same job. They aren't, most of the time. Front Door is Microsoft's global edge service: traffic enters at whichever of 300+ edge locations is closest to the user, gets inspected and routed there, and only reaches your actual infrastructure after that global decision has already been made. Application Gateway is a regional service living inside a specific virtual network in a specific Azure region — traffic has to reach that region first before Application Gateway ever sees it. The comparison that actually matters isn't which one wins in the abstract; it's whether your architecture needs a global entry point, a regional one, or — increasingly the pattern Microsoft's own guidance converges on — both, doing different jobs in the same request path.
Before any feature comparison, the scope difference is the one fact that resolves most of this decision on its own.
| Aspect | Azure Front Door | Azure Application Gateway |
|---|---|---|
| Deployment scope | Global — Microsoft's edge network, 300+ locations | Regional — one specific Azure region |
| VNet presence | Not inside your VNet by default (Premium adds Private Link to origins) | Native — lives inside your virtual network |
| Multi-region routing | Native — automatic failover, latency-based routing across regions | Not native — requires one deployment per region plus Traffic Manager |
| Internal/private-only deployment | Not the default model — designed for public-facing entry | Supported — can be deployed as a fully internal load balancer |
| Protocol support | HTTP/HTTPS only | HTTP(S), plus newer TCP/TLS proxying for non-HTTP workloads |
A single-region application with no public internet exposure requirement, needing routing and WAF entirely within one VNet, plays directly to Application Gateway's strengths — native VNet integration and internal load balancer support are exactly what that scenario needs, and Front Door's global distribution capability goes largely unused. Conversely, a public-facing, multi-region application benefits directly from Front Door's native cross-region routing and edge presence, which Application Gateway alone structurally cannot provide.
With Classic being phased out, the live decision for any new Front Door deployment is Standard versus Premium — and current guidance is unusually clear about what actually drives that choice.
| Capability | Standard | Premium |
|---|---|---|
| Global load balancing, SSL termination, caching | Included | Included |
| Custom WAF rules | Included | Included |
| Managed WAF rule sets (OWASP CRS) | Not included | Included, at no separate charge |
| Bot protection / Bot Manager | Not included | Included |
| Private Link to origins | Not supported | Supported |
| Base monthly fee (illustrative) | ~$35/month | ~$330/month |
Multiple current sources frame the Standard-vs-Premium decision the same precise way: it increasingly comes down to one question — do you need Private Link to your origins? Private Link lets Front Door reach your backend over a private connection rather than requiring a publicly-reachable origin, which removes the public backend exposure that older, Classic-era deployments required by design. If your origins can or must remain fully private, Premium isn't optional — it's the only tier that supports the connectivity model your architecture needs.
The base monthly fee is only one part of the cost. Front Door billing also includes charges for incoming requests, outbound data transfer from the edge to clients, and outbound data transfer from origins to the edge — all four meters matter for a realistic cost estimate, and outbound data transfer rates vary meaningfully by geographic zone. A cost comparison based on base fee alone will understate real spend for any application with genuine traffic volume.
Application Gateway's core identity is being a regional load balancer that lives inside your virtual network, close to your backend services — the opposite positioning from Front Door's edge model, and genuinely complementary rather than redundant.
- Native VNet integration. Application Gateway is deployed directly into a subnet within your virtual network, with full awareness of your private address space.
- Can be internal-only. Deployable as an internal load balancer with no public-facing endpoint at all — a capability Front Door doesn't offer as its primary model.
- WAF_v2 SKU. A mature, feature-rich WAF supporting the same OWASP managed rule sets and custom rules as Front Door's WAF, but evaluated in-region rather than at the edge.
- Newer TCP/TLS proxying. For non-HTTP workloads, Application Gateway can proxy at the TCP/TLS layer — but this traffic bypasses WAF inspection entirely, a specific, documented limitation worth knowing before relying on it for anything security-sensitive.
- Capacity-unit-based pricing. Compute, connections, and throughput combine into a single capacity-unit measure, billed alongside a fixed hourly gateway cost.
If a workload uses Application Gateway's TCP/TLS proxying capability specifically because it needs to handle non-HTTP traffic, it's important to understand explicitly that this traffic receives no WAF inspection at all — the WAF only evaluates HTTP(S) traffic processed through Application Gateway's standard Layer 7 path. A team assuming "we have a WAF attached to this gateway, so everything passing through it is inspected" will be wrong specifically for TCP/TLS-proxied traffic, and should plan additional protection for that traffic class if security inspection is required.
Both WAF options protect against the same class of threats — OWASP Top 10 vulnerabilities, common injection and cross-site scripting patterns — using managed rule sets that are functionally similar. The meaningful difference is where the inspection actually happens, and what that location implies for your infrastructure.
| Aspect | Front Door WAF (Premium) | Application Gateway WAF_v2 |
|---|---|---|
| Inspection location | Microsoft's global edge — before traffic reaches Azure at all | In-region — traffic has already arrived at your Azure infrastructure |
| Malicious traffic impact on backend | Zero — blocked before it ever reaches your network | Traffic reaches the region and Application Gateway before being blocked |
| Bot protection | Bot Manager included | Not a native equivalent feature |
| Rule set version (illustrative) | OWASP CRS 3.2, with JS Challenge for bot mitigation | OWASP CRS, mature and well-established |
| Integration depth | Feeds edge-level analytics, bot classification details | Integrates more deeply with regional security services |
Because Front Door's WAF evaluates traffic before it ever reaches Azure, malicious requests never consume any of your backend's compute, network, or Application Gateway capacity at all — they're stopped at the edge, globally distributed across Microsoft's network rather than concentrated against your specific regional infrastructure. This is a genuine resilience benefit beyond just "the WAF is closer to the user" — a volumetric attack or scraping campaign hits Front Door's edge capacity, not your application's.
Using Front Door's edge WAF for the first layer of filtering and Application Gateway's WAF for a second, in-region layer isn't redundant paranoia — it's the same defense-in-depth logic that applies to any layered security architecture. Front Door's WAF handles broad, edge-appropriate filtering (bot traffic, common injection patterns, geo-based rules) while Application Gateway's WAF can carry more application-specific custom rules tuned to the specific backend it protects. Section 6 covers the combined architecture this naturally produces.
| Routing capability | Front Door | Application Gateway |
|---|---|---|
| Path-based routing | Yes | Yes |
| Multi-site (host header-based) routing | Yes | Yes |
| Latency-based routing across regions | Yes, native | No — requires Traffic Manager |
| Automatic regional failover | Yes, native, via origin health probes | No — Application Gateway itself has no cross-region awareness |
| URL rewrite / redirect | Yes | Yes |
| Session affinity | Yes | Yes |
| Caching (CDN function) | Yes, native — static content cached at edge locations | No native CDN caching function |
| HTTP/2 and HTTP/3 (QUIC) | Yes (Premium) | HTTP/2 supported; check current HTTP/3 status for your SKU |
Because Front Door caches static content at edge locations as a built-in function, many architectures that would previously have used a separate CDN product alongside their load balancer can consolidate that function into Front Door directly. This is part of why Azure's standalone CDN product has increasingly narrowed to legacy scenarios — Front Door's Standard and Premium tiers now cover the combined load-balancing-plus-CDN use case that used to require two separate services.
The most consistently cited pattern in current architectural guidance isn't "choose Front Door or Application Gateway" — it's using both together, each doing the job it's actually built for, connected privately end to end.
- Tier 1 — Front Door Premium. The global edge layer, receiving all incoming traffic, applying edge WAF and bot protection, and routing to the nearest healthy region based on latency and health probe status.
- Tier 2 — Application Gateway, one per region. Each region's Application Gateway is registered as a distinct Front Door origin, connected via Private Link so it has no public-facing endpoint at all. It performs in-region Layer 7 routing and a second WAF inspection pass tuned to that specific region's backend.
- Tier 3 — Backends. AKS clusters, VMs, or App Services, reached only through their region's Application Gateway — never directly exposed.
This three-tier pattern is explicitly described in current guidance as delivering enterprise-grade reliability and security — but the combined bill (Front Door Premium plus Application Gateway WAF_v2 multiplied by the number of regions) is real, running into significant monthly spend for genuine production traffic volumes. This architecture is worth its cost specifically for public-facing, multi-region, security-sensitive applications; it's meaningful over-engineering for a single-region internal application that never needed Front Door's global capability in the first place.
Layering Front Door and Application Gateway is a legitimate pattern, but current guidance is explicit that it's worth confirming you genuinely need both layers before committing to the combined cost. For a single-region, moderate-traffic application, Application Gateway alone is often meaningfully cheaper and simpler — Front Door's base fee plus per-request charges can exceed a straightforward Application Gateway deployment for workloads that never needed global distribution to begin with. Reserve the full combined architecture for the specific case it's built for: genuinely global, multi-region, public-facing, security-sensitive applications.
The two services price on genuinely different axes, which makes a fair, apples-to-apples comparison harder than it first appears.
| Service | Pricing model | Illustrative example |
|---|---|---|
| Front Door Standard | Base fee + per-request + outbound data transfer | ~$35/month base, plus usage — custom WAF rules included, no managed rule set |
| Front Door Premium | Higher base fee, WAF and Private Link bundled in | ~$330/month base, plus usage — managed + custom WAF rules included, no separate WAF charge |
| Application Gateway (Standard_v2) | Fixed hourly gateway cost + capacity units (compute, connections, throughput combined) | Variable — model against your actual traffic; a basic deployment can run notably less than Front Door Premium for single-region use |
| Application Gateway WAF_v2 | Adds WAF cost on top of base Application Gateway pricing | Illustrative: roughly $0.44/gateway-hour + $0.014/capacity-unit-hour — verify current rates for your region |
| Scenario | Typically cheaper option |
|---|---|
| Single-region, moderate traffic, no global distribution need | Application Gateway alone — simpler and usually more cost-effective |
| Multi-region, public-facing, needs global routing | Front Door — one resource vs. multiple regional Application Gateways plus Traffic Manager |
| Static-content-heavy sites migrating off legacy CDN | Front Door Standard — reported up to 45% cheaper than Front Door Classic for static workloads |
| Full three-tier combined architecture | Neither — genuinely additive cost, justified only when both layers' capabilities are actually needed |
Because Application Gateway is inherently regional, a multi-region deployment using it as the sole entry point requires one full Application Gateway (plus WAF, if used) per region — the cost multiplies directly with region count, on top of needing Traffic Manager for the cross-region routing Application Gateway itself doesn't provide. Front Door's single global resource model avoids this multiplication for the edge/routing layer specifically, even though the combined architecture in Section 6 still deploys Application Gateway per region for its in-region role.
| Your situation | Recommended approach |
|---|---|
| Public-facing, single-region application | Application Gateway with WAF_v2 — Front Door's global distribution goes unused |
| Public-facing, multi-region application | Front Door (Standard or Premium depending on WAF/Private Link needs) — native cross-region routing |
| Internal-only application, no public exposure | Application Gateway as an internal load balancer — this is exactly its native model |
| Backends must remain fully private, no public IP anywhere | Front Door Premium (Private Link to origins) — Standard tier can't do this |
| Non-HTTP protocol requirements | Application Gateway's TCP/TLS proxying — Front Door is HTTP/HTTPS only, full stop |
| Public-facing, multi-region, high security/compliance requirements | The combined three-tier architecture (Section 6) — worth the additive cost here specifically |
| Static-content-heavy site, minimal dynamic backend logic | Front Door Standard — its built-in caching largely replaces a separate CDN |
If there's one heuristic worth defaulting to: applications with genuine public internet exposure benefit from Front Door's edge presence, DDoS absorption, and global routing almost by default, while applications confined to internal, VNet-only traffic get little from Front Door and are well served by Application Gateway alone. The exception is the combined architecture — reserved for public-facing applications where the added security and reliability from a second, in-region WAF layer justifies genuinely additive cost.
Determine public-facing vs internal-only, and single-region vs multi-region
These two questions, combined, resolve the large majority of the decision per Section 8's framework — work through them explicitly before evaluating specific features.
If Front Door: determine whether you need Private Link to origins
This single question, per current guidance, is the most reliable way to resolve Standard vs Premium — if your origins can or must stay fully private, Premium is required, not optional.
If Application Gateway: confirm HTTP(S) covers your protocol needs, or plan explicitly for TCP/TLS proxy's WAF gap
If non-HTTP protocols are required, confirm you understand and accept that TCP/TLS-proxied traffic bypasses WAF inspection, and plan supplementary protection if that traffic is security-sensitive.
Model the actual multi-meter cost for your real traffic volume, not just base fees
For Front Door, include request volume and outbound data transfer by geographic zone. For Application Gateway, include capacity-unit consumption under realistic load, not idle-state estimates.
For public-facing, multi-region, security-sensitive applications, evaluate the combined architecture explicitly
Model the full combined cost (Front Door Premium plus Application Gateway WAF_v2 per region) against the specific security and reliability benefit before committing — this is the right pattern for the right workload, not a default upgrade.
If deploying Application Gateway as an origin behind Front Door, configure Private Link explicitly
Don't leave Application Gateway with a public endpoint "just in case" — the whole point of the combined pattern is removing public exposure at every hop except Front Door's own edge presence.
Configure WAF policies deliberately at each layer, not identically duplicated
Use Front Door's edge WAF for broad, edge-appropriate filtering (bot traffic, geo-rules, common patterns) and tune Application Gateway's WAF with application-specific custom rules for that region's backend — layered, not redundant.
| Anti-pattern | Why it feels right | Why it isn't |
|---|---|---|
| Deploying the full combined three-tier architecture for a single-region internal app | "More layers, more security" | Genuinely additive cost for capability (global edge distribution) the workload never uses — Application Gateway alone is the right-sized answer |
| Choosing Front Door Standard for an architecture that needs Private Link | "Standard covers the basics we need" | Private Link to origins is Premium-only — Standard structurally cannot deliver a fully private backend connection |
| Assuming Application Gateway's WAF covers TCP/TLS-proxied traffic | "We have a WAF attached to the gateway" | TCP/TLS proxy mode bypasses WAF inspection entirely — a documented, specific gap, not an edge case |
| Building multi-region routing entirely on Application Gateway plus manual DNS | "We'll just point DNS at whichever region we want" | Recreates, manually and less reliably, what Front Door or Traffic Manager provide natively — health-aware, automatic regional failover |
| Referencing "Front Door Classic" configuration guidance for a new deployment | "Older tutorials still describe it this way" | Classic stopped accepting new profiles March 2025 and retires fully March 2027 — any new deployment should target Standard or Premium |
| Duplicating identical WAF rules at both the Front Door and Application Gateway layers | "Consistency across layers seems safer" | Wastes the opportunity for genuinely layered, complementary rule sets — edge-appropriate broad rules at Front Door, application-specific tuning at Application Gateway |
Key Takeaways
Frequently Asked Questions
Related FAVRITE Articles
- Hub-and-Spoke vs Azure Virtual WAN: Which Network Architecture Wins?
- Slashing Latency: Deploying an Azure Cache for Redis Gateway in Front of Your LLM Endpoints
- Enterprise Network Segmentation in Azure: Architecture Patterns That Actually Scale
- Designing a Multi-Region Azure Architecture for High Availability and Disaster Recovery