Cloud Concentration Risk: When Everybody Fails at the Same Time

Concentration risk is the chance that things you treated as independent fail together. It is a different question from whether any one vendor is reliable, and it is the question that turns a contained incident into an industry-wide one.

The distinction matters because the usual analysis is done vendor by vendor. Each supplier is assessed on its own, each one looks acceptable, and the portfolio is never examined. Then a single cloud region has a bad hour and four of your suppliers go dark simultaneously, along with your monitoring vendor, your incident management tool, and the status pages you would have checked.

This article is about the portfolio view: the mechanisms that make failures correlate, why a multi-cloud strategy addresses fewer of them than it appears to, and how to get a number for your own exposure. It is the market-level companion to the hidden cost of single-vendor dependency, which covers single points of failure inside your own architecture.

Shared hosting is the obvious mechanism and the easiest to check. Most SaaS products run on one of a small number of clouds, and many run in one preferred region. Your vendors' infrastructure choices are not usually disclosed and are often discoverable, and the answer is frequently the same region you are in.

The less obvious mechanisms do more damage because nobody maps them. DNS and certificate authorities sit under everything, so a failure there takes out services that share no compute at all. CDN and edge providers are concentrated into very few large networks. Identity providers create a correlation that is invisible until an authentication outage locks your team out of the tools they need to respond to it. And observability is the cruel one: teams route monitoring, alerting, and incident management through vendors that frequently sit on the same infrastructure as the systems being monitored.

Running across two clouds is expensive, slow to build, and genuinely useful against one specific failure: a single provider having a bad day. It does very little against the other mechanisms above, and teams routinely buy it expecting broader protection than it delivers.

The gap is usually the control plane. A deployment spread across two clouds but orchestrated from one, or fronted by one DNS provider, or authenticated through one identity provider, has moved the single point of failure without removing it. A workload that is portable but whose failover is manual and untested has moved the risk into a runbook.

There is also a cost that shows up later. Multi-cloud increases operational surface area, and more surface area means more of the self-inflicted incidents that dominate most teams' downtime. It is entirely possible to reduce correlated third-party risk and increase total downtime, which is not a trade anybody consciously chooses.

The cheaper intervention is usually to identify the two or three shared layers you genuinely depend on and add redundancy at those specific points. A second DNS provider costs little. A break-glass access path that does not route through your primary identity provider costs less than a cloud migration and removes a correlation that would otherwise strike at the worst moment. Operational practice for running across providers is covered in multi-cloud reliability monitoring.

Start with the inventory you may already owe a regulator. Enumerate external dependencies, then annotate each with the layers from the table above: cloud and region where known, DNS, CDN, identity, and any subprocessors you can get named. The output is a list of shared layers with a count of dependencies behind each one.

Read it by shared layer instead of by vendor. If eleven of your forty dependencies resolve to one cloud region, that region is a bigger exposure than any individual supplier on the list, and no amount of per-vendor due diligence would have surfaced it.

Then check the assumption against history. Line up incident timelines across your vendors over the past year and look for overlap. Providers whose degradations repeatedly land in the same hour share something, whether or not either of them documents it, and that observed correlation is more trustworthy than any architecture claim in a security questionnaire.

For entities in scope of DORA, this analysis is close to what Article 29 asks for before contracting for a critical function. The regulatory framing is in DORA and NIS2 third-party ICT monitoring, and the arithmetic for what correlation does to a redundant pair is in dependency chain availability math.

Eliminating concentration risk is not available. The industry is concentrated, most of the alternatives are worse on every other axis, and a strategy that avoids the major providers usually trades a rare correlated failure for frequent ordinary ones.

Three interventions have a good ratio of benefit to cost. Make your incident response path independent of your production path, so an outage never removes your ability to coordinate a response to it. Add redundancy at the cheap shared layers, particularly DNS, where a second provider is inexpensive and the failure mode it protects against is total. And degrade deliberately: decide in advance which features you can turn off to keep the core working, because a product that keeps its main flow alive through a dependency failure has bought itself an option nothing else provides.

Then write the exposure down and review it when something changes. Concentration risk moves when vendors migrate, when acquisitions consolidate suppliers, and when your own team adds an integration on a Friday afternoon. An assessment from eighteen months ago describes a portfolio you no longer have.

What is concentration risk in cloud computing? The risk that suppliers you treat as independent fail at the same time because they share something underneath, such as a cloud region, a DNS provider, a CDN, or an identity provider. It is a portfolio property and is invisible to vendor-by-vendor assessment.

How is it different from single-vendor dependency? Single-vendor dependency is about your own architecture having one supplier for a function. Concentration risk is about many suppliers converging on shared infrastructure below the level anyone diagrams. You can have well-diversified suppliers and severe concentration risk at the same time.

Does multi-cloud solve it? Partially, and only for one mechanism. It protects against a single cloud provider failing, and does little for DNS, certificate authorities, CDN, identity, or your vendors' own upstream suppliers. It also adds operational complexity, which adds self-inflicted incidents.

How do I find out which cloud my vendors run on? Ask during procurement, since many will answer when a contract requires it. DNS resolution, response headers, and IP ownership reveal a good deal for the rest. Subprocessor lists, which enterprise contracts and GDPR arrangements often already require, are the most reliable source.

What is the cheapest meaningful mitigation? Making your incident response path independent of your production path. It costs very little compared with architectural redundancy and it removes the failure mode where an outage also takes away the tools you would use to handle it.