Cloud Parts

CDNs

Copies of your content cached close to your users.

3 technologies on this page ↓
Live model
What you’re watchingViewers in Tokyo and London hit their nearest edge. Most requests are served from the edge cache; only misses make the long trip to the origin.

How it works

A content delivery network runs hundreds of edge locations around the world. Users connect to the nearest one. If it has a cached copy of the file it answers immediately; if not, it fetches from your origin once and keeps the copy for everyone nearby. CDNs also absorb traffic spikes and attacks and terminate TLS at the edge.

Think of it as

A bookstore chain stocking bestsellers in every local branch instead of shipping each copy from the central warehouse.

Reach for it when

  • Static assets: JavaScript, CSS, images, video
  • Global audiences far from your origin region
  • Shielding your origin from spikes and DDoS attacks

Think twice when

  • Highly personalized responses that can’t be cached, unless you add edge compute
  • Content that must change everywhere instantly, since invalidation takes time

A real example

A web app’s origin is in Virginia, roughly 150 ms from Tokyo for every round trip. A user in Tokyo loads the 2 MB JavaScript bundle from a nearby Tokyo edge instead, and the origin serves one request instead of millions.

Technologies

Specific products, and what each does differently.

What each provider calls it

AWS
CloudFront
Google Cloud
Cloud CDN
Azure
Front Door
Open source & others
Varnish; also Cloudflare, Fastly, Akamai

See it in a real stack

Architectures that use cdns

Serverless web app on AWSCloudFront serves the site from S3 and sends API calls through API Gateway to Lambda functions backed by DynamoDB.Amazon CloudFrontAmazon S3Amazon API GatewayAWS LambdaAmazon DynamoDBCQRS with a static read sideCommands update PostgreSQL; a Lambda projector rewrites the affected JSON views in S3, and CloudFront serves every read without touching a database.Amazon API GatewayAWS LambdaPostgreSQLAmazon SQSAmazon S3Amazon CloudFront

In code · http

# Headers from the origin tell every edge how long to cache
HTTP/1.1 200 OK
Content-Type: application/javascript
Cache-Control: public, max-age=31536000, immutable
ETag: "app.9f2c1e.js"

Often confused with

CachingLoad balancersObject storageDNSIn-process cachesLoad balancer, API gateway or CDN?In-process cache, shared cache or CDN?
Where it came from1997–2025

In the mid-1990s a website lived on one server or a small cluster, and every visitor in the world went there. When a site suddenly became popular it was swamped, and the traffic congested the network around it. A 1997 MIT paper listed famous cases: NASA JPL’s site after comet Shoemaker-Levy 9 struck Jupiter, and IBM’s during the Deep Blue–Kasparov chess match, where users were denied access for hours or even days. Shared proxy caches helped, but the more users shared one, the more likely it was to be swamped itself.

Tim Berners-Lee challenged colleagues at MIT to find a better way to deliver web content. Professor Tom Leighton and his student Danny Lewin worked on the problem, and their paper introduced consistent hashing to spread cached copies over many servers. They founded Akamai in August 1998 and launched its commercial service in April 1999, with Yahoo! as a charter customer. Content owners paid Akamai to keep copies on servers spread across many networks, and Akamai’s DNS sent each user to a nearby one.

Cloud providers later made CDNs self-service: Amazon CloudFront (2008) with pay-as-you-go pricing, and Cloudflare (2010) with a free plan. Today’s CDNs also terminate TLS, absorb DDoS attacks and run code at the edge.

Why it’s built this way

Copies near users, not one bigger origin
Distance and congested links between networks were the problem, so adding origin capacity didn’t help a user on another continent. Serving from inside or near the user’s network shortens every round trip.
Consistent hashing to place content
Each object maps to a server in a way that barely changes when servers join or fail, so caches don’t all reshuffle and no server needs a full view of the network.
Steer users with DNS, and later anycast
Answering the DNS lookup with a nearby server’s address works with every browser unchanged. Newer networks such as Cloudflare announce the same IP addresses everywhere and let internet routing pick the closest site.
Let the origin’s HTTP headers decide
The CDN can’t know how fresh content must be, so the origin says so with headers like Cache-Control. That’s why invalidation takes effort: copies live until they expire or you purge them.

Timeline

  1. 1997

    MIT paper introduces consistent hashing to relieve web hot spots

  2. 1998

    Akamai incorporated on 20 August

  3. 1999

    Akamai’s commercial service launches in April, with Yahoo! as a charter customer

  4. 2008

    Amazon CloudFront offers a CDN with no contract, billed per GB

  5. 2010

    Cloudflare launches, with a free plan

  6. 2017

    Edge code goes mainstream: Lambda@Edge is generally available, Cloudflare Workers announced

  7. 2025

    CloudFront adds flat-rate plans with no overage charges

Sources10

Improve this page on GitHub