A content delivery network is usually described as a cache, and caching is only half of what it provides. The other half, terminating connections close to the user, benefits requests that are never cached at all.

Two separate benefits

The first benefit is the obvious one: a response served from a location near the user travels a short distance, so it arrives quickly and the origin never sees the request.

The second is that connection establishment happens near the user even when the content cannot be cached. The expensive part of a first request is not transferring bytes, it is the round trips: one for the transport handshake, one or two for encryption, then one for the request itself. Each costs the full round trip time to whatever the client connected to.

If the client connects to something 10 milliseconds away rather than 150 milliseconds away, those handshake round trips cost a tenth as much, and the edge then reuses a warm, already-established connection to the origin for the actual fetch. The saving applies to every request, cacheable or not.

Why the second benefit is underestimated

People frequently conclude that an edge network cannot help a dynamic, personalised application because nothing is cacheable. That conclusion is wrong, and the arithmetic shows why.

For a user 150 milliseconds from the origin, a cold request costs three or four round trips of handshaking plus the request, around 600 milliseconds before any processing. Through an edge 10 milliseconds away, the handshake costs 30 to 40 milliseconds, and the edge's warm connection to the origin adds one round trip of 150 milliseconds plus processing. The total falls by roughly a third to a half for the first request and more for subsequent ones.

Add connection reuse at the edge, where the client keeps one connection for many requests, and the saving compounds. This is why putting an entirely uncacheable API behind an edge network is a reasonable decision, and why providers market exactly that.

The structure of an edge network

Understanding the shape helps when reasoning about behaviour and cost.

A provider operates many points of presence, each a set of servers in a facility with good connectivity, and announces its addresses by anycast so clients reach a nearby one without any client logic. The number of locations varies enormously between providers, from dozens to hundreds, and more is not automatically better, since a thin location with poor connectivity can be worse than a well-connected regional one.

Behind the edge locations many providers run a second tier, a smaller number of larger caches, and origin fetches go through it. This matters because it both increases the effective hit ratio and reduces origin load, which is covered later as shielding.

What the edge terminates

The edge becomes the TLS endpoint for the client, which has consequences worth naming explicitly.

It holds a certificate for your hostname, which means either you upload one or the provider obtains one on your behalf, and either way a third party terminates your users' encryption. For most services that is an accepted trade; for some it is a compliance question with a real answer.

It also means the edge sees request content, so it can route, cache, rewrite, compress, authenticate and filter. And it means the connection from edge to origin is a separate one, with its own protocol version, its own encryption and its own timeouts, so all of the two-connection reasoning from layer 7 proxying applies, because an edge network is a geographically distributed layer 7 proxy.

Protocol upgrades for free

One practical benefit of edge termination is that the client-facing protocol is the provider's choice rather than yours.

The edge can offer the newest transport and HTTP versions, modern encryption, session resumption, early data and compression, while speaking something older to your origin. So clients get multiplexing, fast resumption and improved loss recovery without the origin changing at all.

This is a real and often overlooked reason to adopt an edge network, because upgrading an origin's protocol support is work and upgrading an edge configuration is a setting. The newest transport in particular benefits exactly the users who need it most, those on lossy mobile networks, and getting that for a configuration change is good value.

Attack absorption

Because the edge is anycast and enormous, it absorbs volumetric attacks that would overwhelm an origin.

A flood is distributed across every location by routing, so each sees a fraction, and the provider's aggregate capacity is far beyond what any individual customer could provision. Application-layer attacks are handled with rate limiting, challenges and filtering at the edge, before reaching the origin.

The condition for this to work is that the origin is not reachable directly. If the origin's address is discoverable, an attacker bypasses the edge entirely and the protection is decorative. Restricting the origin to accept only the provider's address ranges, or using an authenticated tunnel the provider offers, is the step that makes the protection real, and it is frequently omitted.

Where an edge network does not help

It is worth being clear about the limits, since they shape what to expect.

It cannot reduce origin processing time, so a slow endpoint stays slow for cache misses. It cannot improve a path the provider does not have good connectivity on, and for some regions a particular provider is simply worse than another. It adds a hop that can itself fail, misconfigure or time out.

And for a service whose users are all near the origin already, the latency benefit is small, which is the one honest case for not using one. Even then, the attack absorption and the protocol upgrades often justify it, but the latency argument does not.

Where the bytes come from, and why it matters for cost

A detail with large financial consequences: a request served from the edge's cache never touches your origin, so you do not pay your cloud provider's egress rate for those bytes.

Cloud egress is typically the single largest network cost item for a service of any size, and edge delivery is usually billed at a lower rate for the same bytes. So moving delivery of large assets behind an edge network is frequently a cost reduction rather than an additional expense, which is the opposite of how it is often presented internally.

The arithmetic is worth doing explicitly before a decision: total bytes served, the fraction cacheable, the cloud egress rate and the edge rate per region. For media-heavy services the saving is large enough that the latency benefit is almost incidental.

Who the client actually is

One consequence of edge termination deserves naming early, because it causes confusion later.

From the origin's perspective, every request now comes from the provider's address, not from the user. Access logs, rate limits keyed on source address, geographic logic and abuse blocking all break unless they read the forwarding header the edge adds instead.

The forwarding header is appended rather than replaced, so a client can send a fake value and the edge will add the real one after it. Trusting the leftmost value is therefore a spoofable identity check, and the correct read is the value the edge itself added, counted from the right according to how many trusted hops are in front. Getting this wrong is both a logging problem and a security one.

Choosing a provider on evidence

Providers differ in ways that matter and that marketing material does not distinguish.

The useful comparisons are measured rather than claimed: real-user latency from the countries that matter to you, which providers differ on substantially by region; the second-tier cache behaviour, which determines your effective hit ratio at moderate traffic; the edge runtime's limits if you intend to use it; purge latency and whether tag-based purging is offered; and the pricing shape, since per-request and per-byte rates vary by region by multiples.

The practical way to choose is to serve a fraction of real traffic through each candidate and compare client-reported timings by country, which is a week of work and produces a defensible answer where a feature comparison does not.