Content Delivery Network

A content delivery network places a distributed delivery layer between clients and an application's origin, such as object storage, a load balancer, or a web server. Requests reach an edge location selected through the provider's routing mechanisms, typically based on network conditions and proximity rather than geographic distance alone. When an eligible response is cached there, the edge can serve it without fetching the content from the origin.

For a cache miss, the CDN retrieves the requested content from an upstream cache or the origin and may store it for subsequent requests. This reduces repeated origin work and long-distance transfers. For example, an online retailer can deliver product images, stylesheets, and JavaScript through a CDN while its application servers handle shopping carts and checkout. During a promotion, repeated requests for the same images are largely absorbed by the delivery layer rather than reaching the application infrastructure.

Cache behavior is controlled through expiration settings, HTTP headers, and CDN-specific policies. The cache key determines which requests share a cached response; it commonly includes the URL path and may include selected query parameters, headers, or cookies. Including unnecessary values fragments the cache and reduces the cache hit ratio. Omitting values that genuinely change a response can serve incorrect content or expose one user's information to another. Personalized pages and authenticated API responses therefore need explicit caching and authorization decisions.

Freshness is a deliberate trade-off. Long time-to-live values reduce origin traffic but allow cached content to remain unchanged longer. Versioned asset names, such as an application bundle containing a build identifier, allow long caching periods without delaying releases. Invalidations can remove cached objects before expiration, but propagation takes time and may incur charges. Sensitive responses should use appropriate cache-control directives and policies that prevent unintended shared caching.

CDNs support resilient architectures by distributing request handling and reducing pressure on origins. Some offer origin failover and configurable stale-content serving when an origin fails. However, a CDN does not automatically make a single-region application highly available. Cache misses, expired content, and uncached operations still depend on functioning origins, so critical applications may also require redundant origin capacity and tested failover. A cold cache after a deployment or invalidation can produce a sudden increase in origin traffic.

Security controls commonly include HTTPS, request filtering, and signed URLs or cookies for restricted downloads. Where supported, restrict origin access so users cannot bypass the CDN's controls. An AWS example is allowing a private S3 origin to be accessed through CloudFront origin access control. Viewer authorization and permission for the CDN to access the origin solve different problems and may both be necessary.

A CDN is not limited to static websites: it can deliver media segments and proxy dynamic HTTP traffic, potentially improving connection handling even when responses are not cached. Nevertheless, it is not equivalent to a general-purpose network accelerator. For exam scenarios, choose a CDN when requirements emphasize HTTP-based content delivery, caching, and origin offload. An accelerator such as AWS Global Accelerator addresses network routing for TCP or UDP applications without caching content. Measure cache hit ratio, origin request rate, latency, errors, and total delivery costs to validate the design rather than assuming every workload benefits equally.