Cloud CDN — CloudFront vs Cloud CDN vs Azure CDN/Front Door

A CDN caches your content at edge locations around the world so users hit a nearby server instead of reaching all the way back to your origin. The concept is simple. Getting a good cache hit ratio out of a managed CDN — where every unnecessary header or cookie in the cache key torpedoes your performance — is where things get interesting.

AWS CloudFront

CloudFront is a full-featured CDN that's tightly integrated with the rest of AWS. The core building blocks:

Distributions are the top-level CloudFront resource — one distribution gets one domain name (e.g., d1234.cloudfront.net) and one or more origins. An origin is where CloudFront fetches content when it doesn't have a cached copy: an S3 bucket, an ALB, a custom HTTP server, or even another CloudFront distribution.

Behaviors are the routing rules within a distribution. Each behavior matches a URL path pattern (/api/*, /images/*, *) and defines the cache policy, origin, allowed HTTP methods, and whether to compress responses. The default behavior (*) catches everything else.

Cache policies control the cache key — which combination of headers, cookies, query strings, and compression encoding determines whether two requests hit the same cached object. Origin request policies control what gets forwarded to the origin. These are separate, and confusing the two is a common source of cache misses.

OAC (Origin Access Control) restricts S3 origins so they're only accessible through CloudFront, not directly via the S3 URL. It replaces the older OAI mechanism. Always use it for S3 origins — otherwise users can bypass your CDN (and your WAF, and your geo-restrictions) by going straight to the bucket.

Lambda@Edge and CloudFront Functions let you run code at the edge. CloudFront Functions are lightweight (JavaScript only, sub-millisecond, viewer request/response only) — good for header manipulation, URL rewrites, and simple A/B testing. Lambda@Edge is heavier (Node.js/Python, can run on viewer and origin events, has network access) — good for auth at the edge, dynamic origin selection, or generating responses.

Price classes let you restrict which edge locations CloudFront uses. Price Class 100 uses only the cheapest regions (US, Europe). Price Class 200 adds Asia. Price Class All uses everything. If most of your users are in North America and Europe, restricting the price class saves money without meaningfully impacting latency.

Invalidations purge cached content before the TTL expires. They're free up to 1,000 paths per month, then $0.005 each. Don't use invalidations as your cache management strategy — use versioned URLs (/app.abc123.js) so the old and new versions coexist. Invalidations are for emergencies, not deploys.

GCP Cloud CDN

Cloud CDN isn't a standalone product — it's a checkbox on the global HTTP(S) load balancer. You enable Cloud CDN on a backend service or backend bucket and configure cache policies. This integration is elegant: there's no separate distribution to manage, no origin configuration to duplicate. Your load balancer IS your CDN origin.

Cache modes control behavior: CACHE_ALL_STATIC caches responses with standard static content types, USE_ORIGIN_HEADERS respects Cache-Control headers from your backend, and FORCE_CACHE_ALL caches everything (be careful with this one around authenticated content).

GCP's cache key defaults to the full URL including query string. You can customize it to include or exclude host, protocol, query string parameters, and HTTP headers. Signed URLs and signed cookies control access to cached content.

The main limitation: Cloud CDN has fewer edge locations than CloudFront and less edge compute capability. If you need Lambda@Edge-style processing, you're looking at Cloud Functions or Cloud Run behind the load balancer, not code at the CDN edge.

Azure Implementation

Azure offers two CDN approaches:

Azure Front Door is the modern choice — a global L7 load balancer with integrated CDN, WAF, and DDoS protection. It caches content at Microsoft's edge network and routes dynamic requests to the nearest healthy origin. Think of it as CloudFront + ALB + WAF in one service. Front Door supports rules engine for URL rewrites, header manipulation, and routing decisions at the edge.

Azure CDN profiles (classic) come in multiple tiers: Microsoft, Akamai, and Verizon. Microsoft is phasing these into Front Door. For new projects, start with Front Door.

Front Door's caching is controlled through caching rules in the routing configuration. You can cache by query string, customize cache duration, and bypass cache for specific paths. It supports compression and HTTP/2 natively.

Cache Key Configuration — Where Hit Rate Lives or Dies

Your cache hit ratio is the single most important CDN metric. A 95% hit ratio means 5% of requests reach your origin. Drop to 50% and you've halved your CDN's effectiveness while still paying for it.

The cache key determines when two requests are "the same" and can share a cached response. Every element you include in the cache key fragments your cache:

• Query strings: /page?utm_source=twitter and /page?utm_source=facebook are different cache keys if you include utm_source. Forward only the query parameters your origin actually needs. Strip analytics parameters at the edge.
• Headers: forwarding Accept-Language means separate cache entries per language (often correct). Forwarding User-Agent means separate entries per browser version (almost never correct — use Accept-Encoding instead).
• Cookies: forwarding all cookies means every logged-in user gets their own cache entry, which is equivalent to no caching at all. Forward only the cookies your origin needs for the specific path.

The number one CDN misconfiguration: forwarding all headers and cookies to the origin, which also includes them in the cache key, which means nothing is ever a cache hit.

Shared Concepts Across Providers

TTL hierarchy: CDN-configured TTL, Cache-Control header from origin, Expires header from origin. The specifics of precedence vary by provider and configuration, but the principle is the same: be explicit about TTLs, don't rely on defaults.

Origin shield (CloudFront) / cache fill optimization (GCP) adds an intermediate cache tier between edge locations and your origin. Instead of 200 edge locations each making cache-miss requests to your origin, they check the shield first. Reduces origin load during cache busts.

Compression: all providers support gzip and Brotli at the edge. Enable it. Compressing a 500KB JavaScript bundle to 80KB saves bandwidth and improves load time.

HTTP/3 (QUIC): CloudFront, GCP, and Front Door all support it. HTTP/3 improves performance on lossy connections (mobile networks) by eliminating TCP head-of-line blocking. Enable it unless you have a specific reason not to.

WAF and DDoS at the edge: AWS WAF with CloudFront, Cloud Armor with GCP's load balancer, WAF with Front Door. Filtering malicious traffic at the edge means it never reaches your origin. This is where rate limiting, geo-blocking, and bot mitigation belong.

Custom domains and TLS: all providers support custom domains with managed TLS certificates. On AWS, use ACM certificates in us-east-1 (CloudFront requires this region). On GCP, Google-managed certificates handle renewal automatically. On Azure, Front Door manages certificates or you bring your own via Key Vault.

Side-by-Side Comparison

Aspect	AWS CloudFront	GCP Cloud CDN	Azure Front Door
Architecture	Standalone CDN	Checkbox on global LB	Global LB + CDN + WAF
Edge locations	400+	100+	170+
Edge compute	Lambda@Edge + CF Functions	Limited (Cloud Functions behind LB)	Rules engine
Cache key control	Cache policies (granular)	Per-backend config	Caching rules
Origin shield	Yes	Cache fill optimization	N/A (Microsoft edge network)
WAF integration	AWS WAF (separate service)	Cloud Armor (separate service)	Built-in
Certificate management	ACM (must be us-east-1)	Google-managed	Front Door managed or Key Vault

Measuring CDN Performance

Cache hit ratio is your headline metric. Measure it by bytes and by requests — they tell different stories. A 95% hit ratio by requests but 60% by bytes means your large files aren't being cached. Target 90%+ for static content, and investigate anything below 80%.

When hit ratio drops, check: did someone change the cache policy to forward new headers? Did a deploy change query string patterns? Is a new feature setting cookies on paths that were previously anonymous?

Key Takeaways

• Cache key configuration is where CDN performance lives or dies — forward only the headers, cookies, and query strings your origin actually needs
• Use versioned URLs for assets instead of cache invalidations; invalidations are for emergencies, not deployments
• GCP Cloud CDN is uniquely integrated into the global load balancer rather than being a separate product
• Origin shield reduces origin load by consolidating cache-miss requests through an intermediate tier
• CloudFront has the largest edge network and the most edge compute options; GCP is simplest to configure; Front Door bundles CDN + WAF + global LB
• Monitor cache hit ratio continuously — a drop usually means someone changed a forwarding policy or a deploy introduced new cache-busting query parameters

Next, we'll look at message queues — the asynchronous backbone that decouples the services sitting behind these CDNs and load balancers.