CloudFront & Content Delivery
AWS's global CDN — caching content at edge locations close to users to cut latency and offload traffic from your origin servers.
Want a visual for this topic?
Generate a diagram tailored to CloudFront & Content Delivery — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain how a CDN reduces latency and origin load
- •Configure a CloudFront distribution in front of S3 or an ALB origin
- •Explain cache invalidation and why it's needed
- •Distinguish CloudFront Functions from Lambda@Edge and when to use each
What is it?
Amazon CloudFront is AWS's Content Delivery Network (CDN) — a global network of edge locations that cache copies of your content (images, videos, JS/CSS, or even dynamic API responses) physically close to your users, so requests are served from a nearby edge location instead of traveling all the way to your origin server every time.
Why it exists
A user in Tokyo requesting a file from a server in Virginia experiences real network latency just from the physical distance — light itself takes meaningful time to cross that distance, before any server processing even begins. CloudFront exists to eliminate most of that distance by serving cached content from an edge location near Tokyo instead, dramatically cutting latency, while simultaneously protecting the origin server from having to handle every single request itself.
Problem it solves
It solves the geographic latency problem (edge locations are much closer to users worldwide than any single origin Region), the origin load problem (a popular file served from cache doesn't hit your origin server at all, protecting it from traffic spikes), and the availability problem (CloudFront can continue serving cached content even during a brief origin outage, depending on cache settings).
Intuition
Think of CloudFront like a chain of local warehouses for an online retailer instead of one central warehouse: if a product is popular, copies are pre-positioned at warehouses near customers, so delivery is fast and the central warehouse isn't overwhelmed processing every single order — only when a warehouse doesn't have a copy does it request one from the central warehouse (the origin).
Analogy
A national newspaper printed at hundreds of local print shops near readers, rather than one central printing press shipping physical papers across the country — readers get today's paper fast because printing happens locally from a master copy, and the central press only needs to distribute the master, not every physical copy.
Technical explanation
A CloudFront Distribution ties together one or more Origins (S3 buckets, Application Load Balancers, or any custom HTTP origin), Cache Behaviors (rules per URL path pattern controlling caching, allowed methods, and which viewer headers/cookies/query strings affect cache key), and edge configuration (SSL certificate, allowed HTTP methods, geographic restrictions). Origin Access Control (OAC, the modern replacement for the older Origin Access Identity) ensures an S3 origin is only reachable through CloudFront, not directly via its public S3 URL, so you can keep the bucket itself fully private while still serving its content publicly through the CDN.
Architecture
A common pattern: a CloudFront distribution serves static assets (images, JS, CSS) from an S3 origin with OAC restricting direct bucket access, while a separate cache behavior on the same distribution routes API paths (e.g. /api/*) to an ALB origin with caching disabled or minimal, since API responses are typically dynamic and user-specific. This lets one CloudFront distribution and one domain name front both a static frontend and a dynamic backend.
Workflow
- Create the origin (S3 bucket or ALB) first. 2) Create a CloudFront distribution pointing at that origin. 3) For an S3 origin, set up Origin Access Control and update the bucket policy to allow only CloudFront to read it. 4) Configure cache behaviors — TTLs, which query strings/headers/cookies to include in the cache key, and path-based routing to different origins if needed. 5) Attach a custom domain and SSL certificate (via ACM) if not using the default cloudfront.net domain. 6) Set up cache invalidation or versioned file names for your deployment process.
Example
A media company serves video thumbnails and metadata through CloudFront: thumbnails (rarely-changing images) are cached at edge locations for 24 hours, cutting origin S3 requests by over 95% during peak viewing; the metadata API (frequently changing) is proxied through CloudFront with caching disabled, using CloudFront mainly for connection optimization and DDoS protection at the edge rather than content caching for that path.
Real-world usage
Netflix uses a purpose-built CDN (Open Connect) for its enormous video traffic but relies on standard CDN patterns identical in principle to CloudFront's edge-caching model; most content-heavy websites and SaaS products front their static assets with CloudFront specifically to cut both latency for global users and S3/origin data transfer costs, since CloudFront's data transfer pricing is often more favorable than direct S3-to-internet transfer at scale.
Trade-offs
Longer cache TTLs maximize cache hit rate (less origin load, faster average response) but mean content updates take longer to reach users without an explicit invalidation; shorter TTLs keep content fresher but reduce the caching benefit and increase origin load. Cache invalidation gives immediate freshness on demand but costs money per invalidation path and isn't instant globally; a versioned-filename deployment strategy (e.g. app.v2.js instead of app.js) avoids invalidation costs entirely by making 'new content' simply a new, uncached URL, at the cost of needing a build process that manages those version identifiers.
Visual explanation
Picture a user's request hitting the nearest of CloudFront's hundreds of edge locations first. If that edge location has a cached, still-valid copy (a cache hit), it returns immediately — the origin is never contacted. If not (a cache miss), the edge location fetches the content from the origin (S3, an ALB, or any HTTP server), returns it to the user, AND caches it for the next request to that edge location, following the caching rules you've configured (Cache-Control headers, TTL settings).
Advantages
- —
Dramatically reduces latency for geographically distributed users by serving from nearby edge locations
- —
Offloads repeated requests from the origin, protecting it from traffic spikes and reducing origin infrastructure cost
- —
Built-in integration with AWS Shield for DDoS protection and AWS WAF for request filtering at the edge
- —
Origin Access Control lets you keep an S3 bucket fully private while still serving its content publicly through the CDN
Disadvantages
- —
Cached content can go stale if invalidation or cache-busting isn't handled correctly, serving outdated content to users
- —
Adds a layer of indirection that can complicate debugging — a fix pushed to the origin may not be visible until the cache expires or is invalidated
- —
Cache invalidation requests have a cost and aren't instantaneous across all edge locations
- —
Dynamic, highly personalized content gets little to no benefit from caching and needs careful cache-behavior configuration to avoid accidentally caching user-specific data for the wrong user
Common mistakes
- —
Leaving an S3 bucket origin publicly readable directly (not restricted to CloudFront via OAC), defeating the point of using CloudFront for access control and allowing traffic to bypass the CDN entirely
- —
Setting overly long TTLs on frequently-changing content and being surprised users see stale data with no invalidation triggered
- —
Including unnecessary query strings, headers, or cookies in the cache key, fragmenting the cache into many near-duplicate entries and tanking the cache hit rate
- —
Caching API responses that include user-specific or sensitive data without properly scoping the cache key to the user, potentially serving one user's data to another
- —
Forgetting to update the S3 bucket policy after switching from the legacy Origin Access Identity to the newer Origin Access Control, breaking origin access
In the AWS Console
- 1
AWS Console → CloudFront → Distributions → Create distribution
Select your origin (choose an S3 bucket or enter an ALB/custom origin domain), and for an S3 origin, choose 'Origin access control settings' and create a new OAC.
After creating the distribution, CloudFront shows a bucket policy snippet you must copy into the S3 bucket's permissions — this step is easy to miss and results in 403 errors until done.
- 2
Distributions → [your distribution] → Behaviors → Create behavior
Set the path pattern (e.g. /api/*), choose the appropriate origin, and configure the cache policy — for dynamic content, select or create a policy with caching disabled or a very short TTL.
Behaviors are evaluated in order of specificity, not the order listed — CloudFront automatically matches the most specific path pattern first.
- 3
Distributions → [your distribution] → Invalidations → Create invalidation
Enter the path(s) to invalidate (e.g. /images/logo.png or /* for everything), which forces CloudFront to re-fetch from the origin on the next request to that path across all edge locations.
The first 1,000 invalidation paths per month are free; beyond that there's a small per-path charge — using versioned filenames instead avoids this cost for frequent deploys.
- 4
Distributions → [your distribution] → General → Edit → Custom SSL certificate
Attach an ACM certificate (must be requested in us-east-1 regardless of where your other resources live) and add your custom domain as an alternate domain name.
ACM certificates for CloudFront specifically must be issued in the us-east-1 Region — a certificate issued elsewhere won't appear in the CloudFront selection dropdown.
🎤 Interview questions
How does CloudFront reduce latency for users far from your origin server? (Listen for: caches content at edge locations physically close to users, serving from cache instead of round-tripping to the origin on every request.)
What's the purpose of Origin Access Control, and what happens without it? (Listen for: restricts an S3 origin to be reachable only through CloudFront; without it, the bucket may be directly publicly accessible, bypassing the CDN and any edge-level protections.)
How would you serve fresh content immediately after a deploy without waiting for cache TTLs to expire? (Listen for: create a CloudFront invalidation for the affected paths, or use versioned/hashed filenames so new deploys are automatically uncached new URLs.)
Why might including a session cookie in the CloudFront cache key be dangerous? (Listen for: risk of serving one user's cached, personalized response to a different user if the cache key doesn't properly scope by that cookie's actual value — or conversely, fragmenting the cache badly if it's included unnecessarily.)
When would you choose Lambda@Edge over a CloudFront Function? (Listen for: CloudFront Functions are lightweight, sub-millisecond, JavaScript-only, for simple header/URL manipulation; Lambda@Edge supports full Node.js/Python with more execution time and memory, for heavier logic like origin selection or complex request/response transformation.)