What is a content delivery network (CDN)?

The problem: distance is latency, and origins have limits

Every request a user makes has to travel to a server and back, and the round trip takes longer the further away the server is. A web page is not one request but dozens — the page itself, images, scripts, styles — so the delay multiplies, and an application that feels instant near its servers can feel sluggish an ocean away. No amount of server power fixes this, because the bottleneck is distance, not capacity.

The second problem sits at the origin — the server, storage bucket or application actually holding your content. If every user everywhere fetches everything directly from it, the origin does the same work over and over, serving identical files millions of times. Popularity becomes a threat: enough simultaneous demand, whether a viral success or a deliberate flood, and the origin buckles. Both problems share a root cause — every request travelling to one place — and a CDN removes it by making one place into many.

How a CDN works: edge locations and caching

A CDN operates a network of edge locations — often called points of presence — spread across cities worldwide, deliberately close to where users actually are. This is a finer-grained layer than the regions and availability zones where your application runs (the idea covered in our regions-and-AZs explainer): your origin lives in a region, while the CDN’s edge stretches far beyond it. When a user requests your content, the request is directed to the nearest edge location rather than to your origin.

What happens next is caching. If the edge already holds a copy of the requested file — a cache hit — it responds immediately, and the request never touches your origin. If it does not — a cache miss — the edge fetches the file from the origin, serves it to the user and keeps a copy for the next person nearby. Each cached copy carries a time-to-live (TTL): how long the edge may serve it before checking back with the origin for a fresh version. Long TTLs suit content that rarely changes; short ones keep frequently updated content current. The upshot is that popular content is fetched from the origin rarely and served from the edge constantly — users get speed, and the origin gets quiet.

What CDNs are used for

The classic use, and still the biggest, is static content — the files that are the same for every user:

• Static assets — images, scripts, stylesheets, fonts and downloads, the bulk of most pages’ weight and the easiest wins for caching.
• Media delivery — video and audio streaming, where serving from nearby edges is the difference between smooth playback and buffering.
• Whole static sites — sites built as fixed files can be served entirely from the edge, with an origin that is little more than storage.
• Dynamic acceleration — even uncacheable, personalised responses benefit, because the CDN carries them over its own optimised network routes rather than the open internet.
• Security at the edge — modern CDNs absorb distributed denial-of-service traffic across their global capacity, filter malicious requests with web application firewalls, and terminate TLS close to users.

CDNs on AWS and Azure

AWS’s CDN is Amazon CloudFront. It serves content from AWS’s network of edge locations, integrates naturally with S3 storage buckets and load balancers as origins, and pairs with AWS’s edge security services for DDoS protection and request filtering. A very common AWS pattern — and a favourite of exam scenarios — is a static website in S3 delivered worldwide through CloudFront.

On Azure, the modern flagship is Azure Front Door, which combines global content delivery with layer 7 load balancing and a web application firewall in one service; Azure CDN covers classic content-delivery caching. The mental model transfers directly from one cloud to the other: an origin in a region, edges near users, caching rules and TTLs deciding what is served from where. As ever, the vendors’ names differ more than their ideas do.

The honest limits

A CDN is not a universal accelerator. Content that is unique to every request — a personalised dashboard, a live account balance — cannot be cached, so the edge can only speed its journey, not eliminate it. Caching also introduces the one hard problem it always introduces: staleness. Update a file at the origin and edges may keep serving the old copy until its TTL expires, which is why cache invalidation — telling the CDN to discard copies early — and versioned file names are standard working practices.

None of this diminishes the case. For the large share of traffic that is cacheable, a CDN delivers lower latency, a lighter origin and a broad security shield with very little application change — which is why putting one in front of a public site is close to a default decision rather than an optimisation.

Where CDNs appear in certification study

On the AWS track, CloudFront enters at the foundational level: the Cloud Practitioner exam expects you to know what a CDN is, that CloudFront is AWS’s implementation, and that edge locations are distinct from regions and availability zones. The Solutions Architect Associate goes further, using CloudFront in scenario questions — accelerating a global audience, fronting S3 static sites, and combining the CDN with edge security services for protection at the perimeter.

On the Azure side, AZ-900 expects the same conceptual layer: what content delivery is for and which Azure services provide it. If you can explain a cache hit versus a miss, what a TTL controls and why edge locations differ from regions, you have the concept the exams are probing — the service-level specifics belong to the content-delivery and storage lessons in our revision sections.