Azure Front Door

Azure Front Door is a global, scalable entry point that uses Microsoft's global edge network to route HTTP/HTTPS traffic to your application endpoints. It solves the problem of delivering web applications with low latency and high availability to users worldwide. Without Front Door, a company with a single regional server would suffer slow load times for distant users. If that server fails, the entire app goes down. Front Door provides global load balancing, SSL offload, path-based routing, and a built-in web application firewall (WAF) to protect against common web exploits. It is a Layer 7 (application layer) load balancer, meaning it can make routing decisions based on HTTP headers, URL paths, cookies, or client IP addresses.

Azure Front Door has two tiers: Standard and Premium. The Standard tier includes global load balancing, SSL termination, path-based routing, caching, and basic WAF (custom rules). The Premium tier adds managed WAF rule sets (OWASP), bot protection, private link support, and advanced security features. Pricing is based on outbound data transfer and rules processed. There is no upfront cost; you pay for what you use.

On-premises, you might use a hardware load balancer like F5 BIG-IP or Citrix ADC. These are single-region, require manual scaling, and lack global anycast routing. Azure Front Door is cloud-native, globally distributed, and integrates with Azure services. It also includes a CDN and WAF, which on-premises would require separate appliances. The trade-off is that Front Door only works for HTTP/HTTPS traffic, whereas on-premises load balancers can handle any TCP/UDP protocol.

In the Azure portal, you create a Front Door profile under "Front Doors and CDN profiles." You then configure frontend hosts, backend pools, routing rules, and health probes. The CLI allows scripting:

az network front-door create --name myFrontDoor --resource-group myRG \
  --backend-address myapp.azurewebsites.net

To add a routing rule:

az network front-door routing-rule create --front-door-name myFrontDoor \
  --name apiRule --resource-group myRG --frontend-endpoints myFrontend \
  --accepted-protocols Https --patterns /api/* --route-to-backend-pool myAPIPool

ARM templates and Bicep are also supported for infrastructure as code.

Scenario 1: Global E-Commerce Platform A retail company with customers in North America, Europe, and Asia runs an e-commerce site on Azure App Services deployed in three regions: West US, West Europe, and Southeast Asia. Without Front Door, users in Asia experience high latency because DNS might route them to the US. The company deploys Azure Front Door with latency-based routing. Now, a user in Tokyo is automatically directed to the Southeast Asia backend. If that region experiences an outage, Front Door reroutes to West Europe. The company also caches product images and CSS at the edge, reducing load on the App Services. They enable WAF to block SQL injection attempts. Cost: data transfer costs for outbound traffic from the edge, plus a small per-rule fee. A common mistake is not setting health probes correctly — if the probe path is / instead of /health, the backend might be marked unhealthy if the root page is dynamic and slow to respond.

Scenario 2: Multi-Region API for Financial Services A fintech company exposes APIs to partners globally. They need low latency and high security. They deploy Azure Front Door Premium with path-based routing: /api/v1/* goes to a backend pool of VMs in US East, /api/v2/* goes to a containerized app in UK South. They use priority routing: the primary backend is US East, with UK South as failover. The WAF blocks requests from countries where they don't operate. They also use private link to connect Front Door to their VNets, so traffic never goes over the public internet. The challenge: they initially set the health probe interval too short (5 seconds), causing false positives. They changed it to 30 seconds. Also, they forgot to enable SSL termination at Front Door, causing double encryption overhead.

Scenario 3: Media Streaming Platform A streaming service uses Azure Front Door to route traffic to origin servers and cache video segments at the edge. They use query-string caching to differentiate video quality (e.g., ?quality=1080p). However, they misconfigured the cache duration — set too long, so users saw stale content after a new episode was uploaded. They fixed it by setting a shorter cache duration for video segments and using cache purging to invalidate old content. They also use WAF to block bots that were scraping their content.