Amazon CloudFront CDN
Key concepts
Edge locations and caching
Origin types (S3, ALB, custom)
Cache behaviors
Lambda@Edge
Signed URLs and cookies
Overview
Amazon CloudFront is AWS's content delivery network (CDN), a globally distributed set of caching servers that store copies of your content close to users. When a viewer requests a file, CloudFront serves it from the nearest edge location (a regional cache facility) instead of routing every request back to your origin (the server that holds the authoritative copy). This lowers latency, reduces load on the origin, and absorbs traffic spikes.
This topic is high-yield on the SAA-C03 exam through "reduce latency" and "secure private content" scenarios. You should know what edge locations cache and for how long, the three common origin types (Amazon S3, an Application Load Balancer, and custom HTTP origins), how cache behaviors route requests by path, when to use Lambda@Edge for request and response logic, and how signed URLs and signed cookies restrict access to private content.
Cache at the Edge, Protect at the Edge
CloudFront serves cached content from edge locations near users to cut latency and offload the origin. Cache behaviors decide how each path is cached and which origin answers it, Lambda@Edge customizes requests and responses, and signed URLs or signed cookies gate access to private content.
Map the requirement to the feature: lower global latency for static or dynamic content means CloudFront; restrict a single file means a signed URL; restrict many files behind one auth means signed cookies; rewrite or authorize at the edge means Lambda@Edge for full logic or CloudFront Functions for lightweight header work; lock an S3 bucket so only CloudFront can read it means Origin Access Control (OAC).
Key Concepts
Edge Locations and Caching
How the Edge Cache Works
An edge location is a CloudFront point of presence (POP) that caches your content near viewers. On a cache miss the edge fetches the object from the origin, stores it, and serves later requests from the cache until the object expires. The time an object stays cached is the TTL (time to live), controlled by origin headers such as Cache-Control: max-age or by the minimum, default, and maximum TTL settings on the cache behavior. Regional edge caches sit between edge locations and the origin to improve hit ratios for less-popular content. You shorten or remove cached copies with an invalidation, which marks objects stale before their TTL ends.
Caching Controls
| Control | What it does | Where it is set |
|---|---|---|
| TTL min, default, max | Bounds how long objects stay cached | Cache behavior settings |
| Cache-Control max-age | Per-object freshness from the origin | Origin response headers |
| Invalidation | Removes objects before TTL expires | Distribution invalidation request |
| Cache key | Fields that identify a unique cached object | Cache policy |
Origin Types (S3, ALB, Custom)
Where CloudFront Fetches Content
An origin is the source CloudFront pulls from on a cache miss. An Amazon S3 origin serves static assets and is best locked down with Origin Access Control (OAC) so the bucket stays private and only CloudFront can read it. An Application Load Balancer (ALB) origin or an EC2 origin serves dynamic application traffic. A custom origin is any HTTP server reachable over the public internet, including an on-premises server or a non-AWS endpoint. One distribution can have multiple origins and an origin group can pair a primary and secondary origin for failover.
Common Origin Types
| Origin | Typical content | Access control |
|---|---|---|
| Amazon S3 bucket | Static files, images, video segments | Origin Access Control keeps bucket private |
| Application Load Balancer | Dynamic app responses | Security group plus optional custom header |
| Custom HTTP origin | On-prem or third-party HTTP servers | HTTPS and a shared secret header |
| Origin group | Primary plus failover backup | Failover on configured status codes |
Cache Behaviors
Routing Requests by Path
A cache behavior maps a URL path pattern (for example /images/* or /api/*) to a specific origin and a set of rules. Each behavior controls the allowed HTTP methods, the protocol policy (such as redirect HTTP to HTTPS), the cache policy (which fields form the cache key and the TTLs), and the origin request policy (which headers, cookies, and query strings are forwarded to the origin). The default cache behavior (path pattern *) catches anything that does not match a more specific behavior. CloudFront evaluates behaviors in order of precedence, so put narrow path patterns above the default.
Distribution: shop.example.com
Behavior 1: path "/api/*"
└── Origin: ALB (dynamic), cache disabled or short TTL, forward auth headers
Behavior 2: path "/static/*"
└── Origin: S3 via OAC, long TTL, no cookies in cache key
Default behavior: path "*"
└── Origin: ALB, redirect HTTP to HTTPSCache Policy vs Origin Request Policy
| Aspect | Cache policy | Origin request policy |
|---|---|---|
| Purpose | Defines the cache key and TTLs | Defines what is forwarded to the origin |
| Affects caching | Yes, fields here split the cache | No; excluded from the cache key |
| Includes | Headers, cookies, query strings, TTLs | Headers, cookies, query strings |
| Goal | Higher hit ratio with the right key | Origin gets the data it needs |
Lambda@Edge
Running Code at the Edge
Lambda@Edge runs Node.js or Python functions at CloudFront edge locations so you can customize content without a central server. It hooks into four events: viewer request and viewer response (run for every request and response), and origin request and origin response (run only on a cache miss). Common uses include header-based routing, A/B testing, request authorization, URL rewrites, and adding security headers. For lightweight, high-volume header manipulation and URL rewrites, CloudFront Functions is a cheaper, faster option that runs on the viewer request and viewer response events only.
Lambda@Edge vs CloudFront Functions
| Aspect | Lambda@Edge | CloudFront Functions |
|---|---|---|
| Runtime | Node.js or Python | JavaScript ES5 style |
| Events | Viewer and origin request and response | Viewer request and response only |
| Can call AWS and internet | Yes | No |
| Best for | Authorization, rewrites needing network calls | Header rewrites, redirects, high volume |
Signed URLs and Signed Cookies
Restricting Access to Private Content
For paid or private content you serve through CloudFront, use signed URLs or signed cookies so only authorized viewers can fetch objects. A signed URL grants access to one individual file and is ideal for a single download such as a software installer or a one-off video. Signed cookies grant access to multiple restricted files (for example a whole video library) without changing each URL. Both use a policy that can limit access by expiration time, date range, and source IP. Access is verified with a trusted key group (a set of public keys you upload). Pair this with OAC on an S3 origin so the only path to private objects runs through CloudFront.
Signed URLs vs Signed Cookies
| Need | Signed URL | Signed cookie |
|---|---|---|
| Number of files | One file per signed URL | Many files with one set of cookies |
| Existing URLs | Each URL is replaced | URLs stay unchanged |
| Best for | Single download or stream | Library or member-only area |
| Policy controls | Expiry, date range, source IP | Expiry, date range, source IP |
Best Practices
1. Use OAC for S3 origins
└── Keep the bucket private so only CloudFront can read it
2. Tune the cache key with cache policies
├── Include only fields that change the response
└── Drop unneeded cookies and query strings to raise hit ratio
3. Separate static and dynamic paths with cache behaviors
├── Long TTL on /static/* served from S3
└── Short or no cache on /api/* served from the ALB
4. Pick the right edge compute
├── CloudFront Functions for header rewrites and redirects
└── Lambda@Edge when you need network calls or origin events
5. Protect private content with signed URLs or cookies
├── Signed URL for a single file
└── Signed cookies for many files behind one login
6. Require HTTPS and use AWS Certificate Manager
└── ACM certificates for CloudFront must be issued in us-east-1Common Pitfalls
Pitfall 1: Leaving the S3 Origin Bucket Public
Mistake: Making an S3 bucket public so CloudFront can read it.
Why it fails: Viewers can bypass CloudFront and hit S3 directly, skipping signed URLs, WAF, and logging.
Correct Approach: Keep the bucket private and grant read access to the distribution with Origin Access Control (OAC).
Pitfall 2: Forwarding Everything in the Cache Key
Mistake: Including all headers, cookies, and query strings in the cache key.
Why it fails: Every variation creates a separate cached object, the hit ratio collapses, and most requests fall through to the origin.
Correct Approach: Use a cache policy that includes only fields that change the response, and forward extra fields with an origin request policy when the origin needs them.
Pitfall 3: Requesting the ACM Certificate in the Wrong Region
Mistake: Issuing the TLS certificate for a custom domain in the same Region as the application.
Why it fails: CloudFront reads custom-domain certificates only from AWS Certificate Manager in us-east-1, so the certificate does not appear in the distribution.
Correct Approach: Request or import the certificate in us-east-1 (N. Virginia) for any CloudFront custom domain.
Pitfall 4: Using Lambda@Edge for Simple Header Work
Mistake: Writing a Lambda@Edge function just to add or rewrite headers on every request.
Why it fails: Lambda@Edge costs more and runs slower than needed for trivial header logic at high request volumes.
Correct Approach: Use CloudFront Functions for lightweight header rewrites and redirects, and reserve Lambda@Edge for logic that needs network calls or origin events.
Test Your Knowledge
A media company streams a large video library to paying members and wants to grant access to many video files after one login without changing every file URL. Which CloudFront feature fits best?
An architect must keep an S3 bucket completely private while still serving its objects through CloudFront. What is the recommended configuration?
A site serves static assets that rarely change and API responses that must never be cached. Both share one domain. How should CloudFront be configured?
Related Services
Quick Reference
Well-Known Limits and Defaults
CloudFront Quick Reference
| Item | Value |
|---|---|
| Default object TTL | 24 hours when no Cache-Control is set |
| Max cacheable object size | Up to 50 GB per HTTP GET response |
| Free invalidation paths | First 1000 paths per month at no charge |
| Custom-domain certificate Region | ACM certificate must be in us-east-1 |
| Lambda@Edge events | Viewer request, origin request, origin response, viewer response |
| Private content auth | Signed URLs or signed cookies with a trusted key group |
Common CLI Commands
# Create a distribution from a JSON config
aws cloudfront create-distribution --distribution-config file://dist-config.json
# List distributions
aws cloudfront list-distributions
# Invalidate cached objects before their TTL expires
aws cloudfront create-invalidation \
--distribution-id E123EXAMPLE --paths "/static/*" "/index.html"
# Create a cache policy
aws cloudfront create-cache-policy --cache-policy-config file://cache-policy.json
# Create an origin access control for a private S3 origin
aws cloudfront create-origin-access-control \
--origin-access-control-config file://oac-config.json