Azure Front Door vs Application Gateway: Which One Do You Need? 

If you’re setting up web applications in Azure, you’ve probably come across both Azure Front Door and Application Gateway.

They’re both Layer 7 services (application layer), they both handle web traffic, and at first glance they look like they do the same thing. But they’re designed for different jobs. So which one should you use?

You might be a developer architecting a new application, an IT lead reviewing your Azure setup, or a business decision-maker trying to understand what your team is proposing.

Whatever you’re looking to do, this article should help you understand what each service does and when it makes sense. We’ll compare features, performance, security, and cost.

Azure Front Door is a global, edge-based entry point for web applications. It runs on Microsoft’s worldwide edge network, with 100+ points of presence spread across the globe. When a user connects to your application through Front Door, they’re routed to the nearest edge location using  Anycast, which means lower latency regardless of where they are.

Front Door combines several capabilities in one service: global load balancing, CDN-style caching, SSL offloading, and  web application firewall (WAF) protection. It’s the same infrastructure Microsoft uses to protect and accelerate its own mega-sized web properties, so it’s built to handle serious scale.

The service comes in two tiers. Standard covers the core functionality: global load balancing, SSL termination, caching, and basic routing. Premium adds the full WAF with managed rulesets, bot protection, and Private Link support for connecting to backends without exposing them to the internet.

Front Door works exclusively with HTTP and HTTPS traffic. If you need to handle other protocols, you’ll need to look elsewhere.

On the other side, we have Application Gateway: a regional  load balancer that lives inside your Azure virtual network. Rather than sitting at Microsoft’s edge, it’s deployed within a specific region, close to your backend services.

Where Application Gateway proves its worth is complex traffic routing. It supports:

• Path-based routing (e.g. sending /api/* to one backend and /images/* to another)
• Host header routing for multi-tenant applications
• Cookie-based session affinity
• Detailed URL rewrite rules

If you need fine-grained control over how requests reach your backends, this is where you get it.

Application Gateway can autoscale up to 125 instances per gateway, which means you can handle substantial traffic volumes within a region. (It also includes optional WAF capabilities for Layer 7 protection.)

A relatively recent addition is support for TCP and TLS proxying, meaning Application Gateway can now handle non-HTTP workloads too. This can make it into a more unified entry point, though it’s worth noting that non-HTTP traffic doesn’t get WAF inspection.

Microsoft offers different tiers here as well. The Basic tier is positioned for dev/test and lower-traffic scenarios, while Standard (specifically Standard_v2) is the production-ready option with autoscaling and zone redundancy. Note that the older v1 SKUs are being retired, so new deployments should use v2.

The fundamental difference comes down to where they sit and what they’re optimised for.

Azure Front Door operates globally at the edge. It’s your first line of defence and acceleration for internet-facing applications, routing users to the nearest healthy backend with minimal latency. Think of it as a global entrance that handles the initial connection before traffic even reaches your Azure regions.

Application Gateway operates regionally inside your VNet. It’s where you implement complex routing logic, integrated tightly with your backend services. It’s how you handle traffic that’s already arrived in your Azure environment.

Both of these services offer web application firewall (WAF) capabilities, but they protect your apps in different ways.

Front Door’s WAF sits at the edge, which means malicious traffic gets blocked before it ever reaches your Azure regions. This is a strong offering when combined with Azure’s built-in network DDoS protections. Front Door can absorb volumetric attacks across its global network, and because it needs valid HTTP/HTTPS with proper headers, it filters out a lot of protocol-abuse attacks automatically. The Premium tier includes managed rulesets from Microsoft, bot protection, and the ability to create custom rules.

Application Gateway’s WAF provides Layer 7 protection within your virtual network. It offers similar managed rulesets and custom rule capabilities, and it’s useful when you need deep inspection of traffic that’s already inside your network perimeter. If you’re using Application Gateway’s newer TCP/TLS proxying for non-HTTP workloads, keep in mind that this traffic bypasses WAF inspection entirely.

For internet-facing applications, there’s a strong argument for using Front Door’s WAF as your first line of defence. It handles threats at the edge before they consume resources in your Azure regions. Application Gateway’s WAF then provides defence in depth for traffic that makes it through, or protection for internal traffic that never touches Front Door.

If you’re building a resilient Azure environment, layering these protections is definitely worth considering.

Neither service is without constraints, and it’s worth thinking about these before you commit to an architecture.

Azure Front Door limitations:

• HTTP/HTTPS only, so no raw TCP traffic or non-web protocols
• Endpoint limits vary by tier (up to 500 per profile), with caps on custom domains, routing rules, and security policies
• Caching behaviour needs careful configuration for highly dynamic content
• Adds less value if all your backends are in a single region, since you’re not using the global load balancing

Application Gateway limitations:

• Regional only, so no built-in global routing or edge presence
• WAF inspection doesn’t apply to TCP/TLS traffic, only HTTP/HTTPS
• More complex to configure than Front Door for straightforward use cases
• Capacity planning matters: you’re paying for capacity units, and underprovisioning can cause issues during traffic spikes

Front Door makes the most sense when you’re serving users globally and latency matters.

If your application has users across Europe, the Americas, and Asia-Pacific, Front Door’s edge network makes sure that everyone gets a fast connection to the nearest point of presence.

It’s also the right choice when you need edge-based protection for internet-facing applications. DDoS attacks get absorbed at the edge rather than hitting your Azure resources, and the WAF filters malicious requests before they cost you that precious compute.

Multi-region deployments benefit quite a lot from Front Door. It handles health monitoring of your backends and automatic failover, so if one region goes down, traffic shifts to healthy regions without manual intervention.

If you need CDN-like caching for static content alongside your dynamic application, Front Door combines both capabilities in a single service. You’re not managing a separate CDN configuration.

Application Gateway is the better fit when your application lives entirely within a single Azure region and needs complex routing logic. Path-based routing, session affinity, and detailed URL manipulation are all Application Gateway’s strengths.

If you have workloads that aren’t HTTP-based, Application Gateway’s TCP and TLS proxying fills a gap that Front Door can’t address. This makes it useful as a unified entry point for mixed workloads.

Applications that need tight integration with VNet resources often work better with Application Gateway. It can connect directly to backends using private IPs and integrate with Azure Kubernetes Service ingress. It can also work with other regional services without traffic leaving your network.

For purely internal applications that don’t face the internet, Application Gateway handles the load balancing without the overhead of a global edge service you don’t need.

Surely using both would be quite an indulgence, no?

Well, Front Door and Application Gateway aren’t mutually exclusive. A common pattern is using Front Door at the edge with Application Gateway inside each region.

In this architecture, Front Door handles global routing, edge caching, and the first layer of WAF protection. It routes users to the nearest healthy region and absorbs attacks at the edge. Traffic then arrives at Application Gateway in the relevant region, where complex routing rules direct requests to the right backend services.

This gives you the best of both: global reach and protection from Front Door, plus sophisticated per-region routing from Application Gateway. It’s more complex to set up and adds cost, but for large-scale applications serving global users with complex backend architectures, it’s a powerful combo.

Azure has several load balancing and traffic management options you should be aware of.

Azure Load Balancer is a Layer 4 (transport) service. It routes traffic based on IP address and port, with no awareness of HTTP content. Use it for non-HTTP workloads, internal load balancing within a VNet, or scenarios where you need high throughput without Layer 7 processing overhead. It’s not a substitute for Front Door or Application Gateway when you need HTTP-aware routing.

Azure Traffic Manager is DNS-based traffic routing. It doesn’t sit inline with your traffic; instead, it resolves DNS queries to direct users to different endpoints based on routing rules (geographic, performance, priority, or weighted). Traffic Manager adds some latency because of the DNS lookup, and it can’t do real-time failover as quickly as Front Door. It’s useful for simple multi-region routing without Front Door’s edge capabilities, but Front Door has largely superseded it for HTTP workloads.

(If you’re planning a move to Azure and trying to work out which networking components you need, our toolkit for Azure migration covers the broader planning considerations.)

Neither service is straightforward to price, and neither is categorically cheaper than the other. Your costs depend heavily on traffic patterns, data volumes, and which features you switch on.

Front Door pricing includes a base monthly fee (higher for Premium), per-request charges that vary by request type, outbound data transfer costs, and additional charges if you enable WAF policies or custom rules. The Standard tier starts around £26/month base, while Premium is closer to £260/month before you add traffic costs.

Application Gateway pricing works on capacity units, which combine compute, connections, and throughput into a single measure. You pay for the capacity units you consume, plus data processing charges. WAF adds its own costs on top. A basic deployment might run £50-100/month, but busy production workloads can cost significantly more.

Simply put, you’ll need to model your traffic estimates to get meaningful numbers.

Both options can be weighed up using the pricing calculators linked above, and it’s worth running the numbers for your expected request volumes and data transfer. (For a broader look at keeping Azure spending under control, our guide to Azure cost management covers the strategies that actually work.)

While Front Door is well-integrated with the Azure ecosystem, third-party CDN and edge services can also sit in front of Azure workloads.

Cloudflare offers a comprehensive edge platform with CDN, DDoS protection, and WAF. It’s platform-agnostic, so it works well if you’re running multi-cloud or want to avoid Azure lock-in for your edge layer. Cloudflare’s free tier is definitely useful for smaller sites.

Akamai and Fastly are enterprise-grade CDN providers with extensive edge networks. They’re worth considering if you have specific edge computing requirements or existing relationships with these vendors.

The trade-off with third-party options like these is integration. Front Door works natively with Azure monitoring, fits into Azure Policy for compliance, and can use Private Link to connect to backends without exposing them publicly. Third-party CDNs take more setup to achieve similar integration, and you’re managing another vendor relationship.

For most organisations already committed to Azure, Front Door’s native integration will probably outweigh the benefits of going third-party.

Hopefully the choice is a bit clearer now. Here are a few questions to ask to steer your decision:

• Where are your users? If they’re concentrated in one geography and your application runs in a nearby Azure region, Application Gateway might be all you need. If you’re serving users globally, Front Door’s edge network delivers noticeable latency improvements.
• How complex is your routing? Simple global load balancing with health checks are a good fit for Front Door. Complex path-based routing, session affinity, and URL manipulation are Application Gateway’s strengths.
• What’s your security posture? Internet-facing applications benefit from Front Door’s edge WAF and DDoS absorption. Internal applications or those with other perimeter security might not need it.
• What about the budget? Neither service is expensive for modest traffic, but costs scale differently. Model your expected traffic through both pricing calculators.

At Synextra, we help organisations across the UK design and implement Azure architectures that fit their needs perfectly. If you’d like to talk through what makes sense for your situation, get in touch. We’re always happy to help.