Azure Front Door: Global Load Balancing

Azure Front Door is a globally distributed application delivery network that operates at Layer 7 (HTTP/HTTPS). It routes client requests to the fastest available backend origin across multiple Azure regions using anycast networking — traffic enters the Azure backbone at the nearest edge PoP rather than traversing the public internet to your origin. Front Door provides global load balancing, SSL offload, CDN caching, and a built-in Web Application Firewall in a single service.

Azure Front Door is available in two tiers. Standard includes CDN caching, custom domains with managed TLS, rules engine, and basic WAF. Premium adds advanced WAF with managed rule sets (Microsoft Default and OWASP rule sets), Bot protection, security reports, Private Link integration (to send traffic to origins over a private endpoint without public IP), and Azure Defender integration. Most production web applications use Premium for its WAF and Private Link capabilities.

In Front Door, an origin is a backend server — an App Service, a public IP, a Blob Storage static website, or any HTTP(S) endpoint. Origins are grouped into origin groups. Load balancing and health probe settings are configured per origin group. For example, you might have one origin group with App Service backends in East US and West US. Front Door routes requests within the group based on priority, weight, or latency, and automatically removes unhealthy origins based on health probe results.

Health probes are periodic HTTP/HTTPS requests sent from Front Door PoPs to each origin to measure latency and verify the origin is healthy. You configure the probe path, protocol, interval, and number of consecutive failures before an origin is marked unhealthy. When an origin fails health probes, Front Door automatically removes it from the routing pool — all new requests are sent to the remaining healthy origins. This enables automatic failover with no manual intervention.

Front Door supports three load balancing methods within an origin group. Latency-based routing (default) sends each request to the origin with the lowest measured round-trip time from the client's nearest PoP — ideal for performance. Weighted distributes traffic based on assigned weights (e.g. 80% to primary, 20% to secondary) — useful for canary deployments. Priority sends all traffic to the highest-priority origin and fails over to lower-priority origins only if the primary is unhealthy — ideal for active-passive DR.

A route in Front Door maps a domain and URL path pattern to an origin group. You can create multiple routes to implement path-based routing: for example, /api/* routes to a backend API App Service, /static/* routes to a Blob Storage origin with aggressive CDN caching, and /* routes to the web frontend. Each route has independent caching, compression, and forwarding protocol settings.

Front Door provides a managed TLS certificate for each custom domain you associate with an endpoint — automatically provisioned via DigiCert and auto-renewed before expiry at no additional charge. You validate domain ownership by adding a CNAME record pointing your apex or subdomain to the Front Door endpoint. You can also use your own certificate stored in Azure Key Vault. Front Door terminates TLS at the edge PoP, reducing latency for TLS handshakes compared to origin-terminated TLS.

The rules engine (called Rule sets in Standard/Premium) lets you modify routing behaviour based on request attributes: match on URL path, query string, request method, HTTP headers, geo-location, or device type. Actions include redirecting URLs, forwarding to a different origin group, modifying request/response headers, or overriding caching settings. A common use is enforcing HTTPS by redirecting all HTTP traffic to HTTPS using a redirect rule before it reaches your origin.

In the Premium tier, Front Door can connect to origins via Private Link instead of the public internet. This means your App Service or Blob Storage origin does not need a public IP — traffic from Front Door PoPs travels over Microsoft's private backbone to a private endpoint in your VNet. You approve the Private Link connection request in the portal or via CLI, after which traffic between Front Door and the origin never traverses the public internet, eliminating the need for inbound firewall rules on the origin.

Session affinity (also called sticky sessions) ensures that requests from the same client are consistently routed to the same origin for the duration of a session. Front Door achieves this with a cookie-based mechanism — it sets a session cookie on the first response, and subsequent requests with that cookie are pinned to the same origin. Session affinity trades off even load distribution for application compatibility when state is stored locally on the origin server rather than in a shared cache or database.

Front Door emits metrics to Azure Monitor including total requests, origin health percentage, request hit ratio, origin latency, and WAF request count by action. You can create metric alert rules on these to get notified when origin health drops below a threshold or WAF blocks spike unexpectedly. Front Door also provides built-in reports in the Premium tier showing traffic by geography, top requested URLs, and WAF matched rules.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: Azure Front Door uses anycast networking and health-probe-based failover to route HTTP traffic to the fastest available origin globally, routes and path-based routing let you direct different URL paths to different backends, and the Premium tier adds Private Link origins and advanced WAF capabilities. Next up we explore attaching a Web Application Firewall to Front Door for security.