Microsoft Azure — Azure CDN & Front Door

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers azure cdn & front door with production-ready configurations, best practices, and hands-on examples.

Why Azure CDN and Front Door Are Not Interchangeable

Many teams treat Azure CDN and Front Door as the same service because both accelerate content delivery. That's a mistake that leads to outages. Azure CDN is a content delivery network optimized for static assets: images, videos, JavaScript bundles. It caches at edge locations and reduces origin load. Front Door is a global load balancer and application accelerator. It handles dynamic requests, SSL termination, path-based routing, and Web Application Firewall (WAF) policies. Front Door can also cache, but its primary value is intelligent traffic routing across origins. Choosing the wrong one means either paying for features you don't need or missing critical capabilities like failover and DDoS protection. For example, using CDN for an API gateway will break session affinity and failover. Use CDN for static content, Front Door for applications.

az cdn profile create --name myCDNProfile --resource-group myRG --sku Standard_Microsoft
az cdn endpoint create --name myEndpoint --profile-name myCDNProfile --resource-group myRG --origin www.example.com --origin-host-header www.example.com

Architecture: When to Use CDN, Front Door, or Both

A common production pattern is to place Front Door in front of your application and then use CDN for static assets served from blob storage. Front Door handles routing, SSL, WAF, and caching of dynamic responses. CDN offloads static content delivery from the application servers. For example, an e-commerce site: Front Door routes /api/ to App Service, /images/ to CDN backed by Blob Storage. This reduces origin load by 70% and improves cache hit ratios. Front Door also provides health probes and automatic failover between regions. CDN is simpler and cheaper for static content. If you only need global caching and don't need routing or WAF, use CDN. If you need anycast, path-based routing, or WAF, use Front Door. Both can coexist: Front Door can point to CDN as an origin for static content, but that adds latency. Better to let Front Door cache static content directly or use CDN as a separate endpoint.

resource "azurerm_frontdoor" "main" {
  name                = "my-frontdoor"
  resource_group_name = azurerm_resource_group.main.name
  routing_rule {
    name               = "api-route"
    accepted_protocols = ["Http", "Https"]
    patterns_to_match  = ["/api/*"]
    frontend_endpoints = ["my-frontend"]
    forwarding_configuration {
      backend_pool_name = "app-backend"
      cache_enabled     = false
    }
  }
  routing_rule {
    name               = "static-route"
    accepted_protocols = ["Http", "Https"]
    patterns_to_match  = ["/static/*"]
    frontend_endpoints = ["my-frontend"]
    forwarding_configuration {
      backend_pool_name = "cdn-backend"
      cache_enabled     = true
      cache_duration    = "365.23:59:59"
    }
  }
}

Configuring Caching Rules: Purge, Compression, and Query Strings

Caching rules determine what gets cached and for how long. In Front Door, you can set cache duration per route. For CDN, you can configure caching rules at the endpoint or global level. Key settings: cache expiration (set to a reasonable TTL based on content volatility), query string caching (ignore, bypass, or include), and compression (enable gzip/brotli). A common mistake is caching everything with a long TTL, which causes stale content. For versioned assets (e.g., bundle.v1.js), use a long TTL (1 year). For HTML pages, use a short TTL (5 minutes) or no cache. Always enable compression to reduce bandwidth. Purge is critical when you need to invalidate cached content immediately. Use purge after deployments or content updates. In production, automate purges via CI/CD pipelines. For example, after a new release, purge the CDN endpoint for the changed files.

# Purge specific paths after deployment
$resourceGroup = "myRG"
$profileName = "myCDNProfile"
$endpointName = "myEndpoint"
$paths = @("/index.html", "/js/app.*")

Remove-AzCdnEndpointContent `
  -ResourceGroupName $resourceGroup `
  -ProfileName $profileName `
  -EndpointName $endpointName `
  -ContentPath $paths

Write-Output "Purge initiated for $($paths -join ', ')"

Health Probes and Failover: Avoiding Single Points of Failure

Front Door continuously monitors backend health using HTTP/HTTPS probes. You configure the probe path (e.g., /health), interval (default 30s), and failure threshold. If a backend fails health checks, Front Door routes traffic to healthy backends. This is essential for multi-region deployments. Common pitfalls: using a static page like /index.html as the health endpoint (it never fails), setting the probe interval too low (causes false positives), or not configuring a proper health check that validates dependencies (database, cache). In production, your health endpoint should return 200 only if the service is truly ready. Also, configure the backend pool with multiple origins and set priority/weight for active-passive or active-active failover. For CDN, health probes are not available; CDN relies on origin response status codes. If your origin returns 503, CDN may cache it. Use Front Door for critical failover scenarios.

from flask import Flask, jsonify
import redis
import psycopg2

app = Flask(__name__)

@app.route('/health')
def health():
    health_status = {"status": "healthy"}
    try:
        r = redis.Redis(host='redis-service', port=6379, socket_connect_timeout=2)
        r.ping()
    except Exception as e:
        health_status["redis"] = str(e)
        health_status["status"] = "unhealthy"
    try:
        conn = psycopg2.connect("dbname=app user=app password=pass host=db", connect_timeout=2)
        conn.close()
    except Exception as e:
        health_status["db"] = str(e)
        health_status["status"] = "unhealthy"
    return jsonify(health_status), 200 if health_status["status"] == "healthy" else 503

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

Web Application Firewall (WAF) with Front Door

Front Door integrates with Azure WAF to protect against common web exploits like SQL injection, XSS, and DDoS. You can attach a WAF policy to a Front Door frontend endpoint or a routing rule. WAF policies consist of managed rule sets (e.g., OWASP 3.2) and custom rules. Managed rules provide baseline protection; custom rules allow you to block or allow specific IPs, geo-filter, or rate-limit. In production, start in detection mode to log violations without blocking, then switch to prevention after tuning. Common mistakes: enabling all managed rules without testing (causes false positives), not excluding false positives (e.g., blocking legitimate SQL queries), or not setting up rate limiting for APIs. Also, WAF logs are sent to Azure Monitor; enable diagnostic settings to capture them. For CDN, WAF is not available; use Front Door if you need WAF.

{
  "type": "Microsoft.Network/frontDoorWebApplicationFirewallPolicies",
  "apiVersion": "2022-05-01",
  "name": "myWAFPolicy",
  "location": "Global",
  "properties": {
    "policySettings": {
      "enabledState": "Enabled",
      "mode": "Prevention"
    },
    "managedRules": {
      "managedRuleSets": [
        {
          "ruleSetType": "Microsoft_DefaultRuleSet",
          "ruleSetVersion": "2.1",
          "ruleSetAction": "Block",
          "exclusions": []
        }
      ]
    },
    "customRules": [
      {
        "name": "RateLimit",
        "priority": 1,
        "ruleType": "RateLimitRule",
        "rateLimitDurationInMinutes": 1,
        "rateLimitThreshold": 100,
        "matchConditions": [
          {
            "matchVariable": "RemoteAddr",
            "operator": "IPMatch",
            "selector": null,
            "negateCondition": false,
            "matchValue": ["*"]
          }
        ],
        "action": "Block"
      }
    ]
  }
}

SSL/TLS Termination and Certificate Management

Both CDN and Front Door support SSL termination at the edge. You can bring your own certificate or use Azure-managed certificates. For production, use Azure-managed certificates for simplicity: they auto-renew and are free. However, if you need custom certificates (e.g., EV certificates), you can upload them to Azure Key Vault and reference them. Front Door supports multiple SSL certificates per frontend endpoint. A common issue is certificate validation failures due to mismatched hostnames. Ensure the certificate's CN or SAN matches the custom domain. Also, enable HTTPS-only traffic and set minimum TLS version to 1.2. For CDN, you can enable HTTPS on custom domains via Azure CDN's managed certificate or your own. In production, always enforce HTTPS and redirect HTTP to HTTPS. Use Front Door's redirect rule to achieve this.

# Enable HTTPS on a CDN custom domain using Azure-managed certificate
az cdn custom-domain enable-https `
  --profile-name myCDNProfile `
  --endpoint-name myEndpoint `
  --resource-group myRG `
  --name www.example.com `
  --user-cert-subscription-id "" `
  --min-tls-version 1.2

# For Front Door, enable HTTPS via frontend endpoint
az network front-door frontend-endpoint update `
  --front-door-name myFrontDoor `
  --resource-group myRG `
  --name myFrontend `
  --session-affinity-enabled true `
  --custom-https-configuration "{\"certificateSource\":\"FrontDoor\",\"protocolType\":\"ServerNameIndication\",\"minimumTlsVersion\":\"1.2\"}"

Geo-Routing and Traffic Management with Front Door

Front Door supports geo-routing via routing rules and backend pools. You can direct traffic from specific countries to specific backends. For example, route EU traffic to a West Europe App Service and US traffic to East US. This reduces latency and can comply with data residency requirements. Geo-routing is configured using match conditions on the routing rule: you can match on country code. Additionally, you can use priority and weight to implement active-passive or active-active failover. In production, combine geo-routing with health probes: if the primary region fails, traffic fails over to the secondary region regardless of geography. A common mistake is not setting up a fallback backend for unmatched geographies. Always configure a default backend pool.

{
  "properties": {
    "routingRules": [
      {
        "name": "GeoRouteEU",
        "properties": {
          "frontendEndpoints": [{"id": "frontend-id"}],
          "acceptedProtocols": ["Http", "Https"],
          "patternsToMatch": ["/*"],
          "enabledState": "Enabled",
          "routeConfiguration": {
            "@odata.type": "#Microsoft.Azure.FrontDoor.Models.FrontdoorForwardingConfiguration",
            "backendPool": {"id": "eu-backend-pool-id"},
            "cacheConfiguration": null,
            "forwardingProtocol": "MatchRequest",
            "backendPoolCacheSetting": null
          },
          "rulesEngine": null,
          "matchConditions": [
            {
              "name": "CountryMatch",
              "matchVariable": "RemoteAddr",
              "operator": "GeoMatch",
              "negateCondition": false,
              "matchValue": ["DE", "FR", "GB"],
              "selector": null,
              "transforms": []
            }
          ]
        }
      }
    ]
  }
}

Monitoring, Logging, and Alerts

Monitoring CDN and Front Door is critical for production. Enable diagnostic settings to stream logs to Log Analytics, Storage, or Event Hubs. Key metrics: request count, latency, cache hit ratio, backend health, and error rates. For Front Door, monitor health probe status and backend response times. For CDN, monitor cache hit ratio and origin offload. Set up alerts for anomalies: e.g., sudden drop in cache hit ratio (indicates misconfiguration), increase in 5xx errors (origin issues), or backend health probe failures. Use Azure Monitor workbooks to create dashboards. A common oversight is not logging WAF blocked requests; enable WAF logs to detect attacks. Also, log purge operations to audit content invalidation. In production, set up alerts for backend health probe failures with a severity of 1 (critical).

# Enable diagnostic settings for Front Door
az monitor diagnostic-settings create \
  --name "frontdoor-logs" \
  --resource /subscriptions/.../providers/Microsoft.Network/frontDoors/myFrontDoor \
  --workspace /subscriptions/.../workspaces/myLogAnalytics \
  --logs '[{"category": "FrontdoorAccessLog", "enabled": true}, {"category": "FrontdoorWebApplicationFirewallLog", "enabled": true}]' \
  --metrics '[{"category": "AllMetrics", "enabled": true}]'

# Create alert for backend health probe failure
az monitor metrics alert create \
  --name "BackendHealthAlert" \
  --resource-group myRG \
  --scopes /subscriptions/.../providers/Microsoft.Network/frontDoors/myFrontDoor \
  --condition "avg BackendHealthPercentage < 90" \
  --description "Alert when backend health drops below 90%" \
  --evaluation-frequency 5m \
  --window-size 15m \
  --severity 1

Cost Optimization: Choosing the Right SKU and Caching Strategy

Azure CDN and Front Door have different pricing models. CDN Standard (Microsoft) is pay-as-you-go with no upfront cost. Front Door has a fixed monthly fee plus data transfer costs. For low-traffic sites, CDN is cheaper. For high-traffic with dynamic content, Front Door's fixed fee may be more cost-effective. Optimize costs by: using caching to reduce origin traffic (cache hit ratio > 90% is ideal), compressing responses, and choosing the right SKU. For CDN, Standard Microsoft is sufficient for most cases; Premium (Verizon) offers advanced analytics but costs more. For Front Door, the standard tier is adequate; premium adds private link support. Also, consider using Azure Storage static website with CDN for static content to reduce compute costs. In production, monitor bandwidth and request counts to right-size. Use Azure Cost Management to track spending.

# Estimate monthly cost for Front Door (example)
# Assumptions: 100 GB outbound data, 10 million requests
# Front Door Standard: $0.06 per GB outbound, $0.01 per 10k requests
# Fixed monthly fee: $0 (no fixed fee for Standard? Actually Front Door has a monthly fee ~$35)
# This is a rough estimate; use Azure Pricing Calculator for accurate numbers.
echo "Estimated monthly cost: $35 (fixed) + $6 (data) + $10 (requests) = $51"

CI/CD Integration: Automating Deployments and Purges

Integrate CDN and Front Door into your CI/CD pipeline to automate deployments and cache purges. Use Azure CLI or ARM templates to update Front Door routing rules, backend pools, and WAF policies. For CDN, automate purges after each deployment. Example pipeline: build, test, deploy to App Service, then purge CDN endpoints. Use Azure DevOps or GitHub Actions. Store configuration as code (ARM, Bicep, Terraform) to enable repeatable deployments. A common mistake is not purging after deployment, causing users to see old content. Also, use deployment slots with Front Door to enable blue-green deployments: swap slots and then purge. In production, automate everything to reduce human error.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- task: AzureCLI@2
  displayName: 'Deploy App Service'
  inputs:
    azureSubscription: 'myServiceConnection'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az webapp deployment source config-zip \
        --resource-group myRG \
        --name myAppService \
        --src $(Build.ArtifactStagingDirectory)/app.zip

- task: AzureCLI@2
  displayName: 'Purge CDN Endpoint'
  inputs:
    azureSubscription: 'myServiceConnection'
    scriptType: 'bash'
    scriptLocation: 'inlineScript'
    inlineScript: |
      az cdn endpoint purge \
        --resource-group myRG \
        --profile-name myCDNProfile \
        --name myEndpoint \
        --content-paths "/*"

Troubleshooting Common Issues: 503s, Cache Misses, and SSL Errors

Common issues with CDN and Front Door include 503 errors (origin unavailable), cache misses (low cache hit ratio), and SSL errors. For 503s, check backend health probes and origin response times. Ensure the origin is reachable from the edge. For cache misses, verify caching rules: are you caching the right content? Check cache headers from origin (Cache-Control, Expires). If origin sends no-cache, CDN won't cache. For SSL errors, check certificate validity and hostname match. Use tools like curl to test: curl -I https://yourdomain.com. Also, check Front Door logs for detailed error codes. A common pitfall is not enabling caching on the route in Front Door (cacheEnabled: false). In production, set up a dashboard with key metrics to quickly identify issues.

# Check cache headers from origin
curl -I https://origin.example.com/static/style.css
# Expected: Cache-Control: public, max-age=31536000

# Check Front Door response headers
curl -I https://myfrontdoor.azurefd.net/static/style.css
# Look for X-Cache: HIT or MISS

# Test health probe endpoint
curl -I https://origin.example.com/health

Production Checklist: Go-Live with CDN and Front Door

Before going live, run through this checklist: 1) Configure custom domains with HTTPS (Azure-managed certificates). 2) Set up WAF in detection mode initially. 3) Configure health probes with dependency checks. 4) Set caching rules per content type. 5) Enable diagnostic logs and set up alerts. 6) Test failover by stopping a backend. 7) Verify cache purge works. 8) Check geo-routing if used. 9) Review cost estimates. 10) Document the architecture. Common go-live failures: forgetting to enable HTTPS, not configuring health probes (causes routing to unhealthy backends), or not purging old content. Also, test with real traffic patterns using a staging environment. In production, always have a rollback plan: keep old configuration files and be ready to redeploy.

# Production Go-Live Checklist

- [ ] Custom domains configured with HTTPS (Azure-managed certs)
- [ ] WAF enabled in detection mode
- [ ] Health probes configured with dependency checks
- [ ] Caching rules set per content type
- [ ] Diagnostic logs enabled (access, WAF, metrics)
- [ ] Alerts set for backend health, cache hit ratio, 5xx errors
- [ ] Failover tested by stopping a backend
- [ ] Cache purge tested
- [ ] Geo-routing verified (if used)
- [ ] Cost estimates reviewed
- [ ] Architecture documented