CDN Basics for Cloud-Hosted Sites
A content delivery network is a cache and a reverse proxy, and everything else follows from those two facts. This guide covers cache keys and lifetimes, a practical split of your content, origin configuration, provider options and the billing effects.
Moving the Bytes Closer to the Reader
Your server is in Frankfurt. Your reader is in Sao Paulo. Every request crosses an ocean twice before a single byte of the page appears, and no amount of CPU on the origin changes that, because the delay is distance.
A content delivery network puts copies of your static content in facilities near the reader and answers from there. The first visitor in a city pays the long trip; everyone after them gets a local response. On top of that it terminates TLS at the edge, which removes several round trips from connection setup, and it absorbs traffic that would otherwise hit your origin.
Two mental adjustments make the rest of this simple. The CDN is a cache, so everything depends on what it is allowed to store and for how long. And it is a reverse proxy, so it needs to be told where the origin is and how to talk to it.
What Gets Cached Is Entirely Up to You
Two mechanisms decide the behaviour: the cache key and the cache lifetime.
The cache key is what the edge uses to decide whether it already holds a response. By default it is roughly the hostname plus the path, and often the query string. Anything not in the key is ignored, which is why a page that varies by a cookie or an Accept-Language header will be served wrongly unless you add that to the key or exclude the page from caching. The Vary response header signals this, and every dimension you add multiplies the number of stored copies, so add them sparingly.
The lifetime comes from your own headers. Cache-Control: public, max-age=31536000, immutable on a hashed asset tells both the edge and the browser they never need to ask again. Cache-Control: public, s-maxage=300, max-age=0 lets the edge hold a page for five minutes while browsers revalidate each time, which is a good default for HTML that changes occasionally. Cache-Control: private, no-store keeps a personalised response out of any shared cache at all.
stale-while-revalidate is worth knowing: the edge serves the slightly old copy immediately and refreshes in the background, so nobody waits for the origin. Pair it with ETag so revalidation is a cheap conditional request rather than a full transfer.
A Practical Split of Your Content
| Content | Cache at the edge | Suggested approach |
|---|---|---|
| Hashed CSS, JavaScript and fonts | Yes, for a long time | Content hash in the filename, long max-age, never purge |
| Images and downloads | Yes | Long lifetime, versioned path when replaced |
| Marketing and documentation pages | Yes, briefly | Short s-maxage plus stale-while-revalidate |
| Logged-in pages and dashboards | No | private, no-store, pass straight through |
| API responses that vary per user | No | Pass through; the edge still helps with TLS and routing |
| Public API responses shared by everyone | Yes | Short lifetime with revalidation on an ETag |
| Uploads and user media | Yes | Serve from object storage behind the CDN, with signed URLs if private |
The pattern that causes the least trouble is separating the two lifetimes cleanly: assets get content-hashed filenames and effectively infinite caching, HTML gets a short lifetime. A deployment changes the HTML, which points at new asset filenames, and the old assets simply stop being requested. No invalidation is needed anywhere.
Serving media straight from object storage through the CDN is the other big win, since it takes large files off your application server entirely. The object storage article covers that pairing.
Setting Up the Origin Correctly
Point the CDN at your origin by hostname, and keep a separate name for it, such as origin.example.com, that is not the name users type. That way you can test the origin directly and move the public name to the CDN with a single DNS change.
Restrict the origin so it accepts requests only from the CDN. Providers offer an allowed address range, a shared secret header, or a signed origin request; pick whichever your stack supports. Without it, anyone who learns the origin address can ignore the edge entirely, which defeats both the caching and any protection you are relying on.
Keep TLS between the edge and the origin, not just between the reader and the edge. The traffic is crossing the public internet on that leg too.
Watch the Host header. Many CDNs forward the original host by default, some send the origin hostname, and a virtual host configuration that does not match will serve the wrong site or a redirect loop. This is the same class of problem covered in the reverse proxy guide, and the fix is usually one directive.
Finally, put the DNS record for the public name on a short time to live while you are cutting over, then lengthen it once you are satisfied. The DNS article covers the mechanics, including why an apex domain needs particular attention when the target is a CDN hostname rather than an address.
The Options, and How They Differ
Every major cloud has one: Amazon CloudFront, Azure Front Door, Google Cloud CDN. Each integrates tightly with that platform's storage, load balancers and certificate management, which is convenient when your origin already lives there. The CloudFront developer guide is a good general introduction to the concepts even if you use something else.
Independent networks come at it from the other direction. Cloudflare and Akamai operate large edge footprints and sit in front of an origin anywhere, which suits a stack spread across providers or one hosted on a developer cloud without its own network. Akamai's edge business is also the reason a Akamai cloud account now sits alongside the compute platform it acquired, a relationship the Linode and Akamai comparison explains.
Developer clouds usually offer something lighter. DigitalOcean attaches a CDN to Spaces buckets, and several providers include edge caching with their load balancer. These cover static assets well and offer fewer controls over cache keys and behaviours.
The billing point that matters: content served from the edge is usually charged at a different rate than content leaving your origin, and some providers do not charge at all for data moving from their own storage into their own CDN. For a site with heavy media, this is often the largest single saving available, as the egress costs article describes. An AWS account makes that pairing easy to test, since the storage and the network are billed on the same invoice.
Questions Worth Answering Early
How do I push an urgent change through the cache?
Every CDN has a purge or invalidation call, by path or by prefix, and it usually takes effect within seconds to a minute. Treat it as an emergency tool. If you rely on purging for routine deployments, switch to content-hashed filenames instead, because the version that never needs purging is the one that never goes stale.
Will a CDN speed up a dynamic application?
Partly, even when nothing is cached. TLS termination near the reader and an optimised connection back to the origin remove several round trips, which is measurable on distant connections. The large gains still come from caching, so look for pieces you can make cacheable rather than expecting the edge to fix a slow origin.
Does a CDN replace a load balancer?
No. It reduces the traffic reaching your origin and can often fail over between origins, but it does not distribute requests across a pool with health checks in the way a balancer does. Most production setups use both, with the CDN in front of the balancer.
What about certificates?
The edge presents the certificate for your public hostname, and most providers issue and renew it for you once you prove control of the domain. You still need a valid certificate on the origin for the internal leg. The certificate guide covers issuing that one.
Keep reading
All articles
Object Storage Explained: S3, Blob, GCS and S3-Compatible Options
Object storage keeps whole files as immutable blobs addressed by key. This guide explains the bucket and key model, compares…
Nginx as a Reverse Proxy on a Cloud Server
Nginx handles TLS, hostnames, static files and request limits so your application does not have to. This guide builds a…
DNS Setup for Cloud Servers: Records, TTLs and Propagation
Registrar, nameserver and zone are three separate jobs, and mixing them up causes most DNS confusion. This guide covers the…
Egress Costs: The Cloud Bill Line Nobody Plans For
Data transfer out is the invoice line that no capacity estimate predicts. This guide maps which directions are charged, the…
TLS Certificates for Cloud Servers with Let's Encrypt
A certificate proves domain control and nothing more, which is why issuing one can be automated. This guide covers ACME…
Questions about a cloud account?
Ask about products, variants, availability or purchasing on either channel.