Multi-CDN has a quiet cost multiplier: two platforms means two caches missing independently against your origin, and if that origin is hyperscaler object storage, every miss is billed egress. The fix is architectural — make the shared origin a store that charges nothing for the bytes leaving it — and it happens to solve a second multi-CDN problem at the same time: neutrality, so no CDN’s cloud sibling gets a structural advantage. Here are the economics, the setup, and the fine print.
The egress tax multi-CDN quietly doubles
Run the arithmetic once and the motivation writes itself. Origin traffic equals delivered traffic times miss ratio — and splitting across CDNs raises the effective miss ratio, since each platform’s cooler cache misses more (the dilution mechanics from our fragmentation analysis). Bill those misses at hyperscaler egress — on the order of $0.09/GB from the biggest cloud — and a petabyte-a-month estate with a blended 10–15% miss ratio is paying five figures monthly just to feed its own caches, doubled-ish by the second CDN. Shields help (each platform’s shield collapses its own edges’ misses, per origin shield) but every shield still misses to the origin independently. Zero-egress storage attacks the unit price instead: the per-GB egress line goes to zero, and origin cost becomes storage plus requests — flat-ish, predictable, and indifferent to how many CDNs you add.
The zero-egress field, with numbers
Three names dominate the pattern, with different shapes of “free.” Cloudflare R2: $0.015/GB-month storage, zero egress to anywhere, S3-compatible API — the reference choice, with the caveat list in section five. Backblaze B2: $6.95/TB-month, free egress up to three times stored volume monthly (then ~$0.01/GB) — and unlimited free toward bandwidth-alliance partners including Cloudflare and Fastly, which multi-CDN estates on those platforms should notice. Wasabi: $7.99/TB-month flat with free egress under a fair-use policy (roughly: monthly egress not exceeding stored volume, minimum-retention terms apply) — suited to large, stable libraries. Against ~$0.09/GB hyperscaler egress, any of the three typically cuts the origin line by an order of magnitude for delivery-heavy workloads; the full matchup, including where hyperscaler storage still wins, is in CDN vs object storage. Verify current terms at decision time — free-egress policies carry conditions, and conditions move.
The setup: one bucket, every CDN
The architecture is deliberately dull: one bucket (or one per content class), every CDN configured with it as origin over its S3-compatible endpoint, so identical paths yield identical objects on every platform — the exact groundwork property that video switching and every parity test depend on. Three configuration notes earn their space. Authentication: keep the bucket private and have each CDN sign its origin fetches (the platforms support S3-style origin auth), plus per-CDN credentials so the store’s logs attribute fetches — the same identify-your-caller principle as origin protection, in storage form. Headers: object stores serve what metadata says, so set Cache-Control and Content-Type at upload time as part of the publishing pipeline — there is no origin app to fix it later. Shields: still worth running per CDN even at zero egress, because request fees and origin latency remain real; the shield now buys speed and request-count, not bandwidth savings.
Consistency, purging and the update flow
A shared origin does not synchronize your CDNs’ caches — each platform still holds its own copies on its own clocks — so the update flow must be designed once, properly. The clean answer is the one this site keeps arriving at: immutable, versioned paths for everything that can bear them (assets, media, releases), which makes multi-CDN consistency automatic — new version, new path, no cross-platform purge choreography at all, per asset versioning. For the genuinely mutable remainder, a change means: update the object in the store, then purge every CDN, in parallel, through one script or pipeline step — never by hand per dashboard — and verify propagation on each platform, because purge semantics and speeds differ (the per-platform reality is in purging without pain). An unpurged second platform serving week-old content to 30% of users is the signature incident of shared-origin estates that skipped this paragraph.
Caveats, durability and when to say no
The honest fine print. Feature gaps: the zero-egress tier trails hyperscalers on ancillary features (R2, notably, has lacked object versioning and object-lock-style retention — check current state against your compliance needs); if your pipeline leans on bucket-event ecosystems, lifecycle sophistication or same-region compute adjacency, score that before moving. Performance: these stores are fewer-region than the hyperscalers; with CDN shields in front, origin latency is a second-order concern for delivery, but measure your miss-path TTFB rather than assuming. Migration: moving a large library out of a hyperscaler incurs one final egress bill — price the payback period; it is usually months, not years, for delivery-heavy estates. And the “no” cases: dynamic origins (this pattern is for objects, not applications), tiny estates where the absolute savings don’t cover the project, and workloads contractually pinned to a cloud. For everyone else, the pattern quietly removes the one line item that used to grow every time resilience did.