What Is CloudFront and Why Use a CDN?
Amazon CloudFront is AWS's content delivery network (CDN), a globally distributed system of edge locations that caches copies of your content physically close to end users, reducing latency and offloading traffic from your origin server. Instead of every request traveling all the way to an S3 bucket or EC2 instance in us-east-1, a user in Mumbai gets content served from a nearby edge location, often in single-digit milliseconds, while CloudFront handles the round trip back to the origin only when content isn't already cached (a 'cache miss') or has expired. Beyond raw speed, CloudFront also provides DDoS protection integration with AWS Shield, TLS termination at the edge, and the ability to run lightweight code at the edge via CloudFront Functions or Lambda@Edge for tasks like header manipulation or A/B testing.
Cricket analogy: CloudFront is like the ICC setting up regional broadcast relay towers around the world instead of every viewer streaming directly from a single studio in Mumbai — fans in London get the feed from a nearby relay, cutting delay dramatically.
Origins and Cache Behaviors
A CloudFront distribution is configured with one or more origins — the source of truth for content, commonly an S3 bucket for static assets or an Application Load Balancer for dynamic content — and cache behaviors, which are path-pattern-based rules that determine how requests matching a given URL pattern (like /images/* or /api/*) are handled, including which origin serves them, what HTTP methods are allowed, and how caching is configured via a cache policy. Cache policies define the cache key, meaning which parts of a request (query strings, headers, cookies) cause CloudFront to treat requests as distinct cacheable objects, and getting this wrong is a common source of bugs — including too many headers in the cache key destroys your cache hit ratio, while including too few can leak one user's personalized content to another.
Cricket analogy: Cache behaviors are like a broadcaster having separate camera feeds for different match situations — the boundary-cam origin handles replays while the main-feed origin handles live action, each routed by a specific rule for what's being shown.
Cache Invalidation and TTLs
Every cached object in CloudFront has a Time to Live (TTL) that determines how long an edge location will serve it before checking back with the origin, and you control this via Cache-Control or Expires headers from the origin, or via minimum/maximum/default TTL settings on the cache policy itself. When you need content refreshed immediately — say, after deploying a bug-fixed JavaScript bundle — you can issue an invalidation request that purges specific paths from all edge caches, though the first 1,000 invalidation paths per month are free and additional ones incur a per-path charge, which is why many teams instead use versioned file names (like app.a1b2c3.js) in their build process so new deployments simply get new URLs rather than requiring invalidation at all.
Cricket analogy: A cache invalidation is like an urgent announcement correcting a wrongly displayed scoreboard across every screen in the stadium simultaneously — necessary but disruptive, whereas simply printing a fresh new scorecard each innings (versioned filenames) avoids the correction entirely.
# Create a CloudFront distribution with an S3 origin
aws cloudfront create-distribution \
--origin-domain-name my-static-site.s3.amazonaws.com \
--default-root-object index.html
# Invalidate a specific path after a deployment
aws cloudfront create-invalidation \
--distribution-id E1A2B3C4D5E6F7 \
--paths "/index.html" "/app.js"
# Recommended: use versioned filenames to avoid invalidation entirely
# <script src="/static/app.a1b2c3.js"></script>
# New deploys generate a new hash, so old cached assets simply expire via TTLCloudFront's first 1,000 invalidation paths per month are free; beyond that, each path is billed. Using content-hashed filenames in your build pipeline (like app.a1b2c3.js) means deployments never require invalidation at all — the new file simply has a new URL.
Including too many request elements (headers, cookies, or query strings) in a cache policy's cache key can destroy your cache hit ratio by fragmenting the cache into thousands of near-identical variants, while including too few can accidentally serve one logged-in user's personalized page to another user — always design cache keys deliberately based on what actually varies the response.
- CloudFront is AWS's CDN, caching content at edge locations close to end users.
- A distribution has one or more origins (S3, ALB) and path-based cache behaviors.
- Cache policies define the cache key from query strings, headers, and cookies.
- TTLs control how long edge locations serve cached content before revalidating with origin.
- Invalidations purge cached paths immediately but are billed after the first 1,000 free paths/month.
- Versioned/hashed filenames avoid the need for invalidation on new deployments.
- CloudFront integrates with AWS Shield for DDoS protection and supports edge compute via Lambda@Edge/CloudFront Functions.
Practice what you learned
1. What is the primary benefit of using CloudFront as a CDN in front of an S3 bucket?
2. What determines which parts of a request CloudFront treats as making an object uniquely cacheable?
3. Why might a team prefer versioned filenames over manual cache invalidation?
4. What risk arises from including too many headers/cookies in a cache policy's cache key?
5. How many invalidation paths does CloudFront provide for free each month?
Was this page helpful?
You May Also Like
AWS Route 53 Basics
Learn how Amazon Route 53 provides scalable DNS, domain registration, and traffic routing policies like weighted, latency-based, and failover routing.
VPC Fundamentals
Learn how Amazon VPC creates an isolated, software-defined network inside AWS, including CIDR planning, default vs custom VPCs, and connectivity options.