Three Companies in a Trench Coat

November 18, 2025 managed to be two kinds of historic before dinner. That morning, the EU's financial supervisors published their first list of 19 technology providers deemed critical to the European financial system. That same day, a database permissions change at Cloudflare doubled the size of a Bot Management feature file and took a serious slice of the internet offline, including services people were presumably using to read the regulators' announcement. You could not stage a better product demo for a policy document.

Cloudflare's was the third fall in thirty days, after the AWS us-east-1 outage of October 20 and the Azure Front Door failure of October 29. We covered the first one as it happened and the operational lessons afterward. This post zooms out, because at distance the three incidents stop being three stories. The thesis: the modern internet is a small number of companies in a trench coat, its failure modes are now correlated in a way that fits the textbook definition of systemic risk, and regulators have begun treating hyperscalers as critical infrastructure because that is simply what they are.

Three failures, one shape

Put the postmortems side by side and the pattern does the arguing. AWS: a latent race condition in DynamoDB's internal DNS automation, cascading through every service leaning on it. Azure: an inadvertent configuration change rolling through Front Door, taking Microsoft 365 and the Azure portal along. Cloudflare: a permissions change producing an oversized feature file that crashed Bot Management globally. No attackers anywhere. Three routine internal changes, each in a deep shared dependency, each amplified planet-wide by the very consolidation that makes these platforms efficient.

That's the shape worth staring at: the blast radius of a config change is now the dependency graph of the global economy. Payment processors, airlines, hospitals, government portals, and half the consumer internet reported problems across those three afternoons, and most affected organizations had never heard of the specific subsystem that took them down. Nobody chose that exposure. It accreted, one reasonable vendor decision at a time.

The accretion has a transitive layer that makes it worse. Plenty of the companies down on November 18 had no Cloudflare account; their payment provider did, or their auth vendor, or the status-page service they'd have used to announce the outage. Dependency on the trench coat isn't a line item you can read off your own invoices. It's a property of your vendors' vendors, which is why the honest answer to "are we exposed to Cloudflare?" at most companies is a shrug delivered with confidence.

Systemic risk, the finance edition

Finance has a name for this structure, and it earned the vocabulary expensively in 2008: individually rational, collectively fragile. Every company choosing AWS or Cloudflare makes a defensible choice, often the best available choice. Summed, those choices produce a system where failures stop being independent events and start being correlated ones, and correlation is the entire difference between weather and climate in risk. A thousand small hosting providers fail constantly and nobody notices. Three giants fail rarely, and when they do, everything fails at once, which is the failure mode societies are worst at absorbing.

The regulatory response is following the financial script almost beat for beat. Designation lists. Direct oversight of the critical nodes. Concentration limits discussed, exit requirements imposed. The phrase "too big to fail" hasn't formally crossed into cloud policy, and it doesn't need to; a supervisor who requires your bank to hold an exit plan for its cloud provider has already priced the concept in. What October and November supplied was the empirical case, on schedule, in triplicate.

The steelman: concentration is competence

Here's the argument the trench coat deserves, because it's strong. These platforms fail rarely and recover fast precisely because they're huge: hyperscaler reliability engineering is the best in the industry's history, and the average workload sits on dramatically more redundancy, security, and operational skill at AWS than it ever did in the server closet it came from. Per workload-hour, the concentrated internet almost certainly fails less than the fragmented one did. A monoculture of excellent operators may simply be a better deal than biodiversity of mediocre ones, and anyone who lived through the self-hosted 2000s should hesitate before romanticizing them.

Most of that is true, and it's still an answer to a different question. Individual reliability is about how often you go down; systemic risk is about who goes down with you. The consolidated internet trades many small independent failures for few enormous correlated ones, and the correlated kind lands on exactly the systems that can't share an outage window: payments and ambulance dispatch and airline ops, simultaneously, with no fallback because everyone's fallback runs on the same three providers. Excellence doesn't fix correlation. It just raises the stakes of the exceptions.

What does help is what we keep arriving at from every direction on this blog: thin-layer redundancy where failure is loud, tested portability everywhere else, and an honest map of which trench-coat button your own stack hangs from. The map is the part almost nobody has. After October 20, the most common engineering question wasn't "how do we fail over"; it was "wait, why did that break us?", and not knowing was the actual vulnerability.

The regulators have their list of 19 now. The more useful list is yours: which of the three afternoons last autumn would have taken you down, and did you find out by analysis, or by pager?

Related: AWS Goes Dark: October 20, 2025, the first domino, covered as it fell. More about what we're building at light-cloud.com.