4.3 DNS, CDN and the edge
Describes cloud networking as of August 2026
What this is and why it exists
Your service now runs somewhere. This topic gives it a name people can type and makes it fast for someone two thousand kilometres away — the two jobs of managed DNS and a content delivery network. It also quietly solves a problem you have not met yet: how a small origin survives a large audience, and how it stops being reachable directly at all.
The vocabulary
- Managed DNS — the provider hosting your domain's records. Amazon offers Route 53, Azure offers Azure DNS, Google offers Cloud DNS.
- Zone — the collection of records for one domain, held by whoever is authoritative for it.
- Health-checked routing — DNS answers that change based on whether a target is responding.
- CDN — a network of caches close to users, serving copies of your content: Amazon's CloudFront, Azure's Front Door and CDN, Google's Cloud CDN.
- Edge (or point of presence) — one of those locations, near the user rather than near you.
- Origin — your actual service, which the edge fetches from when it does not have a copy.
- Cache key — the set of things that make two requests "the same request" for caching purposes.
- Invalidation (or purge) — telling the edge to discard a cached copy before it expires.
- TLS termination — the point where the encrypted connection is decrypted, which at the edge is near the user.
The mental model
Managed DNS is the same DNS from the groundwork module, run by somebody else, plus one capability worth the move on its own: the answer can depend on something. Health-checked routing hands out the address of a target that is currently responding and stops handing out one that is not. Latency or geography routing hands each user the nearest deployment. This is a blunt instrument — clients cache answers for the TTL, so failover through DNS takes as long as the TTL you set — and that is the trade to remember: DNS failover is cheap and global, and it is measured in minutes rather than seconds.
The CDN is a cache in front of your origin, and everything about using one well is about what may be cached and for how long. Static assets — images, stylesheets, scripts — should be cached hard and long, and the way to make that safe is to put a version or hash in the filename so a new deployment produces new names rather than needing old ones to expire. HTML and anything personalised generally should not be cached at the edge unless you have thought carefully, because the failure mode is not slowness, it is one user seeing another's page.
Which makes the cache key the concept to understand rather than skim. It decides what counts as the same request: normally the path, and whichever query parameters, headers or cookies you tell it to include. Include too little and different responses collide — that is how a personalised page gets served to a stranger. Include too much and nothing is ever a hit, because every request carries some unique tracking parameter or cookie and each one produces a separate cached copy. The rule of thumb is to include exactly what changes the response and nothing else, and to check the hit ratio afterwards, since a CDN with a low hit ratio is an extra hop that has made things slower.
Invalidation is the escape hatch and not the plan. Purging is slower than people expect, is sometimes charged for, and does not reach every cache in the world — a user's own browser is holding a copy you cannot touch. Versioned filenames and sensible expiry times are the actual answer; keep purging for the emergency where something wrong went out.
TLS termination at the edge is the last piece and has a real performance reason behind it. Setting up an encrypted connection costs round trips, and round trips cost distance — so terminating close to the user makes the expensive part short, after which the edge holds a warm connection back to your origin. Two things follow. The certificate for your public name lives at the edge, which is where you configure and renew it. And the traffic from edge to origin needs its own encryption, so you have not accidentally made the long half of the journey the unprotected one.
That leaves origin protection, which is the security half of a performance feature. If people can reach your origin directly by address, they can bypass every cache, every rate limit and every rule you configured at the edge. So the origin should accept traffic only from the CDN — by a shared secret header, by the provider's own origin-access mechanism, or by network rules — and rate limiting belongs at the edge, where an abusive client is absorbed by capacity you do not pay to run.
What you should now be able to explain or do
Explain what managed DNS adds beyond hosting records, and why DNS failover is measured in minutes. Decide what to cache and for how long for three kinds of content, including one that must not be cached. Say what a cache key is and describe the two opposite failures of getting it wrong. Explain why versioned filenames beat purging. Say where TLS is terminated, what still needs encrypting, and why. Describe two ways to stop people reaching your origin directly.
Check yourself
Why is DNS failover measured in minutes rather than seconds?
Because clients and resolvers hold the previous answer for its TTL. Lowering the TTL shortens the window and increases lookup traffic; nothing makes a cached answer disappear early.
A logged-in user sees another user's page. What CDN mistake causes this?
A cache key that omits something which changes the response — the session cookie or an authorisation header — so two different requests were treated as the same one and a personalised response was shared.
Your hit ratio is near zero. What is the likely cause?
A cache key including something unique to each request, such as a tracking parameter or a cookie, so every request produces its own cached copy. The CDN has become an extra hop.
Why prefer versioned filenames over purging the cache?
Because a new name is a new object everywhere at once, with no waiting and nothing to invalidate — and purging does not reach browsers that already hold a copy anyway.
Why must the origin refuse traffic that did not come through the CDN?
Because a direct address bypasses the cache, the rate limits and the rules at the edge. Restrict it with an origin-access mechanism, a secret header, or network rules — otherwise the protection is optional for anyone who looks.
Go deeper
We haven't checked most of these for screen reader use yet.