What's changed: Deepened ANS-C01 Chapter 3 (Traffic Flow/health-check types, two edge function types/cache key, GA internals/dial + tables, scenarios, FAQ, traps; ja figures)
3.2Content Delivery with CloudFront
Fast and secure at the edge—understand CloudFront, caching, origins (S3/ALB), origin protection with OAC, and TLS/WAF at the edge. Deliver with low latency from edges worldwide.
CloudFront is a CDN that caches content at edge locations worldwide. Users receive content from the nearest edge for low-latency access.
3.2.1Caching and origin protection
- Cache: on a cache hit, respond at the edge without hitting the origin; only a miss fetches from origin.
- Origins: point to S3 (static) or ALB/API (dynamic, custom origin).
- OAC (Origin Access Control): keep S3 private while allowing access only via CloudFront.
- Edge protection: apply TLS termination, WAF, and edge functions at the edge to cut origin load and attack surface.
Common on ANS-C01: low-latency static delivery = CloudFront, CDN delivery while keeping S3 private = OAC, cache hits do not reach the origin, and TLS/WAF at the edge. To deliver without making S3 public, use OAC (formerly OAI).
CloudFront focuses on HTTP/HTTPS content delivery. For arbitrary TCP/UDP or static-IP, non-HTTP workloads, consider Global Accelerator (next section).
ANS-C01 frequently tests the cache key (which governs hit rate) and the two edge function types. By default the cache key is just the path, but a cache policy can split it by selected headers, query strings, or cookies. Including too much lowers the hit rate, so values only needed at the origin should be forwarded via an origin request policy and kept out of the cache key. Two ways to run edge code: CloudFront Functions are ultra-light, sub-millisecond, viewer request/response only—for header manipulation, redirects, and URL rewrites; Lambda@Edge handles heavier work, can hook origin request/response, and can make external calls and run real logic. For origin protection, make an S3 origin private with OAC; for a custom origin (e.g., an ALB) put a secret in a custom header and validate it with WAF to block direct access from anything but CloudFront. With multiple sources, an origin group enables primary/secondary origin failover.
| Item | CloudFront Functions | Lambda@Edge |
|---|---|---|
| Trigger points | Viewer request/response only | Both viewer and origin events |
| Latency/scale | Sub-ms, extreme scale | Milliseconds+, heavier work |
| External calls | No (self-contained) | Yes (network/SDK) |
| Typical use | Header tweaks, redirects, URL rewrites | Auth, A/B, dynamic origin selection |
Scenario: serve a static S3 site, route certain paths dynamically to an ALB in another region, and rewrite thumbnail URLs at the edge. → Configure two origins/behaviors on CloudFront—S3 (OAC) and ALB (custom origin)—and split work: lightweight URL rewrites in CloudFront Functions, heavier request-based origin selection or auth in Lambda@Edge.
FAQ: Q. Cache hit rate won’t improve? A. Check the cache key isn’t including unnecessary headers/queries/cookies; forward origin-only values via an origin request policy instead. Q. OAI vs OAC? A. OAC is the current recommendation, supporting SSE-KMS, all Regions, and all HTTP methods—use OAC for new work.
Trap: "Lambda@Edge is always faster" is false. It runs heavier logic than CloudFront Functions and is overkill for simple header tweaks or redirects. Use CloudFront Functions for light, high-frequency work and reserve Lambda@Edge for origin events or external calls.
3.2.2Section summary
- Delivery = edge cache; protection = OAC + TLS/WAF
- Origins = S3 (static) / ALB·API (dynamic)
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Deliver static images/videos to global users with low latency and reduce origin load. What?
Q2. Serve an S3 bucket only via CloudFront without making it public. What?
Q3. On a CloudFront cache hit, how is the request handled?