Azure Front Door: Global Load Balancing & WAF in One Service

What Is Azure Front Door?

Azure Front Door (AFD) is Microsoft's global HTTP/HTTPS load balancer and CDN, operating at Layer 7 of the network stack. Unlike a classic load balancer that routes traffic within a single region, Front Door routes traffic across regions based on latency, health, and routing rules — all from Microsoft's global edge network (200+ PoPs).

The key insight: Front Door doesn't run in a single Azure region. It runs on Microsoft's global edge — the same backbone that powers Azure CDN, Teams, and Office 365. Your traffic is accelerated globally before it ever reaches your origin servers.

Architecture Overview

Here's how a typical Front Door architecture looks for a multi-region Azure application:

Standard vs. Premium Tier — The Trade-off

Front Door has two tiers (as of the Standard/Premium rebranding). This is a real architectural decision with cost implications:

Standard Tier (~$35/month base + traffic)

• CDN + global load balancing + custom domains + SSL
• Basic WAF (managed rule sets only)
• Good for most production workloads

Premium Tier (~$330/month base + traffic)

• Everything in Standard, plus:
• Private Link origin — connect to App Services, Storage, AKS with no public IP exposure
• Bot protection — Microsoft Bot Manager rule set
• Security reports and advanced threat analytics
• Required if your origins must be private (zero public IP)

WAF Configuration — What Actually Matters

The Web Application Firewall in Front Door gives you two layers of defense:

1. Managed Rule Sets (DRS 2.0)

Microsoft's Default Rule Set covers OWASP Top 10 — SQL injection, XSS, path traversal, and more. Enable this on every WAF policy. The question is whether to run in Detection or Prevention mode.

• Detection mode: logs violations, doesn't block. Use during initial deployment to tune rules.
• Prevention mode: actively blocks. Switch to this once you've confirmed no false positives.

2. Custom Rules

Custom rules let you block/allow based on IP ranges, geo-location, request headers, and rate limits. Common patterns I implement:

• Block all traffic from high-risk geographies the app doesn't serve
• Rate limit by IP: max 100 requests/minute to login endpoints
• Allow-list your own IPs for admin paths (/admin/*)
• Block requests without a valid User-Agent header (catches basic scrapers)

# Example: Bicep snippet for AFD WAF Policy with custom rate limit rule
resource wafPolicy 'Microsoft.Network/FrontDoorWebApplicationFirewallPolicies@2022-05-01' = {
  name: 'wafPolicyProd'
  location: 'global'
  sku: { name: 'Standard_AzureFrontDoor' }
  properties: {
    policySettings: {
      mode: 'Prevention'
      enabledState: 'Enabled'
    }
    managedRules: {
      managedRuleSets: [
        { ruleSetType: 'Microsoft_DefaultRuleSet', ruleSetVersion: '2.1' }
        { ruleSetType: 'Microsoft_BotManagerRuleSet', ruleSetVersion: '1.0' }
      ]
    }
    customRules: {
      rules: [
        {
          name: 'RateLimitLogin'
          priority: 100
          ruleType: 'RateLimitRule'
          rateLimitThreshold: 100
          rateLimitDurationInMinutes: 1
          action: 'Block'
          matchConditions: [
            {
              matchVariable: 'RequestUri'
              operator: 'Contains'
              matchValue: ['/auth/login']
            }
          ]
        }
      ]
    }
  }
}

Securing Origins — No Public IP Exposure

A common mistake is deploying Front Door but leaving origin App Services or AKS clusters publicly accessible. This bypasses WAF entirely. Two approaches to lock this down:

Standard Tier: IP Restriction + AFD Service Tag

In App Service, restrict inbound traffic to the AzureFrontDoor.Backend service tag. This allows only AFD egress IPs. Also validate the X-Azure-FDID header in your app to ensure requests are from your specific Front Door instance (not someone else's AFD pointing at you).

Premium Tier: Private Link (Zero Public IP)

With Premium, you can configure AFD to route to App Services, Internal Load Balancers, or Storage via Private Link. Origins have no public IP. This is the gold standard for security-critical workloads.

Routing Patterns

Front Door supports powerful routing rules. The ones I use most in production:

• Latency-based routing: send users to the fastest healthy origin. Best for multi-region active-active.
• Weighted routing: canary deployments — send 10% of traffic to new version, 90% to stable.
• Path-based routing: route /api/* to AKS, /static/* to Storage, /* to App Service.
• Header-based routing: beta users (special header) get routed to preview environment.

Caching — Reduce Origin Load

Front Door can cache responses at edge PoPs, dramatically reducing load on your origins. Key configuration decisions:

• Set cache duration via Cache-Control response headers from your origin (AFD respects them)
• Use query string caching options: ignore query strings for static assets, include them for dynamic content
• Set up cache purge in your CI/CD pipeline — purge cached content after each deployment

Monitoring & Observability

Connect Front Door to Log Analytics and set up these essential queries:

// WAF blocked requests — top offenders
AzureDiagnostics
| where ResourceType == "FRONTDOORS" and Category == "FrontdoorWebApplicationFirewallLog"
| where action_s == "Block"
| summarize Count = count() by clientIp_s, ruleName_s
| top 20 by Count desc

// Origin health — detect when an origin goes unhealthy
AzureDiagnostics
| where ResourceType == "FRONTDOORS" and Category == "FrontdoorHealthProbeLog"
| where httpStatusCode_d != 200
| summarize FailCount = count() by originName_s, bin(TimeGenerated, 5m)
| order by TimeGenerated desc

When to Use Front Door vs. Application Gateway

This is one of the most common questions I get:

• Use Front Door when: you have users globally, multiple regions, need CDN, or want WAF at the edge
• Use Application Gateway when: all users are in one region, you need deep SSL inspection, mutual TLS, or cookie-based session affinity at the VNet level
• Use both: Front Door at the edge for global routing + WAF, Application Gateway internally for granular backend routing within a VNet

Summary

Azure Front Door is one of the highest-leverage services in Azure's networking portfolio. When architected correctly, it gives you:

• Global latency reduction through edge TLS termination and caching
• WAF protection without managing your own reverse proxy
• Multi-region active-active or active-passive failover
• Zero-public-IP origin security (with Premium)
• Flexible routing for canary deployments and path-based traffic

The main architectural decisions: Standard vs. Premium tier, WAF mode (Detection → Prevention), and how you secure your origins. Get those right and you have a robust, globally distributed application entry point.

Rajaas Tahir

Cloud & AI Solution Architect · 26x Certified · Toronto, Canada

I write about cloud architecture, Azure, DevOps, and AI infrastructure — the real decisions and trade-offs, not just tutorials. Follow along on YouTube and GitHub for hands-on labs.

Subscribe on YouTube Connect on LinkedIn GitHub Labs