CDN for OTT platforms & video streaming

Why OTT teams replace a working CDN

Almost nobody migrates because playback is broken. They migrate because the economics stopped matching the business, and three patterns account for most of it.

What the incumbents charge

Published list rates for the first paid tier, before commitments and discounts. These are the numbers a team models with before talking to sales.

Rates are public list prices and change. The full workings, caveats, and tier boundaries are in our CloudFront cost breakdown and Fastly pricing teardown. Akamai does not publish a delivery rate card, which is itself the relevant fact — see Akamai vs Fastly.

What changes, and what doesn't

The cost case is usually the easy half. The question that actually stalls a migration is what breaks — so here is the honest split.

• Player and playback codeunchanged

  If your media hostname stays yours, the player never learns the CDN changed. Do not ship a player release in the same window as a cutover.

• HLS and DASH manifestsunchanged

  Standard HLS with TS or CMAF segments and MPEG-DASH MPDs are served as-is. No repackaging, and no re-encode of an existing library.

• DRM and licence acquisitionunchanged

  Keep the DRM provider and workflow exactly as they are, and test them as a separate workstream. Licence servers do not sit behind the delivery CDN.

• Origin and packagerunchanged

  Any HTTP origin works, including S3-compatible storage you already run. Origin shield collapses cache-miss fan-out, so the packager sees less load rather than more.

• Cache rules and TTLsmust rebuild

  Manifest and segment TTLs, query-string handling, and cache-key composition have to be recreated deliberately rather than assumed to carry over.

• Signed URLs and tokensmust rebuild

  Token schemes are provider-specific. Plan a dual-validation window where both the old and the new signature formats are accepted.

• TLS certificates and CORSmust rebuild

  Certificates are reissued for the media hostname, and CORS headers must match byte-for-byte or browser playback fails while curl still passes.

The three “must rebuild” rows are the whole risk surface, and all three are verifiable before a single viewer moves. Diff the edge response on both providers behind the same hostname:

# Same URL, both edges, before any traffic moves
curl -sSI https://media.example.com/hls/master.m3u8 \
  --resolve media.example.com:443:<current-edge-ip>

curl -sSI https://media.example.com/hls/master.m3u8 \
  --resolve media.example.com:443:<zerobuffer-edge-ip>

# Compare: cache-control, age, vary, content-type,
#          access-control-allow-origin, accept-ranges

A mismatch in any of those six headers is a playback bug waiting for a specific device to find it. Our cache header checker and HLS manifest checker run the same comparison without the curl flags.

Replacing an OTT CDN in six stages

A CDN migration fails when it is treated as a DNS change. Treated as a staged rollout with gates, it is routine. Each stage below has to produce evidence before the next one starts.

1. 1

   Validate on a non-production hostname

   Serve the real library from a parallel hostname and diff edge behaviour against the incumbent — headers, status codes, range handling, cold-cache latency. No viewers involved.

2. 2

   Route employee and synthetic traffic

   Point internal users and synthetic monitors at the new path. This is where header and CORS mismatches surface, before anyone with a subscription is affected.

3. 3

   Start a sticky production canary

   Move a small, session-sticky slice of real viewers. Sticky matters: a viewer bouncing between CDNs mid-session produces noise you cannot attribute to either provider.

4. 4

   Expand by controlled dimensions

   Widen one variable at a time — market, then device class, then content type, then live versus VOD. A regional failure must not disappear inside a global average.

5. 5

   Ramp new sessions, drain old ones

   Send new sessions to the new path while existing ones finish where they started. Long-tail playback windows decide the schedule, not the DNS TTL.

6. 6

   Reach 100% without decommissioning

   Full traffic does not mean cancelling the old contract. The outgoing CDN is your fastest rollback until the new path has survived a peak event.

The full version — rollout gates, cache and DRM parity checks, cold-cache testing, and the rollback path — is in the OTT CDN migration runbook.

When we are not the right replacement

Migrations that should not have happened are expensive for both sides. Four cases where the answer is to stay where you are:

• You need a contracted WAF, bot management, and API-security platform under one SKU — that is an Akamai or Cloudflare conversation, not ours.
• Your delivery is bound to provider-specific edge compute that would have to be rewritten before any traffic could move.
• Procurement requires a named vendor on an existing enterprise agreement more than it requires a lower rate.
• Your volume still sits inside a competitor's free allowance, where the bill is not yet the problem worth solving.

Frequently asked questions

What is an OTT CDN?

An OTT CDN is a content delivery network configured for internet video services: HLS or DASH manifests, short media segments, adaptive bitrate ladders, high concurrency, and access control across both live and VOD traffic. Its job is to serve the right media object close to each viewer while protecting the origin or packager from repeated requests.

Can you replace an existing OTT CDN without breaking playback?

Yes, if you migrate in stages instead of flipping DNS. Keep the player and the DRM workflow unchanged, preserve URL, header, authorization, and CORS behavior behind your existing media hostname, then move traffic through a sticky canary before ramping. Keep the outgoing provider available until legacy sessions drain.

How long does an OTT CDN migration take?

There is no reliable universal duration. Set the schedule from the number of playback contracts and observation windows you have to prove — markets, device classes, live versus VOD, a peak event — rather than from the DNS change itself, which takes minutes.

Do we have to change our player or re-encode our library?

No on both counts in the normal case. Standard HLS with TS or CMAF segments and MPEG-DASH are served as-is, and if the player addresses a media hostname you control, traffic moves behind that hostname without a player release. Player changes are only forced by client-side content steering, a new token scheme, or provider-specific URLs baked into manifests.

What does OTT delivery cost on ZeroBuffer?

A flat $0.0049/GB in every region, falling to $0.0035/GB above 750 TB, with no per-request fees on manifests or segments and no regional surcharge. Fifty terabytes of delivery is $245 whether those viewers are in Ohio or Jakarta.

Can we run both CDNs at the same time?

Yes, and for a business-critical service you should. Parallel operation gives you a control group for comparison, supports gradual traffic movement, and preserves a fast rollback path. There is no contract or minimum on our side that penalises running at partial traffic for as long as the comparison needs.

How does this relate to your global network?

ZeroBuffer serves viewers in 70+ countries across 6 continents at 25ms average global latency, backed by a 99.99% uptime SLA. Every one of those regions bills at the same flat $0.0049/GB, with no per-request charges on your HLS or DASH segments.