[Quick Bites]: CDN

Gauransh Mathur

Gauransh Mathur

— 3 min read
Share
[Quick Bites]: CDN
This is part of my enterprise cloud architecture series.

You open a tutorial on hosting a website on AWS and it goes EC2, load balancer, database, done. Then you look at how companies actually draw their architecture and the very first box, before the VPC, before anything you just built, is a CDN.

What even is a CDN?

Content delivery network. It is a bunch of servers spread all over the world, sitting close to your users, that keep copies of your content.

Think of it like Amazon home delivery. If everyone had to travel to the warehouse for every item, it would be slow and the warehouse would be crowded. Deliver to the doorstep and most people never go to the warehouse at all.

Here is the flow:

flowchart TD; A([User asks for a page or image]) --> B[Nearest CDN location]; B --> C{Does it have a copy?}; C -- "Yes" --> D[Answers right there]; C -- "No" --> E[Fetch from your servers]; E --> F[Keep a copy]; F --> D;

On AWS this is CloudFront, but the idea is the same everywhere.

Where does it sit?

Before everything else. Users never talk to your servers directly, they talk to the CDN, and the CDN decides what it can answer itself and what it has to pass back.

flowchart TD; U([Users]) --> CDN[CDN]; CDN -- "static files" --> S[(Storage)]; CDN -- "everything else" --> LB[Load balancer]; LB --> APP[App servers]; APP --> DB[(Database)];

Everything from the tutorial is still there, it just moved behind the front door.

Why does it exist?

Three problems, one box:

  • Distance. Your servers live in one region, your users do not. The CDN answers from nearby, so people far away are not stuck waiting on the long trip.
  • Load. Most requests are for the same things, images, scripts, pages. The CDN answers those itself, so your servers only deal with what actually needs them.
  • Protection. Traffic spikes and attacks hit the front door first, not your servers.

Cost falls out of this. If the CDN answers most requests, you need fewer servers behind it, which is why it's beneficial for FinOps.

You do not always need one. If your users are all in one place and traffic is small, it can wait. It starts to matter when users are spread out or traffic grows.

The first firewall

Because every request goes through the CDN first, it is also your first line of defense. Bad traffic can be filtered at the front door, and your servers only see what already got past it.

There is one thing to get right. If people can still reach your servers directly, they can skip the front door entirely. So the design rule is simple, only the CDN should be able to talk to your servers.

Note: A CDN is also one more thing that can break. When a big one goes down, a lot of the internet goes with it. I wrote about that in Why Cloudflare went down?

Where it fits in the pillars

PillarThe questionWhat the CDN does
SecurityWho can reach this?Filters bad traffic at the front door, keeps your servers out of sight
ReliabilityWhat happens when it breaks?Soaks up traffic spikes, can fail over to a backup
Performance EfficiencyIs it fast enough?Answers from nearby, fewer long round trips
Cost OptimizationWhere is the money going?Fewer requests reach your servers, so you need fewer of them

Four pillars, one box on the diagram. That is why it gets drawn first.

Next up in the series, we go one layer deeper. Load Balancers (ALB & NLB)

Read more