What Azure Front Door Does
Azure Front Door is a global, Layer 7 (HTTP/HTTPS) entry point that sits at the edge of Microsoft's global network of Points of Presence (PoPs), routing client requests to the closest and healthiest backend -- which could be an App Service, a VM Scale Set behind a regional load balancer, a Storage static website, or even an on-premises server -- using anycast so a single public IP or hostname resolves to whichever PoP is geographically nearest the requester. Because it operates at Layer 7, Front Door can perform path-based routing (send /api/* to one backend and /images/* to another), URL rewrite/redirect, session affinity via cookies, and SSL offload/termination at the edge, none of which a Layer 4 Azure Load Balancer can do. It also continuously health-probes each backend and automatically fails over to the next-healthy backend in the backend pool if the primary region goes down, making it a common choice for global, multi-region active-active or active-passive application architectures.
Cricket analogy: It's like the ICC assigning a neutral host venue for a match based on which stadium is closest and best-prepared for the touring team, rather than fans having to know in advance exactly which ground their match will be played at -- one fixture entry, routed intelligently to the best available venue.
Front Door vs. Azure CDN
Azure CDN (and its modern successor, Front Door's own caching capability, since Microsoft has been consolidating standalone CDN into the Front Door product line) focuses specifically on caching static content -- images, CSS, JavaScript, video segments -- at edge PoPs close to end users, dramatically reducing latency and origin server load for content that doesn't change per-request. The distinction that matters in practice: Front Door is a full application delivery and global load-balancing layer with dynamic Layer 7 routing and failover as its primary purpose, with caching as a bonus feature, while a pure CDN's primary purpose is caching, with basic routing as a side effect. For a typical production setup, you'd configure caching rules on specific route paths (e.g., cache /static/* aggressively with a long TTL, but never cache /api/* which must always hit the origin), and you can set custom cache durations, query-string caching behavior, and compression per route.
Cricket analogy: It's like the difference between a full stadium operations team handling everything from gate routing to emergency medical response (Front Door -- comprehensive) versus a dedicated concessions-stocking crew whose only job is keeping snack stands pre-stocked near every entrance to reduce queue time (CDN -- caching-focused).
Routing Rules, WAF, and Backend Pools
Front Door configuration centers on routing rules that match incoming requests by domain and path pattern and direct them to a specific backend pool (also called an origin group), which can contain multiple origins with configurable priority and weight for active-active load spreading or active-passive failover. Attached to Front Door, Azure Web Application Firewall (WAF) policies inspect incoming HTTP requests against managed rule sets (like the OWASP Core Rule Set, catching SQL injection, cross-site scripting, and other common attack patterns) or custom rules you define (rate limiting, geo-filtering, blocking specific header/query patterns), all evaluated at the edge before traffic ever reaches your origin infrastructure, which both improves security posture and reduces load on backend compute.
Cricket analogy: It's like a stadium's security screening at the outer gates catching prohibited items before fans even reach the inner concourse (WAF at the edge), combined with ushers directing members-stand ticket holders to one gate and general-admission holders to another (routing rules by path/domain) -- all sorted before anyone reaches the seating bowl.
# Create a Front Door profile with an origin group, origin, and a path-based route
az afd profile create \
--resource-group rg-network-demo \
--profile-name fd-contoso \
--sku Standard_AzureFrontDoor
az afd origin-group create \
--resource-group rg-network-demo \
--profile-name fd-contoso \
--origin-group-name og-app \
--probe-request-type GET \
--probe-protocol Https \
--probe-path /healthz \
--probe-interval-in-seconds 30
az afd origin create \
--resource-group rg-network-demo \
--profile-name fd-contoso \
--origin-group-name og-app \
--origin-name app-eastus \
--host-name app-eastus.azurewebsites.net \
--priority 1 \
--weight 1000
az afd route create \
--resource-group rg-network-demo \
--profile-name fd-contoso \
--endpoint-name ep-contoso \
--route-name route-static \
--origin-group og-app \
--patterns-to-match '/static/*' \
--forwarding-protocol HttpsOnly \
--https-redirect Enabled \
--supported-protocols HttpsAzure Web Application Firewall (WAF) policies attached to Front Door evaluate requests at the edge, before traffic ever reaches your origin. This means a volumetric attack or injection attempt is blocked at a Microsoft PoP potentially thousands of miles from your actual backend, protecting both your security posture and your origin's compute capacity.
Caching in Front Door/CDN is powerful but dangerous if misapplied: caching a route that serves personalized or authenticated content (like /api/user/profile) can leak one user's data to another user who happens to hit the same cached edge response. Always scope caching rules tightly to genuinely static, non-personalized paths, and explicitly disable caching on API and authenticated routes.
- Azure Front Door is a global, Layer 7 (HTTP/HTTPS) entry point providing path-based routing, SSL offload, and automatic multi-region failover.
- Front Door uses anycast so a single hostname routes users to the nearest healthy Point of Presence and onward to the best backend.
- Azure CDN focuses primarily on caching static content at edge PoPs; Front Door is a broader application-delivery layer with caching as one feature.
- Origin groups (backend pools) support multiple origins with priority/weight settings for active-active load spreading or active-passive failover.
- Web Application Firewall (WAF) policies attached to Front Door block malicious requests at the edge using managed rule sets like OWASP CRS or custom rules.
- Routing rules match domain and path patterns to direct traffic to specific origin groups, enabling microservice-style path-based routing.
- Caching must be scoped carefully -- caching personalized or authenticated routes can leak one user's data to another.
Practice what you learned
1. What OSI layer does Azure Front Door operate at, and why does that matter?
2. What is the primary functional difference between Azure Front Door and Azure CDN?
3. What risk arises from misconfigured caching on a Front Door route?
4. What does an origin group's priority and weight settings enable?
5. Where does a Web Application Firewall (WAF) policy attached to Front Door evaluate incoming requests?
Was this page helpful?
You May Also Like
Azure Load Balancer Basics
Learn how Azure Load Balancer distributes Layer 4 traffic across backend pools using health probes, load balancing rules, and the Standard SKU's secure-by-default model.
Azure DNS Basics
Learn how Azure DNS hosts and resolves domain records, the standard record types, and how Alias records solve Azure-specific limitations like apex domain routing.
Azure Virtual Networks
Learn how Azure Virtual Networks (VNets) provide isolated, private IP address spaces for your cloud resources, and how peering and hybrid connectivity link them together.