You Pay to Deliver the Same Video Over and Over. Here's the Math.

You already know this, because you live it.

You drop the latest episode of a new popular micro drama series, or the highlights from last night’s nail-biting football match, or an important geopolitical interview with a world leader. Concurrency climbs on the dashboard. The launch goes well. And a few days later the cloud bill lands, and the delivery line has jumped again. Compute, you rightsize and optimize. Storage, you tier. Delivery just grows with the audience, every month.

With the increasing costs of compute and memory spurred on by AI, more viewers mean increasingly more egress costs. And your delivery cost scales with consumption, and not necessarily in lockstep with revenue. And you already optimized at every stage of the video pipeline: multi-CDN, traffic steering, cache tuning, a negotiated commit. All of that optimizes the same pipe. None of it changes the fact that you pay to deliver the same bytes to every single viewer.

Here is the proof, in numbers you can check. For the sake of simplicity, and my own personal experience, we’re going to use AWS and Amazon CloudFront as a reference but understand that this can apply to most content delivery network services.

Start with a cost table

AWS publishes a reference architecture ↗ (opens in a new tab) for video on demand, with a sample cost table ↗ (opens in a new tab). It is a deliberately simple example: one region, one CDN, list pricing, a single 60-minute video (no security, DRM or edge compute included, purposely). Read it as an illustration of cost structure, not a production benchmark. But as an illustration it is stark, and these are AWS’s numbers, not mine.

For one 60-minute video streamed to 1,000 viewers for one hour:

Delivery is about 98% ($229.50/$233.94) of the bill. Encoding and storage are basically rounding errors beside it. And look at how AWS calculates the delivery line:

0.75 MB/s per viewer × 1,000 viewers × 3,600 seconds = 2,700 GB × $0.085/GB = $229.50

The audience is in the formula. You prepare the title once — encode and store it — and that cost tracks your catalog, not your audience: the same for ten viewers or ten million. Delivery is the only line that multiplies per viewer. (The $0.085/GB is AWS’s list price for the first 10 TB per month of CloudFront egress in North America and Europe; other regions and higher tiers differ. You almost certainly pay a committed rate well below list. Hold that thought, because it does not change the argument at all.)

This is not news to anyone. Hydrolix, in their breakdown of streaming costs ↗ (opens in a new tab), puts it plainly: for any widely distributed title, “the CDN bill usually represents the largest line item.” The question is not whether delivery is your biggest variable cost. It is. The question is whether you’ve actually run out of things to try, or just run out of things that work on the same pipe.

What you are actually paying for: re-delivery

Many web players deliver video using HLS (HTTP Live Streaming), which serves a video as a playlist of small segments, each a few seconds long, in several quality levels (a bitrate ladder). A 60-minute title is roughly 600 segments per rendition. A viewer pulls them in sequence, with the player switching levels as bandwidth changes. Now watch what a synchronized audience does to that.

You drop the video, and 100,000 people watch it in the first hour. A viewer who watches it through pulls about 600 segments, and on binge-style serialized content most viewers pull most of them.

~600 segments × 100,000 viewers ≈ 60,000,000 deliveries

Your CDN bills you for all of them. The unique content behind those deliveries is tiny: about 600 segments per rendition, a few thousand across the whole ladder. And because viewers on the same kind of connection converge on the same one or two quality levels, the same hit segment still gets shipped tens of thousands of times over. You paid to deliver a few thousand unique segments sixty million times. Triple the audience to 300,000 and a pure-CDN bill roughly triples, for the same content. The content did not change. Only the repetition did.

So here’s the bottom line: a few thousand unique segments, sixty million billed deliveries. You are not paying for content. You are paying for redundancy.

Two objections come up here, so let me handle both.

“We cache.” Caching deduplicates the fetch from your origin. It does nothing to reduce the egress billed for delivery from the edge to each viewer, the line that dominates the bill. Two people in the same city watching the same cached segment are still two separate, billable deliveries. Even a perfectly warm cache bills full egress for every byte every viewer watches. Cache hit ratio protects your origin. It does not touch the line that is actually large.

“We negotiated our rate.” Good, and it does not matter to this. Whether you pay your CDN list or a hard-won one cent a gigabyte, you are still billed for 60 million deliveries. Re-delivery is a problem of how many times you are billed, not how much each time. Cache tuning and CDN negotiation can only shave the rate. They cannot touch the count.

Why this lands hardest on vertical and short-form

If you run a vertical or short-form catalog, this is not an edge case. It is your entire cost structure, and the research community has started saying so out loud.

In a 2025 paper presented at Mile-High Video, researchers from Synamedia, Sky, and Ozyegin University (“Beyond Swiping through Short-Form Videos” ↗ (opens in a new tab), Kara, Simon, Demir, Begen, Agboma) analyzed roughly 62,000 short clips from a real platform and about 206 million views. Their conclusion is blunt: short-form video has no standardized delivery protocol, every platform improvises, and the cost of that is real and growing.

But the genuinely useful part is the distinction they draw, because it separates two problems that get lumped together and are not the same.

Prefetch waste. On swipe-feed short-form, the TikTok and Reels pattern, the player preloads the next clips so the feed feels instant. Then the user swipes past most of them. The measurement studies this paper surveys found that early termination wastes nearly half the mobile data in short-video streaming, “costing streaming vendors millions annually.” Those preloaded-but-never-watched segments are a client-side problem: the player fetched video nobody watched.

Re-delivery waste. On serialized micro-drama, the vertical-drama-app pattern, viewers binge full episodes back to back, and titles live or die on a synchronized drop. Here the waste is not unwatched prefetch. It is the same hit segment shipped to every viewer independently, the exact mechanic above. This is a delivery problem.

Different problems. Prefetch waste is fixed in the player. Re-delivery waste is fixed in how the bytes move. If you run serialized vertical content with synchronized drops, your spike is re-delivery, and it’s the one you’ve never had a way to fix.

Where the money comes back

If the cost is that each segment is delivered from the edge to every viewer, the recovery is to deduplicate the last hop. Deliver each segment to a small set of viewers from the CDN, and let other viewers who already have it pass it to the next ones, directly, browser to browser over WebRTC, coordinated by a lightweight signaling service.

That is what we build at Sudden. It is a small script you add to your site (an npm package or a script tag, plus a service-worker loader). The service worker watches your player’s segment requests. When another viewer’s browser on a reachable network path already holds the segment, Sudden fetches it peer to peer instead of from your CDN. When no peer has it, the request goes to your CDN exactly as it does today. Your player, your CDN, and your origin do not change. It runs alongside your multi-CDN setup, it does not replace it.

Put that back into the math. For a segment with 100,000 concurrent viewers, your CDN no longer serves 100,000. It serves a small seed set, the first arrivals plus anyone with no available peer, and the rest are served from peers. Billed CDN deliveries for that segment fall from 100,000 toward that seed count.

Here is what makes the whole thing work: the more people on the same segment at once, the higher your redundancy was, the larger the share you can move off the CDN. The offload rises with exactly the concurrency that was costing you. In this case, the property that makes a video drop expensive is the property that makes it recoverable. On a dense synchronized drop, peer-assisted delivery can move a substantial share of traffic off the CDN; published peer-to-peer streaming deployments report offload ranging from modest to a large majority, depending on concurrency, session length, and network conditions. On a cold, desynchronized long tail, where there is little to share, it is modest.

And the first question every serious engineer asks: what happens when it does not work. If a browser cannot peer, a peer drops, or a network blocks it, the request falls back to your CDN and playback continues with no viewer-visible change. The CDN is the floor. Peer delivery is opportunistic upside on top of it.

The worst case is the bill you already have.

What this does not do

Three honest limits, because you would find them yourself.

It works today on web-browser video on demand. Not live yet. If your platform is live-only, this is not a fit right now, and I would rather say so.

It only pays off on synchronized concurrency, but that’s broader than big drops. Beyond premieres and appointment viewing, everyday demand clusters in each region’s evening prime-time window (Sandvine’s 2019 Global Internet Phenomena Report ↗ (opens in a new tab) and a 2015 ACM study of a real video-on-demand workload ↗ (opens in a new tab)), so most catalogs carry real overlap every night, launch or no launch. The genuine exception is a purely cold, long-tail catalog watched evenly around the clock: little to share, so the math is modest.

And to be precise about the research above: Sudden addresses re-delivery, the delivery-side waste. It does not fix prefetch waste, the unwatched-preload problem on swipe feeds. That one belongs in the player. Anyone who tells you a delivery layer fixes both is selling.

How we price it

The only honest way to make a cost claim to a finance team is to let them measure it. So we charge on what we actually remove: offloaded gigabytes, measured against your own CDN logs. If there is no offload, there is no bill. The arithmetic above tells you where the recoverable money is. Your own dashboard tells you how much.

Here is the whole thing in one line:

your delivery bill ≈ unique content × audience × price per GB

You have spent years working the third term, negotiating price per GB, steering between CDNs, tuning cache. That is real work and it shaves real money, but it shaves the rate. The term that actually controls your bill is the middle one, the audience multiplier on your peak events, because that is the part that is pure redundancy and the part that is recoverable.

Take your biggest drop and work it out: segments times viewers is what you paid, unique segments is what you delivered, and the gap is what is recoverable.

The fastest way to know how big that gap is on your traffic is to let us run the math with you, on your real CDN logs, your number, not ours. Reach out and we’ll do it together. (If you want to go deeper on the mechanics first, see Sudden’s technical documentation ↗ (opens in a new tab).)

---

Sources: AWS, “Video on Demand on AWS,” reference architecture and cost table (CloudFront list pricing; illustrative single-CDN example). Hydrolix, “Live Streaming Pricing.” Kara, Simon, Demir, Begen, Agboma, “Beyond Swiping through Short-Form Videos,” Mile-High Video 2025 (Synamedia, Sky, Ozyegin University); the “nearly half wasted” figure originates in the prior measurement work that paper surveys. Sandvine, The Global Internet Phenomena Report (2019); and Ali-Eldin, Kihl, Tordsson & Elmroth, “Analysis and Characterization of a Video-on-Demand Service Workload,” ACM MMSys ’15 (2015) — both on the evening/diurnal concentration of streaming demand. Cost figures are AWS’s own published list-price illustration; real platforms pay committed rates below list, which does not change the per-delivery structure described here.