CDN consolidation means a handful of companies now control who stays online
Between October 2025 and June 2026, four separate outages at AWS, Azure, and Cloudflare each knocked out services spanning streaming, payments, airlines, logistics, and messaging — not because those sectors share a business relationship, but because they share the same handful of upstream infrastructure providers. The internet looks decentralized from the outside. Underneath, a measurable and growing concentration in who runs DNS, CDN, and cloud infrastructure means a single company's bad day can cascade across industries that have never heard of each other.
The concentration is measurable, and it's rising
The Internet Society's Pulse project tracks CDN market concentration among the top 10,000 most-visited websites using the Herfindahl-Hirschman Index, the standard economic measure of market concentration. That index rose from 2,448 in June 2021 to 3,410 — comfortably past the 2,500 threshold economists generally treat as "highly concentrated." Academic measurement backs this up from a different angle: Cloudflare and Amazon together host over 30% of popular domains for both DNS and web hosting, and adding Google, Akamai, and Fastly brings five providers to roughly 60% of index pages across the Tranco Top-10K.
The dependency runs deeper than direct customer relationships suggest. A separate study found that 89% of Alexa Top-100K websites critically depend on at least one third-party DNS provider, CDN, or certificate authority, and that the top three providers in each category can directly or indirectly affect 50-70% of all sites studied. Indirect dependencies — a site that doesn't use Cloudflare directly but relies on a service that does — amplify a single provider's effective reach by as much as 25 times its direct customer count.
Four outages, one underlying cause
The pattern showed up repeatedly in the thirteen months before this piece was published. In October 2025, a single configuration error in one AWS region disrupted streaming platforms, payment processors, airline booking systems, and parts of global logistics — services with no shared vendor relationship to each other, only a shared dependency on the same regional infrastructure. Weeks later, on October 29, an Azure Front Door DNS issue took down the Azure Portal, Microsoft 365, Outlook, and Xbox multiplayer simultaneously, because all four products route through the same front-door layer. On November 18, a Cloudflare database permission issue cascaded into failures affecting users well beyond Cloudflare's own direct customers. And in June 2026, a fiber break in the Zayo network triggered a Cloudflare disruption that hit Discord, Reddit, Zoom, and Microsoft Teams across more than 70 countries — a physical cable fault in eastern North America with consequences on a different continent.
None of these incidents involved an attack. Each was a routine operational failure — a bad config push, a permissions bug, a severed cable — that should have been contained to one provider's infrastructure. Instead, each cascaded into unrelated sectors because those sectors share upstream dependencies they mostly don't track.
Why bundling makes this worse
Large providers increasingly bundle DNS, CDN, DDoS mitigation, and hosting into a single integrated stack, which is operationally convenient and typically cheaper and faster than assembling the equivalent from independent vendors. But it violates a core principle of resilient system design — separation of concerns — by letting a fault in one subsystem propagate into caching, routing, and application delivery simultaneously. The June 2026 Cloudflare incident is the clearest example: a physical layer problem (a severed fiber) cascaded into an application-layer outage because the routing and delivery stack wasn't isolated from the network layer beneath it.
What to actually do about it
The mitigations are well understood and rarely implemented at the scale the risk warrants. Multi-CDN configurations, redundant DNS across independent providers, and failover paths that let clients reach origin servers directly when a CDN cache becomes unreachable all reduce single-provider blast radius — but they add cost, operational complexity, and a second vendor relationship to manage, which is why adoption lags the actual risk.
The concrete action for any engineering team reading this: map your actual upstream dependency chain, not just your direct vendor contracts. A service three hops removed from Cloudflare is still a Cloudflare dependency when Cloudflare has a bad day. Test your failover path to origin servers before you need it, not during an outage. And treat "which CDN do we use" as a business continuity question with the same weight as "which cloud region do we deploy to" — because the data above says your answer is increasingly correlated with everyone else's.