CDN Basics
Borrow capacity, heat and geography from the cloud's spine
A CDN caches copies of your content on edge servers near users, so most requests never touch your origin. CloudFront, Azure CDN/Front Door and Cloud CDN all model the same split: edge cache + origin + distribution.
What you will learn
- Explain why a CDN improves latency, cost and reliability
- Trace a request through edge → cache → origin
- Enumerate the knobs a distribution exposes (TTL, methods, geo, headers)
A distribution wires an origin (an LB, bucket, or server) to edge locations worldwide. On a miss the edge fetches from origin, caches per Cache-Control/TTL, and serves subsequent hits locally. Providers vary on product names (CloudFront distribution, Front Door profile, Cloud CDN backend bucket), not on the mental model.
What is this?
Distribution: config wiring origin → behaviors (routes/paths) → cache TTLs → TLS/security. Edge locations: regional caches + PoPs. Common origins: CloudFront → S3 bucket + OAC; Azure Front Door → App Service/Storage; Cloud CDN → Cloud Storage bucket. Request flow: user hits nearest edge → cache lookup → hit (served) or miss (origin fetch, cached for TTL). Content types: static (bundle, images, video) caches fine; personalized/API responses need cache keys that exclude user bits or bypass caching entirely.
Why do you need it?
- Users are a planet away from your origin; an edge with copies kills intercontinental round trips.
- Cached hits offload origin compute and egress — big cost and capacity wins for static assets.
- CDNs absorb traffic spikes (launches, viral posts) that would crush a single origin.
- TLS/termination and DDoS absorption happen at the edge, before your stack sees a byte.
Mental model
Warehouse chains stocking popular items near customers
CDN edge caching
The warehouse near you (edge) serves the common item instantly; when you want something rare (cache miss), the warehouse orders from the central depot (origin) and stocks a copy for the next customer.
How it works
- A DNS CNAME points cdn.example.com at the provider's anycast endpoints.
- The user's resolver picks the nearest PoP; TLS terminates there.
- Edge checks its cache: hit (match + fresh within TTL) → respond immediately.
- Miss or stale → edge fetches from the origin (or uses origin shield to collapse fan-out).
- Edge stores the response honoring Cache-Control; repeats skip the origin until TTL expiry.
CDN request lifecycle.
Examples
Verify caching headers on an asset
curl -sI https://cdn.example.com/app.bundle.js# expect: x-cache: Hit from cloudfront | age: 123 | cache-control: public, max-age=86400The cache headers and x-cache status tell you where the request was served from and for how long the edge will reuse it.
In production
- S3/Cloud Storage static sites served through a CDN with a bucket origin and signed URLs for private objects.
- Terraform deployment of a CloudFront distribution for the frontend build; invalidations on release.
- Azure Front Door in front of an originized API for TLS, WAF and routing on top of caching.
Best practices
- Set explicit Cache-Control (max-age, s-maxage) per asset type — never cache ambiguous TTLs.
- Use immutable hashed filenames for long-lived caching; invalidate only for true rewrites.
- Keep a consistent cache key: version/vary headers, query string handling per behavior.
- Route only cacheable traffic through the CDN; gate personalized responses with bypass rules.
- Pre-warm critical pages after deploys via a purge + targeted fetch.
Common mistakes
- Assuming something is cached — 'it works' but every request is a miss that still hits origin.
- Caching personalized content shared across users by baking user data into the CDN copy.
- Setting max-age monstrously high on un-hashed mutable paths, so stale UI persists for days.
- Forgetting purge/invalidation exists until the 'we updated but the CDN shows the old page' call.
Debugging tips
- curl -sI + x-cache / Age / Via headers reveal hit-vs-miss instantly.
- Compare response of /?nocache=1 against the cached variant to isolate origin drift.
- Check whether the origin itself sets Cache-Control — a CDN cannot invent a TTL.
- Use provider logs (CloudFront real-time logs, Front Door logs) for per-PoP behavior.
Interview checkpoint
Hands-on lab
- Create an S3-backed origin with public read and a distribution
- Serve two asset types with different TTLs via behaviors
- Verify hit vs miss using cache headers
Wire a Static Site Through a CDN Edge
45 min · beginner
Quick quiz
A CDN serves a user a cached copy from the:
How long an edge keeps a cached copy is set by the Cache-Control/TTL the origin returns.