Front Door & CDN Guide
Configure Azure Front Door and CDN for global content delivery, including routing, WAF policies, caching, SSL/TLS, and performance optimization.
Prerequisites
- Understanding of HTTP caching and CDN concepts
- Familiarity with Azure networking basics
- Experience with DNS configuration
Azure Content Delivery Overview
Delivering content to users with low latency and high reliability is a fundamental requirement for modern web applications. Azure provides several services for global content delivery and traffic management, with Azure Front Door and Azure CDN being the two primary options. Understanding the differences between these services, and when to use each, is essential for designing performant, secure, and cost-effective application delivery architectures.
Azure Front Door is a global, scalable entry point that uses Microsoft's worldwide edge network to provide fast, reliable, and secure access to your web applications. It combines content delivery (CDN), global load balancing, WAF (Web Application Firewall), and SSL offloading into a single service. Azure CDN, on the other hand, is a more traditional content delivery network focused primarily on caching static content at edge locations close to users.
With the introduction of Azure Front Door Standard and Premium tiers (which incorporate Azure CDN capabilities), Microsoft has been converging these services. This guide covers both services in depth, helping you understand their architectures, features, and the scenarios where each excels.
Azure Front Door Tiers
Azure Front Door is available in two tiers: Standard and Premium. The Standard tier includes CDN capabilities, custom domains, SSL, basic WAF, and routing. The Premium tier adds managed WAF rule sets, bot protection, Private Link origin support, and advanced analytics. For most production workloads that need WAF protection, the Premium tier is recommended. The legacy Azure Front Door (Classic) and Azure CDN Standard/Premium from Microsoft are being consolidated into the new Front Door tiers.
Azure Front Door Architecture
Azure Front Door operates at Layer 7 (HTTP/HTTPS) on Microsoft's global edge network, which spans over 190 edge locations worldwide. When a user makes a request to your application through Front Door, the request is received at the nearest edge location (called a Point of Presence or PoP), where it can be served from cache, or forwarded to the optimal origin based on routing rules, health probes, and latency measurements.
Key Concepts
| Concept | Description |
|---|---|
| Endpoint | A globally unique hostname (e.g., myapp.z01.azurefd.net) that receives traffic |
| Origin Group | A collection of backend origins that serve the same content (for load balancing and failover) |
| Origin | A backend service (App Service, Storage, VM, custom hostname) that serves content |
| Route | Rules that map incoming requests to origin groups based on path, protocol, and headers |
| Rule Set | Collections of rules for request/response manipulation (rewrite URLs, add headers, redirect) |
| Security Policy | WAF policy attached to an endpoint for security protection |
| Custom Domain | Your own domain name (e.g., www.myapp.com) pointed to the Front Door endpoint |
# Create an Azure Front Door profile (Premium tier)
az afd profile create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--sku Premium_AzureFrontDoor \
--tags project=myapp environment=production
# Create an endpoint
az afd endpoint create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--endpoint-name myapp-endpoint \
--enabled-state Enabled
# Create an origin group with health probes
az afd origin-group create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--origin-group-name og-webapp \
--probe-request-type HEAD \
--probe-protocol Https \
--probe-interval-in-seconds 30 \
--probe-path "/health" \
--sample-size 4 \
--successful-samples-required 3 \
--additional-latency-in-milliseconds 50
# Add primary origin (East US App Service)
az afd origin create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--origin-group-name og-webapp \
--origin-name origin-eastus \
--host-name myapp-eastus.azurewebsites.net \
--origin-host-header myapp-eastus.azurewebsites.net \
--http-port 80 \
--https-port 443 \
--priority 1 \
--weight 1000 \
--enabled-state Enabled
# Add secondary origin (West US App Service)
az afd origin create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--origin-group-name og-webapp \
--origin-name origin-westus \
--host-name myapp-westus.azurewebsites.net \
--origin-host-header myapp-westus.azurewebsites.net \
--http-port 80 \
--https-port 443 \
--priority 1 \
--weight 1000 \
--enabled-state Enabled
# Create a route to connect the endpoint to the origin group
az afd route create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--endpoint-name myapp-endpoint \
--route-name route-default \
--origin-group og-webapp \
--supported-protocols Https \
--https-redirect Enabled \
--patterns-to-match "/*" \
--forwarding-protocol HttpsOnly \
--link-to-default-domain EnabledAzure CDN Profiles & Tiers
Azure CDN (now being consolidated under Azure Front Door) provides static content caching at globally distributed edge nodes. While Front Door is designed for dynamic and static content with advanced routing, CDN profiles focus primarily on caching static assets (images, CSS, JavaScript, videos) to reduce origin server load and improve end-user latency.
| CDN Tier | Provider | Features | Best For |
|---|---|---|---|
| Azure Front Door Standard | Microsoft | CDN + basic routing + basic WAF | Websites needing CDN with light WAF |
| Azure Front Door Premium | Microsoft | CDN + advanced routing + managed WAF + Private Link | Enterprise apps with strong security needs |
| Azure CDN Standard from Edgio | Edgio (Verizon) | Traditional CDN, rules engine, real-time analytics | Media streaming, large file downloads |
| Azure CDN Standard from Akamai | Akamai (retiring) | Traditional CDN, broad PoP coverage | Legacy workloads (being deprecated) |
CDN Provider Consolidation
Microsoft is consolidating Azure CDN offerings under the Azure Front Door brand. The Azure CDN from Akamai tier has been deprecated, and new profiles can no longer be created. Azure CDN from Edgio may also be affected by Edgio's business changes. For new projects, use Azure Front Door Standard or Premium, which include all CDN capabilities plus advanced routing and security features. Existing CDN profiles continue to work but should be migrated to Front Door during your next architecture review.
Routing & Load Balancing
Azure Front Door provides sophisticated routing capabilities that determine how incoming requests are matched to origin groups and how traffic is distributed across origins within a group. The routing system operates at two levels: route matching (which origin group handles the request) and origin selection (which specific origin within the group receives the request).
Route Matching
Routes match incoming requests based on protocol, hostname, and URL path patterns. When multiple routes match a request, Front Door uses the most specific match. Path patterns support wildcards and exact matches.
Load Balancing Methods
| Method | How It Works | When to Use |
|---|---|---|
| Latency-based | Routes to the origin with lowest measured latency | Default; best for most web applications |
| Priority | Routes to highest priority origin; lower priority used as failover | Active/passive DR with a clear primary region |
| Weighted | Distributes traffic proportionally based on weight values | Canary deployments, gradual traffic migration |
| Session Affinity | Routes subsequent requests from same user to same origin | Stateful applications that store session data locally |
# Create a rule set for URL rewriting and header manipulation
az afd rule-set create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--rule-set-name SecurityHeaders
# Add a rule to set security headers on all responses
az afd rule create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--rule-set-name SecurityHeaders \
--rule-name AddSecurityHeaders \
--order 1 \
--match-variable RequestMethod \
--operator Equal \
--match-values GET POST \
--action-name ModifyResponseHeader \
--header-action Append \
--header-name "Strict-Transport-Security" \
--header-value "max-age=31536000; includeSubDomains"
# Create separate origin group for static assets (blob storage)
az afd origin-group create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--origin-group-name og-static \
--probe-request-type HEAD \
--probe-protocol Https \
--probe-interval-in-seconds 120 \
--probe-path "/"
az afd origin create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--origin-group-name og-static \
--origin-name origin-storage \
--host-name stmyappstatic.blob.core.windows.net \
--origin-host-header stmyappstatic.blob.core.windows.net \
--https-port 443 \
--priority 1 \
--weight 1000
# Create a route for static assets with longer cache TTL
az afd route create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--endpoint-name myapp-endpoint \
--route-name route-static \
--origin-group og-static \
--supported-protocols Https \
--https-redirect Enabled \
--patterns-to-match "/static/*" "/images/*" "/css/*" "/js/*" \
--forwarding-protocol HttpsOnly \
--link-to-default-domain Enabled \
--query-string-caching-behavior IgnoreQueryStringWAF Policies & Security
Azure Web Application Firewall (WAF) protects your web applications from common exploits and vulnerabilities. When integrated with Azure Front Door, WAF inspects every incoming request at the edge before it reaches your origin servers, providing protection against OWASP Top 10 threats, SQL injection, cross-site scripting (XSS), and other attack vectors.
WAF Policy Modes
WAF policies can operate in two modes: Detection mode (logs matched rules but does not block requests, ideal for testing) and Preventionmode (blocks requests that match rules, required for production protection). Always start in Detection mode, analyze the logs to identify false positives, configure exclusions, and then switch to Prevention mode.
# Create a WAF policy for Front Door (Premium tier)
az network front-door waf-policy create \
--resource-group rg-frontdoor \
--name wafMyAppProd \
--sku Premium_AzureFrontDoor \
--mode Prevention \
--redirect-url "https://myapp.com/blocked"
# Enable managed rule sets (OWASP and bot protection)
az network front-door waf-policy managed-rules add \
--resource-group rg-frontdoor \
--policy-name wafMyAppProd \
--type Microsoft_DefaultRuleSet \
--version 2.1 \
--action Block
az network front-door waf-policy managed-rules add \
--resource-group rg-frontdoor \
--policy-name wafMyAppProd \
--type Microsoft_BotManagerRuleSet \
--version 1.0 \
--action Block
# Add a custom rule: block requests from specific countries
az network front-door waf-policy rule create \
--resource-group rg-frontdoor \
--policy-name wafMyAppProd \
--name GeoBlockRule \
--priority 100 \
--action Block \
--rule-type MatchRule \
--match-variable RemoteAddr \
--operator GeoMatch \
--match-values "XX" "YY"
# Add a custom rule: rate limit per IP (100 requests per 5 minutes)
az network front-door waf-policy rule create \
--resource-group rg-frontdoor \
--policy-name wafMyAppProd \
--name RateLimitPerIP \
--priority 200 \
--action Block \
--rule-type RateLimitRule \
--rate-limit-threshold 100 \
--rate-limit-duration-in-minutes 5 \
--match-variable RemoteAddr \
--operator IPMatch \
--match-values "0.0.0.0/0"
# Associate WAF policy with Front Door security policy
az afd security-policy create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--security-policy-name sp-waf \
--waf-policy /subscriptions/<sub-id>/resourceGroups/rg-frontdoor/providers/Microsoft.Network/FrontDoorWebApplicationFirewallPolicies/wafMyAppProd \
--domains /subscriptions/<sub-id>/resourceGroups/rg-frontdoor/providers/Microsoft.Cdn/profiles/afd-myapp-prod/afdEndpoints/myapp-endpointWAF Tuning
Managed WAF rules can generate false positives, especially for APIs that accept complex JSON payloads or applications that use non-standard URL patterns. After enabling WAF in Detection mode, analyze the logs in Log Analytics using theAzureDiagnostics | where Category == "FrontDoorWebApplicationFirewallLog" query. For rules that trigger false positives, create rule exclusions for specific request fields (headers, cookies, query strings) rather than disabling the entire rule.
SSL/TLS & Custom Domains
Azure Front Door provides built-in SSL/TLS termination at the edge, meaning encrypted connections are decrypted at the Front Door PoP closest to the user and then optionally re-encrypted for the connection to your origin. This reduces latency (because the TLS handshake happens closer to the user) and allows Front Door to inspect and cache content.
Certificate Options
| Option | Management | Use Case |
|---|---|---|
| Front Door Managed | Automatic provisioning and renewal | Most scenarios (zero-touch certificate management) |
| Bring Your Own (Key Vault) | You manage certificates in Azure Key Vault | EV certificates, specific CA requirements, wildcard certs |
# Add a custom domain to the Front Door endpoint
az afd custom-domain create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--custom-domain-name www-myapp-com \
--host-name www.myapp.com \
--certificate-type ManagedCertificate \
--minimum-tls-version TLS12
# The command will output a validation token
# Create a DNS TXT record for domain validation:
# _dnsauth.www.myapp.com -> <validation-token>
# Then create a CNAME record:
# www.myapp.com -> myapp-endpoint.z01.azurefd.net
# Check domain validation status
az afd custom-domain show \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--custom-domain-name www-myapp-com \
--query '{Domain:hostName, ValidationState:validationProperties.validationState, CertStatus:tlsSettings.certificateType}' \
--output table
# Associate the custom domain with a route
az afd route update \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--endpoint-name myapp-endpoint \
--route-name route-default \
--custom-domains www-myapp-comCaching Rules & Optimization
Caching is one of the most impactful performance optimizations Front Door provides. When a request can be served from the edge cache, the response is returned to the user in milliseconds without any origin server involvement. Effective caching requires understanding cache key composition, TTL configuration, and cache purging strategies.
Cache Key Components
The cache key determines whether two requests are considered "the same" for caching purposes. By default, Front Door uses the request URL (including query string) as the cache key. You can customize this behavior to ignore query strings, include specific headers, or group requests that should share a cached response.
# Update route with caching enabled
az afd route update \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--endpoint-name myapp-endpoint \
--route-name route-static \
--enable-caching true \
--query-string-caching-behavior IgnoreQueryString
# Create a rule set for cache customization
az afd rule-set create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--rule-set-name CacheRules
# Rule: Cache images for 7 days
az afd rule create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--rule-set-name CacheRules \
--rule-name CacheImages \
--order 1 \
--match-variable UrlFileExtension \
--operator Equal \
--match-values jpg jpeg png gif webp svg ico \
--action-name CacheExpiration \
--cache-behavior Override \
--cache-duration "7.00:00:00"
# Rule: Cache CSS/JS for 1 day with query string differentiation
az afd rule create \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--rule-set-name CacheRules \
--rule-name CacheAssets \
--order 2 \
--match-variable UrlFileExtension \
--operator Equal \
--match-values css js \
--action-name CacheExpiration \
--cache-behavior Override \
--cache-duration "1.00:00:00"
# Purge cached content when you deploy new versions
az afd endpoint purge \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--endpoint-name myapp-endpoint \
--content-paths "/static/*" "/css/*" "/js/*"
# Purge everything
az afd endpoint purge \
--resource-group rg-frontdoor \
--profile-name afd-myapp-prod \
--endpoint-name myapp-endpoint \
--content-paths "/*"Health Probes & Failover
Health probes are the mechanism by which Front Door monitors the availability of your origin servers. Front Door periodically sends requests to the configured health probe path on each origin and uses the responses to determine whether an origin is healthy. When an origin fails health checks, Front Door automatically routes traffic to healthy origins within the same origin group, providing transparent failover without user impact.
Health Probe Configuration
| Setting | Recommendation | Why |
|---|---|---|
| Path | /health or /healthz | Use a dedicated health endpoint, not the homepage |
| Protocol | HTTPS | Match production traffic protocol |
| Method | HEAD | Reduces probe bandwidth; GET if you need body validation |
| Interval | 30 seconds | Balance between detection speed and origin load |
| Sample Size | 4 | Number of recent probes to consider |
| Successful Samples | 3 | How many of the sample must succeed (3 of 4 = 75%) |
Health Probe Design
Your health probe endpoint should check the actual health of your application, not just return 200 OK. A good health endpoint verifies database connectivity, cache availability, and critical dependency reachability. However, do not make the health check too deep; if a non-critical dependency is down, you probably do not want Front Door to failover. Consider implementing both a shallow health check (for load balancer probes) and a deep health check (for monitoring and alerting).
Front Door vs CDN vs Traffic Manager
Azure offers three services that handle global traffic distribution, each operating at a different network layer with different capabilities. Understanding the differences is essential for choosing the right service for your architecture.
| Feature | Azure Front Door | Azure CDN (Edgio) | Azure Traffic Manager |
|---|---|---|---|
| Layer | Layer 7 (HTTP/HTTPS) | Layer 7 (HTTP/HTTPS) | Layer 4 (DNS-based) |
| Traffic Handling | Proxies traffic through edge | Proxies traffic through edge | DNS resolution only (no data path) |
| WAF | Yes (built-in, managed rules) | Limited | No |
| Caching | Yes | Yes (primary focus) | No |
| SSL Offloading | Yes | Yes | No (passthrough) |
| Routing | URL path, header, method-based | Limited rules engine | Geographic, performance, weighted, priority |
| Health Probes | HTTP/HTTPS at origin level | HTTP/HTTPS | HTTP/HTTPS/TCP at endpoint level |
| Non-HTTP Protocols | No (HTTP/HTTPS only) | No | Yes (any TCP/UDP protocol) |
| Best For | Web apps needing CDN + WAF + routing | Static content-heavy sites, media delivery | Non-HTTP traffic, DNS-level failover |
Combining Services
For complex architectures, you can combine these services. A common pattern uses Azure Front Door for HTTP/HTTPS web traffic (providing CDN, WAF, and Layer 7 routing) while using Traffic Manager for non-HTTP services like database connections, MQTT for IoT, or custom TCP protocols. Traffic Manager can also sit in front of multiple Front Door instances for cross-profile failover, though this is rarely needed since Front Door itself provides global failover.
Cost Optimization & Best Practices
Azure Front Door pricing is based on several components: base fee (per profile), data transfer from edge to client, data transfer from edge to origin, and request count. WAF requests and custom domains add incremental costs. Understanding these components helps you optimize costs while maintaining performance and security.
Cost Optimization Strategies
- Maximize cache hit ratio: Higher cache hit ratios reduce origin data transfer costs and origin server load. Use the Front Door analytics to track cache hit ratios and identify frequently requested content that is not being cached.
- Use compression: Enable compression for text-based content types (HTML, CSS, JavaScript, JSON). Compression reduces data transfer volume by 60–80%, directly reducing bandwidth costs.
- Right-size your tier: Use the Standard tier if you do not need managed WAF rule sets, bot protection, or Private Link. The Standard tier is approximately 30% cheaper than Premium for the same traffic volume.
- Minimize origin requests: Increase cache TTLs for static content, use
stale-while-revalidatepatterns, and batch API responses to reduce the number of requests that reach your origin. - Monitor data transfer patterns: Analyze which origins generate the most data transfer and whether that content could be served from a closer edge location or from blob storage instead of compute resources.
Operational Best Practices
- Deploy with Infrastructure as Code: Define your Front Door configuration in Bicep or Terraform for repeatability, disaster recovery, and change tracking.
- Enable diagnostic logging: Send Front Door access logs and WAF logs to Log Analytics for traffic analysis, security investigation, and troubleshooting.
- Test failover regularly: Disable one origin periodically to verify that health probes detect the failure and traffic shifts to healthy origins within your expected recovery time.
- Automate cache purges in CI/CD: Add a cache purge step to your deployment pipeline that clears cached content after deploying new versions of your application or static assets.
- Lock down origins: Configure your origins to only accept traffic from Front Door by validating the
X-Azure-FDIDheader or using Private Link (Premium tier). This prevents attackers from bypassing Front Door's WAF by hitting origins directly.
# View Front Door metrics
az monitor metrics list \
--resource /subscriptions/<sub-id>/resourceGroups/rg-frontdoor/providers/Microsoft.Cdn/profiles/afd-myapp-prod \
--metric "RequestCount" "ByteResponseSize" "OriginLatency" "TotalLatency" \
--aggregation Total Average \
--interval PT1H \
--output table
# Enable diagnostic settings for detailed logging
az monitor diagnostic-settings create \
--resource /subscriptions/<sub-id>/resourceGroups/rg-frontdoor/providers/Microsoft.Cdn/profiles/afd-myapp-prod \
--name afd-diagnostics \
--workspace /subscriptions/<sub-id>/resourceGroups/rg-monitoring/providers/Microsoft.OperationalInsights/workspaces/law-central \
--logs '[
{"category": "FrontDoorAccessLog", "enabled": true},
{"category": "FrontDoorHealthProbeLog", "enabled": true},
{"category": "FrontDoorWebApplicationFirewallLog", "enabled": true}
]' \
--metrics '[{"category": "AllMetrics", "enabled": true}]'Key Takeaways
- 1Azure Front Door provides global load balancing, CDN, and WAF in a single service.
- 2Front Door Standard/Premium tiers combine the functionality of classic Front Door and Azure CDN.
- 3WAF policies protect against OWASP Top 10 threats, bot attacks, and rate limiting at the edge.
- 4Custom domains with managed TLS certificates provide secure, branded API and web endpoints.
- 5Health probes and failover ensure automatic routing away from unhealthy origins.
- 6Caching rules and compression optimize delivery performance for static and dynamic content.
Frequently Asked Questions
What is the difference between Front Door and Azure CDN?
When should I use Front Door vs Traffic Manager?
How does Front Door WAF work?
How much does Azure Front Door cost?
Can Front Door connect to origins outside Azure?
Written by CloudToolStack Team
Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.
Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.