will a cdn actually lower your hosting costs?
The Math Most Engineers Skip
The answer is yes. The answer is also: it depends.
And the reason people get the math wrong in both directions is the same. They skip the one number the whole equation turns on.
CDN vendors lead with the cost-reduction story because it's true, in the right conditions. The problem is that "right conditions" gets collapsed into a headline percentage, the headline gets accepted without interrogation, and organizations sign contracts priced against a cache hit ratio they never actually modeled. Some overpay. Some underestimate real savings and walk away from a genuinely useful tool. Either way, the gap between what a CDN can do and what it will do for a specific environment comes down to one variable. That variable rarely makes it into the sales conversation.
Before we get to the number, let's establish the mechanism.
How CDN Offload Actually Reduces Your Origin Costs
A CDN sits between your users and your origin server. Every request served from the edge, an image, a video segment, a CSS file, is a request your origin never sees. That matters because bandwidth is a real line item: every incoming request that hits your origin consumes network bandwidth, and that consumption is what your hosting or cloud provider bills against.
CDNs cut that load through caching and optimization. Content is stored at edge nodes distributed geographically close to your users; when a user requests an asset, the edge node serves it directly rather than routing the request all the way back to your origin infrastructure. The origin handles the first request for a given asset, caches it at the edge, and then steps back. Every subsequent request for that asset, until the cache expires, never reaches origin at all.
The bandwidth savings are real. The compute offload is real. Where most organizations lose the thread is in assuming those savings apply uniformly across everything their infrastructure serves. They don't, and the variable that determines how far your actual savings diverge from the theoretical maximum is one you can calculate before you sign anything.
The Number People Skip : Cache Hit Ratio
Cache hit ratio is the percentage of requests served from the CDN edge rather than your origin. That's the hinge number. Every cost projection, every vendor claim, every ROI model is a function of it.
A 90% cache hit ratio can cut monthly bandwidth costs by roughly 85%. That's a genuinely meaningful reduction, and it's the kind of number that shows up in CDN sales decks. What those decks don't always surface is the assumption baked into it: your content is actually cacheable at that rate.
The reason cache hit ratio gets skipped in pre-contract conversations is that calculating it requires knowing your asset mix before you sign, not after. That's work. It's also the work that separates organizations that see the savings the vendor projected from the ones that run the math six months later and wonder where the gap came from.
What Actually Caches — And What Collapses the Ratio
Not all content behaves the same way in a CDN cache, and the spread between asset types can swing your effective cache hit ratio by 40 to 50 percentage points.
Static assets. video segments, images, JavaScript, CSS, cache cleanly. They're the same for every user who requests them, they don't change on every request, and they're exactly the kind of content CDNs were architected to serve. These are where the ceiling is high and the math is favorable.
Dynamic content is where the ratio collapses. Personalized pages, transactional data, session-specific API responses, if your infrastructure is serving content that's unique per user, the CDN has nothing to cache. The request still passes through the edge layer, but it doesn't stop there. It routes to origin every time, and your bandwidth cost profile stays close to what it was before the CDN was in the stack.
Advanced CDN configurations can push cache hit potential to 70–90% even on mixed workloads — but only when the architecture is built to support it and the workload characteristics align. Static content caches. Personalized content doesn't. Transactional data doesn't. The more your traffic skews toward what a user owns rather than what everyone shares, the weaker your CDN math gets. That isn't an argument against CDNs — it's an argument for modeling your specific traffic pattern before you assume a number.
The Netflix Ceiling — What Purpose-Built CDN Actually Achieves
The ceiling of what a CDN can do, when the content distribution pattern is fully in its favor, has a concrete reference point.
Netflix built Open Connect in 2011 not because commodity CDNs had failed them, but because commodity CDNs had a ceiling they'd already hit. Their approach was fundamentally different: instead of waiting for users to request content and then serving it from the edge, Open Connect uses proactive, directed caching, pushing content to the edge before it's even requested. The result was a reduction in overall upstream network demand by several orders of magnitude. That isn't optimization at the margins. That's an architectural redesign of the content distribution model itself.
Most organizations aren't Netflix. The traffic volume, the asset predictability, the ability to model what users will want before they ask for it — those are conditions Netflix built an entire proprietary infrastructure to create. Replicating that without the same traffic pattern and engineering investment isn't realistic.
But the principle still holds. The closer your content distribution model maps to a purpose-built caching strategy, high-volume, predictable, largely static assets served to a large audience, the closer your realized savings approach that ceiling. The further your workload skews toward dynamic, personalized, or session-specific content, the further from it you fall. Open Connect is the north star. Your actual environment determines how far you are from it.
The Math That Has to Be Yours — A Three-Step Framework
The CDN vendor's cost-reduction claim is directionally accurate. Whether it's accurate for your environment, at your scale, with your asset mix — that's a different calculation. Here's how to make it before any contract conversation happens.
Map your cache hit ratio by asset type: Don't model a single ratio for your whole workload. Segment by asset class: video segments, static images, JS and CSS, API responses, and user-session or transactional content. Each segment carries its own effective cache hit rate. The weighted average of those segments — weighted by the actual traffic volume each class generates — is your real projected cache hit ratio. A single blended number hides too much.
Price your current origin egress cost per GB : Pull this from your cloud or hosting provider invoice. This is the baseline the CDN has to beat. If you don't know this number with precision going into a vendor conversation, you cannot meaningfully evaluate the contract — you're anchoring on their projection, not yours.
Model your residual origin load post-offload: Multiply your current monthly egress volume by (1 − your projected cache hit ratio). That figure is what stays at origin after the CDN does its job. Price that residual load at your current egress rate, then compare it to your CDN contract cost. The delta is your real savings — or your real exposure if the math runs the other direction.
Run those three steps before the first vendor call. It takes time upfront. It also means you walk into that conversation with your own numbers rather than theirs — and that changes the entire dynamic of what you're actually negotiating.
The Savings Are Real. Model the Math First.
CDNs genuinely reduce origin bandwidth costs. The mechanism is sound, the savings ceiling Netflix demonstrated is real, and for organizations with the right asset mix and traffic pattern, the ROI can be substantial. What's equally real: that ceiling is only reachable when your content distribution pattern supports it.
The one number that tells you how close you are is your cache hit ratio, modeled by asset type, not pulled from a vendor projection. Price it against your current egress cost. Model what stays at origin after offload. Then price the CDN against that residual.
That's the math. It has to be yours.
If you're evaluating a CDN contract or auditing an existing deployment and want to run those numbers against your actual architecture, reach out — our team at WESCO can walk through it with you. And if you want logs like this one delivered directly to your inbox before they hit the site, join The Private Frequency below.
Views my own.
Sources
Cloudflare. "What is a CDN? | How do CDNs work?" https://www.cloudflare.com/learning/cdn/what-is-a-cdn/
BlazingCDN. Cache hit ratio / 85% bandwidth cost reduction claim.
Netflix. Open Connect — proactive directed caching and upstream demand reduction. https://openconnect.netflix.com
