CloudFront vs Traditional CDN: What's Changed and Why It Matters

Traditional CDNs and CloudFront both cache content close to users. That is where the resemblance ends. CloudFront runs code at the edge, filters traffic before it reaches your origin, and makes routing decisions mid-request. A traditional CDN does none of that by default. For static, heavily cacheable workloads, the difference barely matters. For dynamic, API-driven applications on AWS, it matters quite a lot.

Why traditional CDNs are no longer enough

CDNs were designed around one assumption: most content is static and shared across users. Cache a file at the edge, serve it from there, avoid the round trip to origin. That works extremely well for images, stylesheets, fonts, and JavaScript bundles with long cache TTLs.

Modern applications broke that assumption. A single page load on a contemporary SaaS product can trigger dozens of API calls returning user-specific data, tokens, feature flags, and personalised responses. None of those are cacheable the way a JPEG is. Traditional CDNs, built around the shared-static-content model, offer no meaningful help for that traffic. The requests pass through to origin unchanged.

Security created a second gap. Traditional CDNs were built to deliver content, not to inspect or transform it. Adding a Web Application Firewall typically meant routing through a separate layer, with the latency overhead that comes with it. For applications under sustained attack, bolting security onto a delivery-focused architecture is awkward at best.

The practical outcome: teams running traditional CDNs in front of modern applications often end up paying for geographic distribution while most of their traffic bypasses caching entirely and hits origin anyway. They get the cost without the benefit on the requests that matter most.

Understanding traditional CDN architecture

Traditional CDN architecture has three components: Points of Presence, a caching layer, and a routing mechanism.

Figure 1: Traditional CDN request flow showing DNS/Anycast routing, a single edge cache layer, and origin retrieval on cache misses.

Points of Presence are physical data centers distributed geographically. PoP density directly affects performance: the more PoPs a provider operates, the shorter the network path between a user and cached content. Edge servers at each PoP cache content locally. When a user requests a file, they are directed to the nearest PoP. Cache hit: the file returns immediately. Cache miss: the edge fetches from origin, caches the response, and serves future requests from cache.

Routing uses one of two mechanisms, and major providers combine both. DNS-based routing returns different IP addresses to different users based on location. When a user queries cdn.example.com, they receive the IP of a nearby PoP. Anycast routing is faster: multiple PoPs advertise the same IP via BGP, and the internet's routing protocol delivers each request to the announcing node with the lowest route cost. Anycast does not depend on DNS resolver cache behaviour, which means it reacts to real-time network conditions rather than stale geographic mappings.

Caching is controlled by HTTP cache-control headers and TTLs set on the origin. An object with a 24-hour TTL stays cached at the edge for 24 hours. Once the TTL expires, the edge re-validates with origin or evicts the object. For static assets with long TTLs, this is efficient and reduces origin load substantially. For content with short TTLs, no-cache headers, or user-specific responses, the edge provides no benefit.

This architecture is reliable and well-understood. Akamai, Fastly, and Cloudflare all operate on variations of it, with their own optimisations layered on top. The ceiling is not a flaw in the architecture; it is the scope the architecture was designed for.

How Amazon CloudFront has evolved beyond content delivery

CloudFront launched as a standard CDN. It has been extended substantially since, and what it does now is better understood as a programmable edge platform that also handles content delivery.

Figure 2: CloudFront extends the traditional CDN model by introducing a multi-tier cache hierarchy and programmable edge compute. Requests are first evaluated at the global edge network, followed by Regional Edge Caches and an optional Origin Shield layer before reaching the origin. CloudFront Functions and Lambda@Edge allow request processing at the edge, reducing latency, improving cache efficiency, and lowering origin load.

Multi-layer caching

CloudFront operates three distinct cache tiers. Edge PoPs sit closest to users: 750+ locations across 440+ cities globally. Regional Edge Caches sit between edge PoPs and the origin. There are 15 of them globally, and they hold a larger cache than individual PoPs, which keeps less-popular objects cached closer to users instead of going to origin on every miss. Origin Shield adds a third optional tier: a single designated Regional Edge Cache that consolidates all origin requests. If 50 edge PoPs miss on the same object simultaneously, only one request goes to origin. AWS has published that Origin Shield reduces origin load by up to 57% for workloads like live streaming and high-volume image serving. For any origin running real compute, that directly affects cost.

Edge computing with CloudFront Functions and Lambda@Edge

CloudFront Functions runs lightweight JavaScript at every edge location. Execution is sub-millisecond. The use cases are things that need to happen on every request, fast: HTTP header manipulation, URL rewrites, cache-key normalisation, and conditional routing. A CloudFront Function can inspect which edge location is serving a request, determine the nearest AWS region, and on a cache miss forward the request to the closest origin without involving a centralised routing service.

Lambda@Edge runs at Regional Edge Caches, not at every PoP. It supports heavier logic: execution up to 30 seconds, Node.js 22 and Python 3.13, and calls to other AWS services like DynamoDB or S3 mid-request. The tradeoff is that Regional Edge Caches are fewer and farther away than PoPs, so Lambda@Edge adds a few milliseconds compared to CloudFront Functions. A/B testing, JWT validation, and dynamic content assembly are common Lambda@Edge patterns.

The combination means you can run very lightweight logic at every edge location and heavier logic at a regional layer, without any of it involving a round trip to origin.

Security integration

AWS WAF, AWS Shield Advanced, and AWS Certificate Manager integrate directly with CloudFront distributions. WAF rules run at the edge, which means malicious traffic is filtered before it touches the origin. CloudFront supports TLS 1.3 by default and has added post-quantum key exchange algorithms. For context on scale: CloudFront peaked at 268 Tbps during a major game release, with WAF and delivery running simultaneously.

Beyond protocol support, CloudFront also operates 1,140+ embedded PoPs inside ISP networks across 100+ providers. Those embedded PoPs cache large content catalogs inside the ISP, reducing reliance on the public internet path between the edge city and the user's device. This is particularly useful for video and large file distribution.

AWS ecosystem integration

A CloudFront distribution can serve static assets from S3 and API traffic from an Application Load Balancer using different cache behaviours per URL path pattern. Origin groups provide automatic failover between primary and backup origins. CloudFront Functions can also override which origin handles a specific request dynamically, enabling percentage-based traffic splitting without changing the distribution configuration. That kind of flexibility is either unavailable or substantially more complex to achieve with a third-party CDN in front of an AWS backend.

CloudFront vs traditional CDN: key differences

A few of these need more context than a table cell allows.

On dynamic content: traditional CDNs pass non-cacheable requests to origin with minimal modification. CloudFront keeps persistent TCP connections open between edge locations and origin servers, so each cache miss does not pay a full TCP handshake. For applications handling many uncacheable API requests, this reduces per-request latency without any caching involved.

On cost: CloudFront's pricing is not simple. Data transfer out rates vary by geography, Origin Shield is charged per request routed through it, and Lambda@Edge invocations are billed separately. The flat-rate plans bundle CDN, WAF, DDoS protection, and DNS into a single monthly fee, which is easier to budget for teams with stable traffic. Anyone accustomed to straightforward per-GB pricing from a traditional CDN should model CloudFront costs carefully before committing.

When should you choose CloudFront?

Static sites are where traditional CDNs and CloudFront are most interchangeable. Cloudflare or Fastly will serve static assets just as fast, with simpler pricing and no AWS dependency. If the stack is not on AWS, there is no strong reason to prefer CloudFront here.

Enterprise SaaS applications are where CloudFront has a clear advantage. Personalised dashboards, authenticated API calls, and region-aware routing all benefit from Lambda@Edge and CloudFront Functions running in the request path. On a traditional CDN, either all non-cacheable traffic goes to origin unchanged, or you maintain a separate edge compute layer alongside the CDN. CloudFront handles both in one distribution.

Streaming platforms benefit from CloudFront's MediaPackage integration and its embedded PoPs inside ISP networks. Cache hit rates for large media files are meaningfully higher when the cache sits inside the ISP rather than only at the nearest edge city.

API-heavy applications gain from how CloudFront handles uncacheable traffic. Persistent connections and Origin Shield request collapsing reduce per-request overhead at scale. A service handling high request volumes will see real origin capacity savings compared to taking the same traffic as raw internet requests.

Multi-region AWS deployments are the clearest fit. Native support for multiple origins, automatic failover via origin groups, and dynamic origin selection via CloudFront Functions make it the natural front door for any architecture spanning more than one AWS region.

Where CloudFront fits less well: purely static sites outside AWS, workloads with hard vendor-diversity requirements, or situations where AWS lock-in is a genuine constraint.

What's shaping CDN infrastructure decisions

Edge compute is now expected, not optional. Running logic at the CDN layer, rather than sending every non-trivial request back to origin, has become standard for production applications. Frameworks with edge runtime modes assume compute infrastructure at the CDN layer. Traditional CDNs without native edge compute are catching up, but CloudFront has had it for years and has extended it significantly.

Security runs at the edge. WAF rules, bot detection, and DDoS mitigation that execute at the edge prevent malicious traffic from ever reaching the origin. For high-traffic applications this is not optional equipment; it is the first line of defense. CDNs that treat security as a bolt-on add latency and operational complexity. CloudFront integrates it natively.

HTTP/3 is deployed, not experimental. Cloudflare puts global HTTP/3 traffic at 35% of all requests. Among the highest-traffic sites, adoption is above 50%. CloudFront supports it natively via QUIC. The practical benefit is on mobile and degraded networks, where QUIC's handling of packet loss and connection migration produces noticeably faster page loads. Treat HTTP/3 support as a baseline expectation when evaluating CDN infrastructure.

CDN egress cost is a real FinOps line item. At scale, unpredictable per-GB pricing creates budget problems. CloudFront's flat-rate plans give teams with predictable traffic volumes more control over spending. Multi-CDN setups, where overflow traffic routes to a cheaper provider during spikes, are appearing at enterprise scale. The operational complexity is real, but so are the savings at high egress volumes.

Final thoughts

Traditional CDNs are good at what they were built for: getting static files from origin to user quickly and reliably. For that workload they still work well.

The problem is that most production applications are not that workload anymore. They need logic in the request path, security enforcement at the edge, dynamic routing based on application state, and integration with backend services. CloudFront has been built and extended to handle those requirements. Traditional CDNs are working to close the gap.

If your edge layer only needs to carry traffic, a traditional CDN is sufficient. If it needs to participate in how your application handles each request, CloudFront is the right choice, especially when the rest of your stack is already on AWS.