Skip to main content
AzureNetworkingintermediate

Front Door & CDN Guide

Configure Azure Front Door and CDN for global content delivery, including routing, WAF policies, caching, SSL/TLS, and performance optimization.

CloudToolStack Team24 min readPublished Feb 22, 2026

Prerequisites

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

ConceptDescription
EndpointA globally unique hostname (e.g., myapp.z01.azurefd.net) that receives traffic
Origin GroupA collection of backend origins that serve the same content (for load balancing and failover)
OriginA backend service (App Service, Storage, VM, custom hostname) that serves content
RouteRules that map incoming requests to origin groups based on path, protocol, and headers
Rule SetCollections of rules for request/response manipulation (rewrite URLs, add headers, redirect)
Security PolicyWAF policy attached to an endpoint for security protection
Custom DomainYour own domain name (e.g., www.myapp.com) pointed to the Front Door endpoint
Terminal: Create Azure Front Door with origins
# 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 Enabled

Azure 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 TierProviderFeaturesBest For
Azure Front Door StandardMicrosoftCDN + basic routing + basic WAFWebsites needing CDN with light WAF
Azure Front Door PremiumMicrosoftCDN + advanced routing + managed WAF + Private LinkEnterprise apps with strong security needs
Azure CDN Standard from EdgioEdgio (Verizon)Traditional CDN, rules engine, real-time analyticsMedia streaming, large file downloads
Azure CDN Standard from AkamaiAkamai (retiring)Traditional CDN, broad PoP coverageLegacy 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

MethodHow It WorksWhen to Use
Latency-basedRoutes to the origin with lowest measured latencyDefault; best for most web applications
PriorityRoutes to highest priority origin; lower priority used as failoverActive/passive DR with a clear primary region
WeightedDistributes traffic proportionally based on weight valuesCanary deployments, gradual traffic migration
Session AffinityRoutes subsequent requests from same user to same originStateful applications that store session data locally
Terminal: Configure routing rules and rule sets
# 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 IgnoreQueryString

WAF 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.

Terminal: Create and configure WAF policy
# 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-endpoint

WAF 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

OptionManagementUse Case
Front Door ManagedAutomatic provisioning and renewalMost scenarios (zero-touch certificate management)
Bring Your Own (Key Vault)You manage certificates in Azure Key VaultEV certificates, specific CA requirements, wildcard certs
Terminal: Configure custom domain with managed certificate
# 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-com

Caching 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.

Terminal: Configure caching rules
# 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

SettingRecommendationWhy
Path/health or /healthzUse a dedicated health endpoint, not the homepage
ProtocolHTTPSMatch production traffic protocol
MethodHEADReduces probe bandwidth; GET if you need body validation
Interval30 secondsBalance between detection speed and origin load
Sample Size4Number of recent probes to consider
Successful Samples3How 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.

FeatureAzure Front DoorAzure CDN (Edgio)Azure Traffic Manager
LayerLayer 7 (HTTP/HTTPS)Layer 7 (HTTP/HTTPS)Layer 4 (DNS-based)
Traffic HandlingProxies traffic through edgeProxies traffic through edgeDNS resolution only (no data path)
WAFYes (built-in, managed rules)LimitedNo
CachingYesYes (primary focus)No
SSL OffloadingYesYesNo (passthrough)
RoutingURL path, header, method-basedLimited rules engineGeographic, performance, weighted, priority
Health ProbesHTTP/HTTPS at origin levelHTTP/HTTPSHTTP/HTTPS/TCP at endpoint level
Non-HTTP ProtocolsNo (HTTP/HTTPS only)NoYes (any TCP/UDP protocol)
Best ForWeb apps needing CDN + WAF + routingStatic content-heavy sites, media deliveryNon-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-revalidate patterns, 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-FDID header or using Private Link (Premium tier). This prevents attackers from bypassing Front Door's WAF by hitting origins directly.
Terminal: Monitor Front Door performance
# 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

  1. 1Azure Front Door provides global load balancing, CDN, and WAF in a single service.
  2. 2Front Door Standard/Premium tiers combine the functionality of classic Front Door and Azure CDN.
  3. 3WAF policies protect against OWASP Top 10 threats, bot attacks, and rate limiting at the edge.
  4. 4Custom domains with managed TLS certificates provide secure, branded API and web endpoints.
  5. 5Health probes and failover ensure automatic routing away from unhealthy origins.
  6. 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?
Front Door Standard/Premium has unified classic Front Door and Azure CDN into one service. Front Door provides Layer 7 global load balancing, WAF, and CDN caching. For new deployments, use Front Door Standard or Premium tier, as separate Azure CDN profiles are the legacy approach.
When should I use Front Door vs Traffic Manager?
Front Door works at Layer 7 (HTTP/HTTPS) with caching, WAF, and URL-based routing. Traffic Manager works at the DNS level (Layer 3) for non-HTTP protocols. Use Front Door for web applications; use Traffic Manager for non-HTTP workloads or as a complement to Front Door.
How does Front Door WAF work?
Front Door WAF applies security rules at the edge before requests reach your origin. It supports managed rule sets (OWASP Top 10, bot protection), custom rules (IP filtering, geo-filtering, rate limiting), and exclusion lists. WAF runs in detection or prevention mode.
How much does Azure Front Door cost?
Standard tier: $35/month base + per-request and data transfer charges. Premium tier: $330/month base with advanced WAF and Private Link support. Data transfer charges range from $0.08-$0.16/GB depending on zone. There is no free tier for Front Door.
Can Front Door connect to origins outside Azure?
Yes. Front Door supports any publicly accessible HTTP/HTTPS endpoint as an origin, including Azure services, on-premises servers, and other cloud providers. Premium tier also supports Private Link origins for Azure-hosted backends.

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.