Cloud computing can make an individual organization more resilient while making an economy more dependent on a few common suppliers. That tension is moving cloud concentration from procurement discussions into financial-stability and competition policy.

A hyperscale provider can offer multiple regions, mature security controls, rapid recovery, and engineering depth that most customers could not reproduce. Yet many banks, public bodies, and digital businesses rely on the same underlying identity, storage, networking, and management services. A failure in one widely used control plane can therefore affect otherwise unrelated customers at the same time. The relevant unit of risk is no longer just one company's deployment; it is the shared dependency graph beneath an entire sector.

Concentration Has Several Layers

Provider market share is only the most visible layer. Concentration can also occur in a particular region, managed database, identity service, software license, or specialist workforce. Two firms may claim to be “multi-cloud” while both depend on the same identity provider or run their backup environments in facilities connected through common infrastructure. Conversely, using one provider across genuinely independent regions may sometimes be safer than operating a poorly tested second platform.

The U.S. Treasury made the systemic concern explicit in February 2023: “The current market is concentrated around a small number of CSPs” (U.S. Treasury). Its financial-sector review found data gaps that prevented regulators from measuring how a single incident would propagate, while also noting that cloud services can improve security and resilience for smaller institutions. Treasury subsequently formed a public-private Cloud Executive Steering Group to work on transparency, incident coordination, and the definition of cloud concentration risk (U.S. Treasury).

The competition evidence points in the same direction. The United Kingdom's Competition and Markets Authority concluded its cloud infrastructure investigation in July 2025 and recommended considering strategic-market-status investigations of Amazon Web Services and Microsoft (CMA). Its provisional findings had estimated that each accounted for as much as 40 percent of UK customer spending, while highlighting egress charges, committed-spend agreements, technical barriers, and software licensing as obstacles to switching (CMA). Those are competition issues, but they are also resilience issues: an exit plan is less credible when data, skills, and licenses cannot move quickly.

Regulation Is Moving Toward the Providers

Traditional outsourcing rules place responsibility on the regulated customer. That remains necessary, but it scales poorly when thousands of firms individually audit the same handful of suppliers. The European Union's Digital Operational Resilience Act, applicable since January 17, 2025, created direct oversight for designated critical information-and-communications-technology providers. The framework assesses systemic importance, interconnectedness, the criticality of supported functions, and substitutability (European Banking Authority). The first EU list, published in November 2025, was built from financial firms' registers of contractual ICT relationships rather than market share alone (European Banking Authority).

Cloud Concentration Risk Is Becoming a Policy Problem — supporting image
Cloud Concentration Risk Is Becoming a Policy Problem — supporting image

The United Kingdom has taken a related approach. Its 2024 critical-third-party regime allows financial regulators to set resilience requirements and test providers whose disruption could threaten confidence or stability. The Bank of England describes transmission through concentration, interconnectedness, dependence on data, operational contagion, and loss of confidence (Bank of England). This does not make providers utilities, but it recognizes that ordinary bilateral contracts cannot fully address sector-wide externalities.

Resilience Requires Architecture, Contracts, and Evidence

Policy should not equate diversification with a mandatory second copy of every workload. Forced duplication can add complexity, expand the attack surface, and dilute scarce engineering expertise. A more useful approach begins with mapping critical services to their provider, region, control plane, identity system, subcontractors, and recovery dependencies. Regulators can then aggregate anonymized maps to identify common failure points.

Organizations also need tested portability. That means exportable data, documented rebuild procedures, escrow or continuity arrangements where appropriate, realistic recovery-time objectives, and exercises that include loss of a provider's management plane—not merely failure of a virtual machine. Contracts should provide timely incident information and meaningful audit assurance, while policymakers should scrutinize terms that make switching technically or economically impractical.

Cloud concentration is not an argument against cloud adoption. It is a reason to distinguish redundancy inside a provider from substitutability across providers, and firm-level continuity from system-level resilience. The policy challenge is to preserve hyperscale efficiency while making common dependencies visible, governable, and recoverable.

That requires recurring joint exercises among customers, providers, regulators, and critical infrastructure operators. Exercises should publish lessons about coordination delays and recovery dependencies without exposing customer secrets or exploitable technical details.

Sources