Amazon CloudFront
Master Amazon CloudFront: CDN setup, edge locations, caching strategies, and security features.
What is Amazon CloudFront?
Amazon CloudFront is AWS's content delivery network. A distribution receives a viewer request, selects a matching cache behavior, checks CloudFront's cache layers, and forwards a miss to the configured origin. The origin might be Amazon S3, an Application Load Balancer, API Gateway, MediaPackage, or another HTTP server.
CloudFront matters because network distance and repeated origin work are user-visible costs. Correct caching can shorten response time and protect an origin during a traffic spike. Incorrect caching can expose private content, serve stale data, or multiply origin traffic through unnecessary cache-key variants.
Core invariant
Two requests may share a cached response only when every input that can change that response is represented by the cache key or eliminated through safe normalization.
Public entry
Distribution
Owns the CloudFront hostname, certificates, behaviors, origins, logging, and optional edge-function associations.
Route policy
Cache behavior
Matches a path pattern and chooses the origin, methods, protocol policy, cache policy, origin request policy, and response headers.
Reuse identity
Cache key
Starts with distribution domain and object path, then may include selected query strings, headers, and cookies that genuinely alter the response.
Source of truth
Origin
Produces content on a miss. Its tested capacity and failure behavior remain part of the CDN design even when the average hit rate is high.
Budget the miss path before celebrating the hit rate
The cache hit rate is an outcome, not a capacity plan. A 95% hit rate still sends 5,000 requests per second to the origin during a 100,000 request-per-second event. The origin must also tolerate cold objects, invalidations, fragmented keys, and sudden traffic for uncached URLs.
The lab separates four quantities:
- Viewer requests: all requests entering the distribution.
- Edge misses: viewer requests multiplied by one minus the edge hit rate.
- Duplicate misses: simultaneous misses for the same object that a centralized cache layer may consolidate.
- Origin pressure: modeled origin requests divided by a measured, tested origin capacity.
Protect the origin, not only the average hit rate
Change traffic, cache reuse, and duplicate misses. The model keeps every assumption visible so you can see which requests still reach the origin.
Workload
Origin verdict
The miss path has measured headroom
Modeled origin pressure is 26%. Keep a cache-regression alarm because the origin must survive the failure state, not just today's average.
47,000/s
served without an origin request
3,000/s
forwarded to the next cache layer
1,320/s
26% of tested capacity
1,680/s
teaching estimate, not an AWS guarantee
This is a teaching model, not an AWS performance guarantee or price quote. Replace its inputs with CacheHitRate, origin request counts, origin latency, response classes, object popularity, and load-test evidence from your own distribution.
Trace the request that actually runs
A request may end at the edge, reach a regional cache, pass through Origin Shield, or reach the origin. Viewer-request functions run before the cache lookup. Origin-facing Lambda@Edge triggers run only when CloudFront is going to the origin path. Select each scenario and inspect which components participate.
The important distinction is policy versus path: configuring a component does not mean every request invokes it. A cache hit should not pay for origin work, and a failover origin should not receive traffic until the configured failure criteria are met.
Design a cache key from response variance
Start with the narrowest identity that remains correct. Add a request value only when the origin returns meaningfully different content because of that value.
1 Path
Name the response
Use a stable, versioned object path where possible. A changed immutable asset should receive a new name instead of relying on a broad invalidation.
2 Correctness
List response inputs
Record every query parameter, header, cookie, identity claim, locale, and device signal that can change status, body, or response headers.
3 Reuse
Normalize noise
Remove tracking values, order-insensitive differences, and defaults that do not alter the response. Normalize before the cache lookup.
4 Security
Test isolation
Prove that two users, tenants, or authorization states cannot receive each other's private response through a shared cache key.
Common key decisions
- Include a query string when it chooses the returned resource or representation.
- Exclude analytics and campaign parameters when they do not alter the response.
- Forward a value to the origin without caching on it only when the origin needs the value but the response remains reusable.
- Prefer signed URLs or signed cookies for private-content authorization rather than inventing an unaudited token scheme.
- Never cache an authenticated response merely because its path appears public.
The official cache-key guide explains the default key and how cache policies add request values.
Select the edge-compute boundary deliberately
Viewer events
CloudFront Functions
Use lightweight JavaScript for redirects, URL rewrites, header changes, validation, and cache-key normalization at viewer request or viewer response time.
Four event phases
Lambda@Edge
Use it when the logic needs an origin event, more execution resources, supported libraries, or capabilities outside the CloudFront Functions runtime.
Business authority
Origin service
Keep database access, durable state changes, complex authorization, and business rules in a service with explicit ownership and observability.
This viewer-request function removes known tracking parameters while preserving values that may change the response. Treat the allowlist as an application contract and test it with representative URLs.
AWS documents the current runtime and event differences in its edge-function comparison.
Operate freshness and failure as product behavior
Freshness controls
- Use origin
Cache-Controldirectives and a cache policy whose minimum, default, and maximum TTLs preserve the product's freshness promise. - Version immutable assets so normal deployments do not depend on wildcard invalidations.
- Decide how errors are cached; a long error TTL can preserve an outage after the origin recovers.
- Separate content classes into behaviors instead of forcing one TTL and key policy on every route.
Failure controls
- Load-test the origin with the miss rate expected during a cache regression.
- Use bounded timeouts and failover criteria that do not retry unsafe writes.
- Protect private S3 origins with Origin Access Control rather than a public bucket.
- Alarm on origin request rate, origin latency, error rate, cache hit rate, and unexpected cache-key dimensions.
- Keep logs sufficient to distinguish hit, miss, error, function failure, and origin response behavior.
Origin Shield adds another cache layer and can consolidate simultaneous misses for the same object. AWS's Origin Shield documentation describes where it sits and how it reduces origin load.