Azure CDN and Front Door: Microsoft's Edge Delivery Stack
Microsoft's edge delivery stack has undergone significant consolidation in recent years. What was previously a fragmented set of products — Azure CDN with profiles from Microsoft, Akamai, and Verizon, plus Azure Front Door as a separate service — is converging into Azure Front Door as the unified platform for global content delivery, Layer 7 load balancing, and edge security. Understanding this evolving landscape is essential for organizations building on Azure or evaluating Microsoft's CDN capabilities against competitors like Cloudflare, AWS CloudFront, and Akamai.
What Are the Azure CDN Profile Options?
Azure has historically offered four CDN profile types, each powered by different underlying infrastructure. This multi-provider approach gave customers choice but created confusion about feature parity and future direction.
| Profile Type | Powered By | Status | PoP Count | Key Differentiator |
|---|---|---|---|---|
| Azure Front Door Standard | Microsoft | Active (recommended) | 180+ edge locations | CDN + L7 load balancing + WAF |
| Azure Front Door Premium | Microsoft | Active | 180+ edge locations | Advanced WAF + Private Link |
| Azure CDN from Microsoft (Classic) | Microsoft | Migration to Front Door | 130+ PoPs | Basic CDN caching |
| Azure CDN from Edgio | Edgio (Verizon) | Sunsetting | 130+ PoPs | Rules engine, large file optimization |
Microsoft's strategic direction is clear: Azure Front Door Standard and Premium are the future of content delivery on Azure. Classic Azure CDN profiles are being migrated to Front Door, and the Edgio-powered profiles are being phased out following Edgio's financial difficulties. New deployments should use Azure Front Door directly rather than legacy CDN profiles.
How Does Azure Front Door Work as a Combined CDN and Load Balancer?
Azure Front Door is fundamentally a global Layer 7 (HTTP/HTTPS) load balancer with integrated CDN caching, not a CDN with bolted-on routing. This architectural distinction shapes how Front Door handles traffic and how it compares to CDN-first products.
| Metric | Edge Processing | Origin Processing | Improvement |
|---|---|---|---|
| Latency (p50) | 8–15 ms | 120–300 ms | 15–20x faster |
| Cache Hit Ratio | 85–95% | N/A | Reduces origin load |
| TLS Handshake | 1–5 ms (nearby PoP) | 50–150 ms | 10–30x faster |
| Bandwidth Cost | $0.01–0.04/GB | $0.05–0.12/GB | 3–5x cheaper |
| Availability | 99.99% (multi-PoP) | 99.9% (single DC) | 10x fewer outages |
When a user request arrives at the nearest Microsoft edge PoP (routed via anycast), Front Door performs three operations in sequence: security evaluation (WAF rules, DDoS checks), cache lookup (for cacheable content), and origin routing (for cache misses or non-cacheable content). Origin routing uses Front Door's health probing and routing rules to select the optimal backend from a pool of origins that may span multiple Azure regions, on-premises data centers, or other cloud providers.
Routing Methods
Front Door supports four routing methods that can be combined for complex multi-region architectures:
- Latency-based routing: Directs requests to the origin with the lowest measured latency from the edge PoP, accounting for real-time network conditions. This is the default and most common method for global applications.
- Priority-based routing: Configures primary and fallback origins. Traffic goes to the highest-priority origin; if health probes detect failure, traffic shifts to the next priority level. This enables active-passive failover across Azure regions.
- Weighted routing: Distributes traffic across origins based on configured weights (e.g., 70% to Region A, 30% to Region B). Useful for gradual migration between regions, blue-green deployments, and A/B testing infrastructure changes.
- Session affinity: Routes subsequent requests from the same user to the same origin, using cookies to maintain the affinity. Required for applications with server-side session state that is not shared across origins.
What Can the Front Door Rules Engine Do?
The Front Door Rules Engine provides declarative request and response manipulation at the edge. Rules consist of match conditions (URL path, query string, request headers, HTTP method, geographic location, device type, SSL protocol) and actions (URL rewrite, URL redirect, modify request/response headers, override cache behavior, route override).
Common Rules Engine use cases include:
- URL canonicalization: Redirecting HTTP to HTTPS, adding or removing trailing slashes, enforcing www or non-www prefixes.
- Cache behavior overrides: Setting custom TTLs for specific paths, bypassing cache for authenticated content, enabling compression for specific content types.
- Security header injection: Adding Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, and other security headers at the edge without modifying the origin application.
- Geographic routing: Directing users in specific countries to localized origins or blocking traffic from restricted regions for compliance requirements.
- Device-based routing: Serving different content or routing to different origins based on mobile versus desktop classification.
The Rules Engine does not support arbitrary code execution. For use cases requiring custom logic beyond declarative rules — JWT validation, complex routing algorithms, dynamic content assembly — organizations must use Azure Functions or other compute services behind Front Door, accepting the latency of centralized execution.
How Does Azure WAF Integrate with Front Door?
Azure Web Application Firewall (WAF) attaches directly to Front Door profiles, evaluating every request at the edge before cache lookup or origin routing. WAF policies contain three types of rules:
Managed rule sets provide pre-configured protection against OWASP Top 10 threats (SQL injection, XSS, command injection, path traversal), Microsoft threat intelligence (known malicious IPs), and bot detection. Managed rules are updated by Microsoft as new threats emerge, requiring no customer-side maintenance. The Default Rule Set (DRS) 2.1 includes over 100 rules organized by attack category.
Custom rules define application-specific policies. Common custom rules include rate limiting by IP address (e.g., maximum 100 requests per minute per IP), geographic restrictions (block or allow specific countries), and header-based filtering (require specific API keys or authentication tokens). Custom rules are evaluated before managed rules, allowing overrides for trusted traffic.
Bot protection rules (Premium tier only) classify incoming traffic using Microsoft's bot detection algorithms. Good bots (search engine crawlers, monitoring services) are identified and allowed. Bad bots (scrapers, credential stuffers, vulnerability scanners) are blocked or challenged. Unknown bots can be challenged with CAPTCHAs or JavaScript challenges to verify human origin.
| WAF Feature | Standard Tier | Premium Tier |
|---|---|---|
| Managed OWASP rules | Yes | Yes |
| Custom rules | 100 per policy | 100 per policy |
| Rate limiting | Yes | Yes |
| Geo-filtering | Basic | Advanced |
| Bot protection | No | Yes |
| IP reputation | No | Yes |
| Anomaly scoring | No | Yes |
What Is Private Link Origin and Why Does It Matter?
Private Link origins (Premium tier only) allow Front Door to connect to backend services through Azure's private network rather than the public internet. The origin does not need a public IP address or firewall exceptions for Front Door's IP ranges. Instead, Front Door establishes a private endpoint connection directly to the origin's virtual network.
This feature provides stronger origin protection than IP allowlisting because the origin is completely invisible to the public internet. Even if an attacker discovers the origin's address, they cannot reach it because it has no public network path. Private Link origins work with Azure App Service, Azure Storage, Azure Functions, and any service that supports Azure Private Endpoints.
For enterprises with strict security requirements — financial services, healthcare, government — Private Link origins eliminate an entire attack surface. The origin infrastructure exists only on Azure's private backbone, accessible exclusively through the Front Door edge network. This level of origin isolation is not available from CDN-only providers; it requires the CDN to be integrated into the cloud platform's networking layer.
How Does Azure DDoS Protection Work with Front Door?
Azure DDoS protection operates at two levels. DDoS Protection Basic is automatically enabled for all Azure resources, including Front Door endpoints. It mitigates common network-layer attacks (SYN floods, UDP floods, reflection attacks) without additional cost or configuration. DDoS Protection Standard ($2,944/month) adds application-layer protection, attack analytics, rapid response team access, and cost protection guarantees for scaling charges incurred during attacks.
Front Door's distributed edge network inherently absorbs volumetric DDoS attacks by distributing attack traffic across Microsoft's 180+ global edge locations. Combined with WAF rate limiting and bot protection, Front Door provides multi-layer defense against both network-layer and application-layer attacks. The integration between DDoS Protection Standard, WAF, and Front Door is seamless within the Azure portal, providing unified security monitoring and alerting.
When Should You Choose Azure Front Door?
Azure Front Door is the right choice for organizations with significant Azure investments that need integrated CDN, load balancing, and security under Azure's management plane. The unified ARM (Azure Resource Manager) template support, Azure Monitor integration, and Azure Policy compliance make Front Door the most operationally efficient CDN option for Azure-native architectures.
Front Door's key advantages include Private Link origins (unmatched origin security), multi-region load balancing (built-in failover and traffic management), and unified Azure security (WAF + DDoS + Azure Monitor in one pane). Its disadvantages include higher base costs than CDN-only providers ($35/month Standard, $330/month Premium), no edge compute capability (unlike Cloudflare Workers or Lambda@Edge), slower cache purge times compared to Fastly, and less transparent documentation about PoP-level performance.
For organizations not on Azure, Front Door offers little advantage over competing CDNs. CloudFront provides equivalent cloud-integrated CDN for AWS. Google Cloud CDN serves the same role for GCP. Cloudflare and Bunny CDN provide cloud-agnostic CDN services with simpler setup, more transparent pricing, and broader feature sets for pure content delivery use cases. The CDN market rewards ecosystem alignment — choose the CDN that integrates most naturally with your existing cloud infrastructure.