Why architecture matters here
Architecture matters here because the CDN sits on the critical path of every user request, and its two jobs — cutting latency and protecting the origin — are both won or lost by the cache-hit ratio. A high hit ratio means most requests are served from an edge a few milliseconds away and never touch your origin; a low hit ratio means users pay the full round-trip to origin plus the extra hop through CloudFront, which is worse than no CDN at all. Every architectural decision in a CDN — the tiering, the cache-key design, the TTLs — is ultimately in service of keeping that hit ratio high, because that single number determines whether the CDN is helping or hurting.
The origin-protection angle is just as important as latency. A CDN with a good hit ratio acts as a massive shock absorber: a viral spike or a traffic flood is absorbed by the edge fleet's enormous aggregate capacity, and your origin — which might be a modest set of servers or an S3 bucket — sees only the trickle of cache misses. This is what lets a small origin serve a global audience and what makes CloudFront a first-class DDoS mitigation, because volumetric attacks are absorbed and filtered at the edge before they reach anything you have to scale. Take the CDN away and the same traffic would have to be handled by origin capacity you would have to provision and pay for continuously.
The tiered design exists precisely because a flat CDN — many edge caches all pulling independently from origin — would give poor origin protection for anything but the most popular objects. With hundreds of PoPs, a moderately popular object might be evicted from each individual PoP often enough that origin still sees substantial miss traffic. Inserting the regional edge caches and Origin Shield as consolidation tiers means misses funnel through progressively fewer, larger caches, so the origin's view of demand is smoothed and collapsed. The architecture is a hierarchy specifically engineered to convert 'popular somewhere' into 'cached somewhere upstream,' which is what makes the origin's load nearly independent of global request volume.
Finally, pushing security and logic to the edge is an architectural decision with latency and blast-radius consequences. Terminating TLS at the PoP means the expensive handshake happens close to the user over a short RTT, and the long-haul segment to origin rides a warm, reused connection — a large latency win invisible in origin metrics. Running WAF and Shield at the edge means malicious traffic is dropped before it consumes any origin or application resource, shrinking the attack surface to what the edge chooses to forward. And running functions at the edge lets you personalize, redirect, or authorize without a round trip to origin, moving work to where it is cheapest and closest. The edge is not just a cache tier; it is the first place you get to make decisions about a request.
The architecture: every piece explained
Start with the distribution, CloudFront's top-level configuration object. It binds one or more origins (where the real content lives — an S3 bucket, an Application Load Balancer, or any HTTP server) to a set of cache behaviors that match request path patterns and decide, per pattern, how to cache and route. A behavior specifies the origin, the allowed HTTP methods, the protocol policy (redirect HTTP to HTTPS), the TTLs, and — most importantly — the cache-key policy that determines what makes two requests 'the same object.'
The cache key is the crux of CDN correctness and efficiency. By default the key is the request path, but you can include selected query-string parameters, headers, and cookies. This is a double-edged sword: include a value that genuinely changes the response (like an Accept-Encoding that selects gzip vs brotli, or a language header) and you cache the right variants; include a value that does not change the response (a random analytics query parameter, a per-user cookie on shared content) and you fragment the cache into millions of near-duplicate entries, destroying the hit ratio. Cache-key and origin-request policies let you specify exactly which components are part of the key versus merely forwarded to origin, which is the single most consequential tuning knob in the whole system.
The caching tiers are the PoP, the regional edge cache, and optionally Origin Shield. A viewer connects to the nearest PoP (chosen by anycast and DNS). On a PoP miss, CloudFront routes to the regional edge cache associated with that PoP; on a regional miss, to Origin Shield if enabled, then to the origin. Each tier caches according to the object's TTL, which is governed by origin Cache-Control / max-age headers or by the behavior's min/default/max TTL settings, and revalidated using validators like ETag and Last-Modified so an unchanged object can be refreshed cheaply with a 304 instead of a full re-fetch. Request collapsing at each tier ensures that many simultaneous misses for the same object become a single upstream fetch.
Around the caching core sit the edge capabilities. TLS termination happens at the PoP with certificates managed through ACM. AWS WAF and Shield filter and absorb malicious traffic at the edge. CloudFront Functions (a lightweight JavaScript runtime for sub-millisecond viewer-request/response manipulation like header rewrites, URL normalization, and simple auth) and Lambda@Edge (fuller Node/Python functions for origin-request/response logic) let you run code at the edge. And Origin Access Control (OAC) signs CloudFront's requests to a private S3 origin so the bucket can deny all public access and trust only CloudFront — the correct way to serve private content without exposing the origin.
End-to-end flow
Trace a request for /assets/app.v7.js. The viewer's browser resolves the distribution's domain to the nearest PoP by anycast, opens a TLS connection that terminates at that PoP, and sends the GET. CloudFront computes the cache key from the path and the behavior's cache-key policy. On the first request of the day this is a miss at the PoP, so CloudFront forwards to the regional edge cache; that is also a miss, so (with Origin Shield enabled) it forwards to the shield cache, another miss, and finally to the origin — an S3 bucket locked down with OAC. S3 returns the object with an ETag and a long max-age. The object is cached at the shield, the regional cache, and the PoP on the way back, and served to the viewer. Every tier now holds a warm copy.
A second viewer in the same city requests the same object seconds later. This time it is a hit at the PoP: CloudFront serves the cached bytes directly, a few milliseconds away, without any upstream communication at all. A viewer in a different city whose PoP shares the same regional edge cache gets a PoP miss but a regional hit — the object is served from the regional tier without touching Origin Shield or origin. This is the tiering paying off: the object was fetched from origin exactly once, yet it is now serving hits across many PoPs in the region.
Now consider a flash crowd: the object's TTL expires just as a popular post drives ten thousand simultaneous requests to one PoP. Without protection, all ten thousand would miss and stampede the origin. CloudFront's request collapsing prevents this: the PoP sends a single revalidation request upstream and holds the other requests until the response returns, then serves them all from the refreshed cache entry. Because the object was only conditionally changed, the origin returns a cheap 304 and the PoP resets the TTL. Ten thousand viewer requests became one conditional upstream request, and the origin never felt the spike.
Finally, consider a request that needs edge logic. A viewer requests a path that requires a country-based redirect and a security header. A CloudFront Function attached to the viewer-request event inspects the CloudFront-Viewer-Country header, rewrites the URI to the localized path, and returns — all in well under a millisecond, before the cache lookup, so the localized object is served from cache on the very same request. On the response side, another function stamps security headers (HSTS, CSP) onto every response. No origin round trip was needed for either transformation; the edge did the work, which is both faster for the user and cheaper for the origin, and it illustrates why the edge is the natural home for request-shaping logic that does not depend on origin state.