Multi-CDN Strategy for OTT: When You Need One and How to Implement It Right

A single CDN is the right way to launch a streaming service. The case for a second one builds slowly: an outage lands on your biggest live night, viewers in a new region buffer more than everyone else, or a growing delivery bill has no alternative to negotiate against. This guide covers how to tell when that point has arrived, a worked example of whether a second CDN pays for itself, what a multi-CDN setup is made of, and how players report what they experience through CMCD.

Why one CDN is not enough

Every major CDN has had a bad day, and a single CDN turns its bad day into yours. These incidents come from the providers' own post-mortems:

• Fastly, 8 June 2021: 85% of its network returned errors, and 95% of traffic was back to normal within 49 minutes.
• Akamai Edge DNS, 22 July 2021: a DNS service disruption that lasted up to an hour.
• Microsoft Azure Front Door, 29 October 2025: customers were affected from 15:41 to 00:05 UTC, more than eight hours.
• Cloudflare, 18 November 2025: disruption began at 11:20 UTC, core traffic was largely back by 14:30, and every system was normal by 17:06.

Outages are the loudest reason, not the only one:

• Regional performance varies. A CDN that is fast in North America can be ordinary in the region you are growing into next, and viewers there see it as slow starts and rebuffering.
• Price varies by region, even within one provider. Bunny's published Standard-network price is $0.01 per GB in Europe and North America, $0.03 in Asia and Oceania, $0.045 in South America and $0.06 in the Middle East and Africa.
• Leverage. When traffic can move, a contract renewal becomes a negotiation.

When you do not need multi-CDN

For most services at launch, you don't. A second CDN adds a steering layer, a second set of tokens and logs, and another contract to manage. It starts to pay off when one of these is true:

• A single outage during your peak window would cost more than running a second CDN for a year. The worked example below shows how to check.
• Viewers in a region that matters to you consistently see worse startup time or rebuffering than everyone else, and your CDN cannot fix it.
• Your delivery bill is large enough that a credible alternative changes your renewal terms.

If none of these apply, stay on one well-monitored CDN, but keep manifests and token signing CDN-agnostic so adding a second CDN later is a configuration change rather than a rebuild. Revisit the decision before each major live event and each new region.

A worked example: does a second CDN pay for itself?

The list prices below are published by the CDNs. Everything else is an assumption, marked as one; swap in your own numbers.

Delivery. At those list prices, 150 TB a month on CloudFront alone costs about $9,965 before request fees, counting 1 TB as 1,000 GB. Send 30% of it through the second CDN and the total drops to about $7,715: $7,265 for CloudFront's 105 TB and $450 for Bunny's 45 TB. That is $27,000 a year saved on delivery.

Resilience. The second CDN path costs $6,000 a year for steering plus $24,000 of integration work, so about $3,000 net in year one once the delivery savings are counted. Assume a one-in-ten chance that a major CDN outage lands on one of the year's event nights: the expected loss is $6,000, twice that net cost, before counting support load and churn.

What it leaves out. The $3,000 excludes ongoing engineering and operations time, and any extra origin egress from filling a second CDN's cache. Setting it against the $6,000 expected loss also assumes the second CDN would prevent nearly all of that loss: an origin failure that takes both CDNs down, or a failover that does not trigger in time, would reduce the benefit.

Moving all traffic to the cheaper CDN would save more on paper, but it would put you back on a single point of failure. Run the same sums with your own traffic and your own biggest night. If that night is worth a few thousand dollars and your traffic is small, a second CDN rarely pays.

Components of a multi-CDN architecture

1. Two or more CDN contracts, ideally with different network footprints. Pairing a premium CDN with a budget one is common.
2. A steering layer that picks a CDN for each session, and ideally re-picks mid-session.
3. Real-user monitoring that scores each CDN by region, typically fed by CMCD and player analytics.
4. DNS or manifest routing, so the player fetches segments from the chosen CDN.
5. Token authentication that every CDN in the mix can validate.

CDN selection: DNS, client-side and content steering

• DNS-based steering answers each lookup with the best CDN for that viewer's network and region. It is simple and works with any player, but DNS answers are cached, so it reacts slowly once a session is under way.
• Client-side selection lets the player test each CDN at startup and fall back when segments fail. Failover is fast, but every player platform needs its own logic.
• Content steering is the standards-based middle path. Apple's HLS Content Steering specification, first proposed in 2021, adds an EXT-X-CONTENT-STEERING tag whose SERVER-URI points the player at a steering server, plus a PATHWAY-ID attribute that groups renditions by CDN. DASH-IF put an equivalent Content Steering for DASH out for community review in July 2022. The steering server can move viewers between CDNs mid-session without rewriting manifests, and AVPlayer, hls.js and dash.js support it.

Most mature setups combine two of these: steering picks the primary CDN for each session from real-user data, and the player falls back on its own when segments from that CDN fail.

CMCD: what the player tells the CDN

Common Media Client Data (CTA-5004, published in 2020) is a standard way for a video player to attach what it is experiencing to every request it makes. The CDN logs that data next to its own delivery logs, so you can see buffer health and throughput per session, per CDN and per region without a separate analytics beacon.

Version 1 defines 18 optional keys. The ones that matter most for CDN decisions:

• bl buffer length in milliseconds, and bs buffer starvation, set when the buffer ran empty.
• mtp measured throughput and br the bitrate of the requested rendition, both in kbps.
• su startup, set when a segment is needed urgently for startup, a seek or recovery from an empty buffer.
• sid session ID and cid content ID, which let you group requests into viewing sessions.
• ot object type, sf streaming format (h for HLS, d for DASH) and st stream type (v for VOD, l for live).

Here is a segment request carrying CMCD as a query argument, with illustrative values:

GET /vod/title-123/1080p/seg_00042.m4s?CMCD=bl%3D12400%2Cbr%3D5000%2Ccid%3D%22title-123%22%2Cd%3D4000%2Cdl%3D12400%2Cmtp%3D25400%2Cnor%3D%22seg_00043.m4s%22%2Cot%3Dv%2Csf%3Dh%2Csid%3D%223c9a7d2e-5b1f-4e8a-9c6d-2f7b8e1a4d05%22%2Cst%3Dv%2Ctb%3D8000
Host: cdn.example.com

Decoded, the payload reads:

bl=12400,br=5000,cid="title-123",d=4000,dl=12400,mtp=25400,
nor="seg_00043.m4s",ot=v,sf=h,sid="3c9a7d2e-5b1f-4e8a-9c6d-2f7b8e1a4d05",st=v,tb=8000

In words: 12.4 seconds of buffer, a 5 Mbps rendition requested over a 25.4 Mbps connection, and a 4-second video segment from an HLS VOD stream whose top rendition is 8 Mbps. Players send the same data either as that CMCD= query argument or as four request headers: CMCD-Object, CMCD-Request, CMCD-Session and CMCD-Status.

Version 2 (CTA-5004-A, published in February 2026 and revised as CTA-5004-B in April 2026) grows the list to 49 keys. It adds dropped frames (dfa) and startup delay (msd), plus an event mode in which the player posts reports to your own endpoint instead of only to the CDN.

Token authentication across CDNs

If you sign segment URLs to stop hot-linking, each CDN has traditionally used its own signing scheme, which forces you to re-sign at the edge for every CDN in the mix. The Common Access Token (CTA-5007, revised as CTA-5007-B in April 2025) is a CDN-neutral alternative built on the CBOR Web Token format.

Support is growing rather than universal. Akamai offers a CAT module for EdgeWorkers that covers part of the specification, and Amazon CloudFront added support through CloudFront Functions in November 2025. Confirm support with every CDN in your mix before you depend on it.

Operational costs to budget for

• Integration. The steering layer, token handling and log pipelines for each CDN. How long it takes depends on how many player platforms you ship, so plan it as a project, not a setting.
• Tuning. A monthly review of per-region performance and routing rules.
• A steering service, unless you run DNS steering or a content steering server yourself. Vendors selling CDN steering for video today include IBM NS1 Connect, NPAW CDN Balancer and IO River, and most quote pricing for video-scale traffic. Citrix's Intelligent Traffic Management, the product that grew out of Cedexis, reached end of life on 31 October 2025.

The bottom line

Multi-CDN is insurance with a running cost. Before your next big live event or new region, put a number on what a single outage would cost, compare it with the net yearly cost of a second CDN, and keep your steering and token layers CDN-agnostic either way. Start a free trial to try OTTEngine with your own content.

Frequently Asked Questions