A second CDN looks like insurance until the first invoice arrives. Priced band by band on Bunny's published Volume ladder, 2 PB a month costs at least 20% more split evenly across two accounts than on one — 38.5% more if you take the 1–2 PB rate from Bunny's marketing page rather than its documentation. The ratio you send to the second provider sets your bill, your cache hit ratio and your real failover time at once. This article settles how to pick it.
What a multi-CDN strategy actually is
A multi-CDN strategy delivers the same content through two or more CDN providers, with a steering layer deciding which one serves each request. It is built three ways: DNS-based steering, client-side selection inside the player or application, and manual failover by changing a record when something breaks. They differ in how fast they react and in what they can measure.
DNS steering is the common choice because it needs no application change; Cloudflare's Load Balancing documentation, for example, lists five global steering policies — Standard, Geo, Dynamic, Proximity and Least Outstanding Requests (Cloudflare, 2026). Client-side selection reflects real delivery performance, because the player measures what the user got, but it requires you to own the client.
The decision most teams skip is not which mechanism, but what share of traffic the second provider carries in steady state. That number reorders every other answer below.
The split ratio sets the bill, and the worst ratio is 50/50
CDN volume pricing is a descending ladder. Where it is applied band by band to one monthly total — which is how the published labels read ("First 500 TB", "Next 10 TB"), although neither Bunny page states the method — splitting the traffic restarts each provider's meter at the top band. Because the marginal rate falls as volume rises, the penalty on two identical ladders is largest at the even split, the configuration that looks most redundant.
The table isolates the effect by pricing one published ladder against itself, one account against two. A real second vendor has a different ladder, so read it as the mechanism, not a quote.
| Published ladder | Monthly volume | One provider | 50/50 split | 90/10 split | Premium at 50/50 |
|---|---|---|---|---|---|
| Bunny Volume ($0.005 first 500 TB, $0.004 to 1 PB) | 500 TB | $2,500 | $2,500 | $2,500 | 0.0% |
| Bunny Volume | 1 PB | $4,500 | $5,000 | — | +11.1% |
| Bunny Volume, 1–2 PB at $0.003 (docs page) | 2 PB | $7,500 | $9,000 | $7,900 | +20.0% |
| Bunny Volume, 1–2 PB at $0.002 (marketing page) | 2 PB | $6,500 | $9,000 | $7,100 | +38.5% |
| Fastly, one region ($0.12 to 10 TB, $0.08 next 10 TB) | 20 TB | $1,988 | $2,376 | — | +19.5% |
Rates: bunny.net/pricing/cdn, bunny.net/docs/cdn/pricing and fastly.com/pricing, all read 15 October 2026. Bunny's two pages disagree on the 1–2 PB band, so both rows are shown. Fastly bills "per GB per Region per month"; its free first 100 GB is included.
Three things fall out of that table no single provider will say.
Below the first band boundary, splitting is free. At 500 TB both halves stay inside Bunny's first Volume band, so the split costs nothing. Tier dilution only exists once your single-provider volume has crossed a discount boundary — so below that point the cost argument against a second CDN does not apply.
The cheapest split is the one that protects you least. At 2 PB, moving from 50/50 to 90/10 cuts the premium from 20.0% to 5.3% on the documentation rate (38.5% to 9.2% on the marketing rate), and 95/5 cuts it to 2.7% (4.6%). Every point saved there comes from traffic taken away from the provider you are paying to keep warm.
Above a certain volume the comparison stops being possible. Fastly's public rate card ends after the "Next 10 TB" band, with "Contact us for high-volume pricing" above the table; Bunny's Volume ladder ends at "2 PB+" with "Contact us". A multi-CDN plan at real scale is a negotiation, and the published cards are only your opening anchor. Before assuming the split is cheap, see how to cut CDN costs before you add a second provider.
Failover is slower than your TTL, and lowering the TTL makes it worse
DNS-based CDN failover is not instant. Detection takes the health-check interval multiplied by the retry count — Cloudflare's own monitor documentation works an example in which five retries at a 20-second timeout mark an endpoint unhealthy "after approximately 120 s (6 × 20 s)" — and the record change then has to outlive every resolver cache still holding the old answer.
The instinct is to cut the TTL to 30 or 60 seconds. Measurement data says that makes the tail worse rather than better. Bhowmick et al. measured 27,131 resolvers across 9,514 autonomous systems. At a 60-minute TTL, 0.31% of the resolvers tested extended it; as the test TTL was lowered step by step to one minute, the share rose to 8.74% of the resolvers measurable from at least five vantage points. The authors estimate the effect reaches "at least 38% of the popular websites that use CDNs" (Bhowmick et al., PAM 2023).
So the shortest TTL you set is not the longest wait you get. Close to one in eleven of the resolvers measured extended a short TTL, which keeps their users on a CDN you have already pulled from rotation. Plan the failover window as detection plus TTL plus a non-compliant tail.
The standby cache is the cost nobody quotes
Each CDN maintains its own cache. A provider carrying 5% of your traffic sees 5% of your request volume, which means the long tail of your catalogue is never resident in it. When you fail over, you do not move traffic onto a warm CDN. You move it onto a cold one, and every miss becomes an origin fetch.
The arithmetic is unforgiving because miss rate, not hit rate, is what the origin feels. Fastly's engineering team puts it plainly: "If your CHR increases from 90% to 95%, it's not merely a 5% improvement; it actually halves your origin load" (Fastly, 2024). Run that backwards. A standby whose hit ratio starts at 50% instead of a steady-state 95% delivers ten times the origin fetch volume of the provider it just replaced — at the exact moment you are already in an incident.
Fastly's shielding case study shows the scale in production: with shielding, one customer's origin load was "capped well below 5GiB/s"; without it, at a similar hit ratio, it settled "in the low 20GiBs range," which Fastly describes as 4x the shielded load (Fastly, 2024). Shielding suppresses that, and shielding is per-vendor — provider B's shield cannot read provider A's cache. Two CDNs means two independent fill paths against one origin.
That is the hidden cost of a multi-CDN strategy: it appears on neither CDN invoice. It lands on your origin egress bill. If your origin sits in a hyperscaler, see cloud egress fees comparison for what those fetches cost per GB.
What breaks in production
The cold standby turns a CDN incident into an origin incident. The failure mode is not that the second CDN is slow. It is that your origin saturates while it fills. Load-test the failover at real traffic, not at 1%.
Shielding inflates the miss count you monitor on. Fastly documents that "a request that does reach your origin server will be counted as two misses, one at the edge, and one at the shield." Fastly adds that this "will result in a cache hit ratio (CHR) that may be lower than you expect" — enabling shielding can make the reported hit ratio look worse while origin load falls. Judge it on origin bytes, not on CHR.
Anycast routing can move you into a more expensive billing region. Fastly's billing documentation states that Anycast IPs "will route a request to the nearest POP located in a billing region that may charge a higher rate." Two providers means two independent region maps, and traffic you believed was European can be billed otherwise at one of them.
Package terms can carry geographic caps. Fastly's Deliver packages carry the footnote "No more than 10% of traffic may originate in the African, Indian, or South Korean billing regions." A steering policy that shifts traffic by latency can walk a contract into breach without anyone reading the clause.
You cannot attribute a failure without a per-response identifier. When a user reports a broken session, nothing in a standard response says which CDN served it. CTA-5006, Common Media Server Data, defines response headers that give "a uniform method for media servers and services to communicate data about media objects," and AWS Elemental MediaPackage uses its n key for "The identifier for the MediaPackage origin endpoint of this object" (AWS, 2026). Without an equivalent header or log field at every provider, a multi-CDN incident review is guesswork.
Measure these seven things before you split traffic
Your single-provider monthly volume against your current ladder. Find the next band boundary. Below it, tier dilution is zero and the cost objection does not apply to you.
Origin egress over 30 days, in bytes, not requests — the number a second cache will increase.
Cache hit ratio by content class — hot catalogue versus long tail. The long-tail ratio is what the standby will actually deliver on day one.
Health-check detection time end to end: interval × retries, measured, not assumed. Then add your TTL.
Resolver behaviour on your own zone. Change a record, then watch the decay curve of requests to the old target. That tail is your real failover window.
A parallel run. Serve a sampled share of live traffic through the candidate provider for a full week including a weekend peak, and compare delivered performance from the client rather than from either vendor's dashboard. CDN optimization: cache hit ratio, TTL and origin load covers the measurement setup.
Your contracts. Minimums, commitments, region caps and the overage rate above the published card — for both providers, in writing, before the split.
Choosing the ratio
Three questions decide it, in order.
Is your volume past a discount boundary? If not, choose the split on resilience grounds alone. If it is, price 50/50, 90/10 and 95/5 against your actual ladder first — at 2 PB on Bunny's ladder, the gap between 50/50 and 95/5 is 17 to 34 percentage points.
Can your origin survive the standby filling at full traffic? If not, give the second provider a higher steady-state share, paid for as cache warmth, not redundancy. A 5% standby is a 5% guarantee.
Can you attribute a failure to a provider within one incident? If not, build that before the second CDN, not after. A multi-CDN setup you cannot debug is two vendors blaming each other.
Read together, the three sections above point one way: a single well-chosen provider with shielding beats a badly-split pair, and a share chosen deliberately — priced against your ladder and tested against your origin — beats both a default 50/50 and a reflexive 95/5. We buy across providers rather than for one, so the split ratio is a configuration choice here, and one invoice covers every provider in the test. Bring us 30 days of volume, origin egress and hit-ratio figures and we will price the split three ways before you commit to either vendor — see how our data delivery service handles multi-provider sourcing. If you are splitting because one provider is exiting, the CDN shutdown migration playbook sequence applies first.
FAQ
Does a multi-CDN strategy always cost more?
Not always. Below your provider's first discount boundary, splitting traffic costs nothing extra, because both halves stay in the same band. Above it, the penalty grows with volume and peaks at an even split — on Bunny's published Volume ladder, 11.1% at 1 PB a month and 20% to 38.5% at 2 PB, depending on which Bunny page you price from.
How fast is multi-CDN failover in practice?
Slower than the TTL suggests. Detection takes the health-check interval times the retry count, and Cloudflare's documentation gives roughly 120 seconds for six 20-second attempts. The record change then has to expire in every resolver cache, and measurement data shows a minority of resolvers extend short TTLs beyond their stated value.
Should I lower my DNS TTL to speed up failover?
Within limits. A 2023 study of 27,131 resolvers found 0.31% extending a 60-minute TTL, rising to 8.74% as the test TTL was lowered to one minute, so very short TTLs increase the share of resolvers that hold your record longer than instructed. A short TTL shortens the median failover and lengthens the tail.
What traffic share should the second CDN carry?
Enough to keep its cache representative of your catalogue, which for most workloads is more than the 5% a hot-standby design implies. Measure your long-tail hit ratio at the candidate share during a parallel run; if it is far below your primary's steady state, the standby is not yet a standby.
Does multi-CDN increase origin load?
Yes. Each provider fills its own cache independently and each vendor's shield is private to that vendor, so the same object can be fetched from origin twice. The effect is largest on long-tail content and shows up on your origin egress bill rather than on either CDN invoice.
Can I run multi-CDN without changing my application?
Yes, with DNS-based steering, which is why most teams start there. The tradeoff is measurement: DNS steering decides from health checks and routing data rather than from what the user actually received. Client-side selection reacts to real delivery performance but requires you to control the player or application.
