When one provider fails, everything fails: cloud concentration risk
The AWS outage in October 2025 and the Cloudflare outage in November 2025 were a reminder that a shared dependency is a group-level risk. How to map it without duplicating everything.
On 20 October 2025, an outage starting in AWS's US-EAST-1 region, linked to a DNS resolution problem affecting a database service, spread to many dependent services. On 18 November 2025, an internal configuration change at Cloudflare disrupted its traffic for several hours and affected a very large number of sites and applications (TechTarget, SoftwareSeni). The scale figures put forward vary by source; the finding itself is solid: a handful of providers carry a considerable share of the Internet.
Concentration is not lock-in
Vendor lock-in describes the cost of leaving a provider. Concentration risk describes something else: the simultaneous impact on a large number of organizations when a widely used provider fails. You can be free of lock-in and still exposed, if all the services you depend on rest, unbeknownst to you, on the same infrastructure.
Why it is a group matter
In a multi-company structure, each entity makes its own technical choices, and the common dependency is often invisible. One subsidiary's email, another's website and the group's invoicing tool can depend on the same identity provider, the same DNS or the same content delivery network. A single outage then becomes an outage of the whole group, at the very moment communication is needed.
Four useful steps, without duplicating everything
- Map shared dependencies: DNS, identity and authentication, email, hosting, content delivery, payment. The aim is to know which are common to several entities.
- Distinguish critical services from the rest: you don't need redundancy for everything, but for what you can't afford to lose for more than a few hours.
- Plan a degraded mode: a backup communication channel independent of the main infrastructure, local copies of essential data, a manual fallback procedure.
- Test recovery: a recovery plan never executed is a hypothesis. Analyses of these outages insist that recovery must work even when the provider's console, the identity path or the usual automation are unavailable.
What can't be eliminated
Concentration risk can't be reduced to zero. The right question isn't "how do we eliminate it?" but "is the remaining dependency known, proportionate to the service concerned, and backed by a proven recovery path?". Diversifying providers has a complexity cost that can itself create outages; control comes from clarity about dependencies more than from multiplying them.
The link with governance
This mapping is among the questions a group's management can ask its entities, alongside those on security or AI. It ties in with our conviction on open, reversible technologies, developed in the article on that subject: being able to change provider or take back control is a form of resilience.