How Azure and GCP do what CloudFront, Route 53 and ELB do on AWS (AWS CloudFront Deep Dive, AWS Route 53 Deep Dive, AWS Elastic Load Balancing Deep Dive). Networking context: 3. Azure Networking, 1. GCP Fundamentals.

Services at a glance

Azure Front Door

Global entry point: CDN, TLS termination, routing, WAF and failover in one service, using Microsoft's edge network.

flowchart LR
    V[Viewer] --> E[Front Door endpoint: xxx.azurefd.net]
    E --> R{Route + rule set}
    R --> OG1[Origin group: web]
    R --> OG2[Origin group: api]
    OG1 --> O1[App Service / Storage / VM]
    OG2 --> O2[AKS ingress / Container Apps]
    W[WAF policy] -.-> E

Caching

• Enable caching per route; Front Door honours origin Cache-Control unless a rule set overrides the duration
• Query string behaviour: ignore, use each unique query, or include / exclude listed parameters (controls the cache key)
• Compression for text types
• Purge removes cached content:

$ az afd endpoint purge --resource-group rg-web --profile-name fd-prod \
    --endpoint-name www --content-paths '/*' '/images/*'

Headers, security and domains

• Rule set actions add or override response headers such as HSTS, CSP, X-Content-Type-Options: 3. HTTP Security Headers and CSP
• Restrict the origin to Front Door by checking the X-Azure-FDID header (your Front Door ID) and the AzureFrontDoor.Backend service tag
• DNS: CNAME the custom domain to the endpoint (apex via alias in Azure DNS); add the TXT validation record
• WAF policy modes: Detection or Prevention; custom rules, rate limiting, geo filtering

Azure's older CDN offerings (CDN profiles) are being phased out in favour of Front Door; check the current status in the Azure docs before starting new work.

Azure Application Gateway, Load Balancer and Traffic Manager

Rule of thumb: Front Door for global web apps, Application Gateway for regional L7 behind it, Load Balancer for non-HTTP, Traffic Manager for DNS-level failover across anything.

GCP Cloud CDN and Load Balancing

Cloud CDN is switched on for a backend (a backend service or backend bucket) behind the global external Application Load Balancer; there is no separate "distribution".

flowchart LR
    V[Viewer] --> FE[Global anycast IP + forwarding rule]
    FE --> HP[Target HTTPS proxy + certificate]
    HP --> UM[URL map: host and path rules]
    UM --> BS[Backend service + Cloud CDN]
    UM --> BB[Backend bucket + Cloud CDN]
    BS --> MIG[Instance groups / NEGs / Cloud Run]
    BB --> GCS[(Cloud Storage)]
    CA[Cloud Armor policy] -.-> BS

Cache modes

• Set default, minimum and maximum TTLs and client TTL
• Cache keys: include or exclude protocol, host, query string and selected headers or cookies; fewer values mean a better hit ratio
• Custom response headers can be added on the backend service (for HSTS and other security headers)
• Signed URLs and cookies protect private content
• Negative caching and serve stale options reduce load during errors

$ gcloud compute backend-services update web-backend --global \
    --enable-cdn --cache-mode=CACHE_ALL_STATIC --default-ttl=3600

$ gcloud compute url-maps invalidate-cdn-cache web-map --path "/*"
$ gcloud compute url-maps invalidate-cdn-cache web-map --host www.example.com --path "/images/*"

Invalidation takes a short time to propagate and has rate limits; prefer versioned filenames.

Load balancer families

Cloud DNS and Cloud Armor

• Cloud DNS: public and private zones, routing policies (weighted round robin, geolocation, failover), DNSSEC, 100% availability SLA
• Cloud Armor: WAF and DDoS protection attached to a backend service: preconfigured rules (OWASP-style), rate limiting, IP and geo rules, adaptive protection

Choosing Across Clouds

Common ideas apply everywhere: keep the cache key small, set explicit Cache-Control at the origin, version asset filenames, keep origins private so traffic must go through the edge, add security headers at the edge, and purge deliberately instead of relying on it.