Cloud concentration risk is no longer a line item that lives only in a regulator’s slide deck: across the nine years Uptime Institute has tracked publicly reported outages, third-party providers such as cloud giants, telecoms, and colocation companies account for about two-thirds of them (Source: Uptime Institute Annual Outage Analysis 2026).
Your own systems may be fine. The provider underneath them is where the failure usually starts.
On July 23, 2026, that pattern played out again. A defect in Microsoft’s automated maintenance process pulled more network routes than intended out of its West US region, and for roughly five hours businesses lost access to Azure services and Microsoft 365 tools. Nobody at those businesses made a mistake.
They just shared a failure boundary with thousands of other companies, and most of them had never drawn it on paper.
Key Takeaways
- Concentration risk is about shared failure boundaries, not vendor count.
- The July 2026 Azure outage hit traffic crossing one region’s edge.
- EU regulators now oversee 19 providers as systemically critical.
- Your recovery tools often sit inside the same boundary.
- Multi-region is usually cheaper and more realistic than multi-cloud.
What Is Cloud Concentration Risk?
Cloud concentration risk is the exposure you carry when too many of your critical services depend on one provider, one region, or one shared component, so that a single failure takes them all down at once.
It works at two levels. At the company level, it means your ERP, customer app, email, and identity system all fail together. At the market level, it means a whole sector fails together, because every bank, airline, or retailer in a country picked the same three hyperscalers. Regulators care mostly about the second. You should care about both, because the market-level version decides whether your competitors are down too, and whether your customers have anywhere else to go.
A common misconception: having many vendors does not mean you are diversified. You can buy from twenty SaaS companies and still find that fifteen of them run on the same cloud region. Count failure boundaries, not invoices.
What the July 2026 Azure Outage Actually Showed
The facts are worth getting right, because the lessons sit in the details.
Microsoft’s preliminary post-incident review put the disruption between 14:44 and 19:41 UTC. Routine device maintenance required isolating selected network paths. A software defect in the step that turns maintenance requests into automated instructions flagged extra devices as part of the job, so more IP routes were removed than planned. That cut connectivity between West US datacenters and Microsoft’s wide-area network. Engineers started the rollback at 17:45 UTC, network stability returned at 18:26, and all services had recovered by 19:41.
The affected list was long: App Service, Azure Kubernetes Service, Cosmos DB, Azure Database for PostgreSQL, Azure Monitor, Microsoft Graph, Sentinel, VPN Gateway and more. Users across North America reported problems with Outlook, Teams, SharePoint and OneDrive.
Three details matter for planning.
Availability zones did not help. The failure affected traffic entering and leaving the region. Workloads communicating entirely inside West US kept working. If your app was spread across three zones in that one region, it stayed up and still could not reach its users.
Some of the damage was impossible to architect around. You can move your own workloads to a second region. You cannot move Microsoft 365. If your incident bridge runs on Teams and your runbooks live in SharePoint, your response tooling went down with the incident.
Nobody attacked anything. This was a change-management failure inside the provider. Microsoft’s own advice afterwards was to consider multi-region deployment for critical applications and to set up Azure Service Health alerts.
This was not a one-off either. In October 2025, a major AWS disruption was followed about a week later by an Azure Front Door outage that affected Alaska Airlines, Heathrow Airport, and Vodafone. Different providers, different root causes, same outcome for their customers.
Why Regulators Now Treat It as a Systemic Problem
In financial services, concentration risk has moved from guidance to law. On November 18, 2025, the European Supervisory Authorities published the first list of critical ICT third-party providers under the Digital Operational Resilience Act. Nineteen companies made it, including Amazon Web Services, Google Cloud, and Microsoft, alongside data center operators, telecoms, and financial technology specialists.
The designation criteria read like a definition of concentration risk: the systemic impact if a provider fails at scale, how important the dependent financial firms are, how concentrated reliance is across banking, insurance, and markets, and whether the service can be substituted.
Direct oversight of the provider does not move the obligation off your desk, though. Regulated firms still have to map their critical ICT dependencies, test recovery, and hold credible exit plans. If you already run a certified business continuity program, the ISO 22301 certification guide covers how those artefacts map to DORA and NIS2.
Outside finance, no rule forces you to do this yet. Enterprise customers, insurers, and auditors are asking the questions anyway.
Where Concentration Hides in a Typical Stack
Most dependency maps stop at “we run on Azure” or “we run on AWS.” That is too coarse to act on. Concentration usually hides in four places.
The region and the provider network
Availability zones protect you from a single datacenter failure. They do nothing when the region’s connection to the outside world breaks, or when a global service such as a content delivery network, DNS layer, or management plane fails for every region at once. Ask which of your provider’s services are regional and which are global. The global ones are shared by everyone.
SaaS that runs on the same cloud
Your CRM, HR platform, payment provider, and support desk each run somewhere. Many publish their hosting provider and region in trust centers or subprocessor lists. When you line those up, you often find that “diversified” SaaS is really one region wearing different logos.
Identity, DNS, and certificates
If your single sign-on provider goes down, every application behind it goes with it, even the ones hosted elsewhere. The same applies to DNS and certificate services. These are small line items with enormous blast radius.
Your own recovery tooling
This is the one that catches experienced teams. Runbooks in a wiki hosted on the failing cloud. Alerting that routes through the affected region. An incident chat channel on the collaboration suite that just went dark. A status page on the same infrastructure as the product. If the outage takes out your ability to respond, your recovery time objective was fiction.
Multi-Region, Multi-Cloud, or Accept the Risk?
There is no universal answer, and anyone selling one is selling something. The honest trade-offs look like this:
| Approach | Protects against | Main cost | Fits best when |
|---|---|---|---|
| Multi-zone, single region | Datacenter failure | Low | Non-critical workloads |
| Multi-region, single provider | Regional outages like July 2026 | Moderate: data replication, duplicate capacity | Customer-facing systems with tight recovery targets |
| Multi-cloud active-active | Provider-wide failures | High: two skill sets, lowest-common-denominator services | A small number of truly critical, regulated services |
| Documented risk acceptance | Nothing technical | Low, but requires sign-off | Workloads where hours of downtime are tolerable |
Multi-cloud gets a lot of airtime. In practice, running the same critical workload actively on two providers doubles operational complexity and often forces you onto the few services both clouds share. For most organizations, a well-tested second region with the same provider buys most of the protection for a fraction of the effort, and most existing infrastructure resilience tooling already supports it.
Multi-cloud earns its cost for a narrow set of services where a provider-wide outage would be existential or where a regulator expects a credible exit path.
How to Reduce Cloud Concentration Risk in 90 Days
You do not need a transformation program. You need a map, a test, and a few uncomfortable conversations.
Month one: draw the real map
Pick your five most critical business services. For each one, list every dependency down to the region: hosting, databases, identity, DNS, payment processing, messaging, the SaaS tools staff need to operate it. Then mark which items share a failure boundary. This takes days, not months, and it is the step most organizations have never done.
Month two: move recovery out of the blast radius
Keep runbooks somewhere readable when your main cloud is down, even if that is an exported PDF. Set up an out-of-band communication channel for incident responders on a different provider. Host your status page independently of your product. Check that alerting still works if the primary region disappears.
Month three: test and renegotiate
Run a region-evacuation exercise for one critical service, even a partial one. Run a tabletop for a scenario where your collaboration suite and your cloud fail together. Then read your contracts. Cloud service level agreements typically pay service credits, not your actual losses, so compare the credit you would receive for a five-hour outage against what those five hours would cost you. The gap is the risk you are self-insuring. Cyber and business interruption insurers increasingly ask about this, so the analysis doubles as underwriting evidence. If ransomware is also on your risk register, the same dependency map feeds straight into that planning.
Conclusion
Cloud concentration risk will not go to zero. The hyperscalers run huge, well-engineered platforms, and moving off them would usually make you less resilient, not more. The goal is narrower: know exactly where your shared failure boundaries are, make sure your response tools sit outside them, and match the level of redundancy to what each service is actually worth.
Start with the map. Five critical services, every dependency, down to the region. When the next provider outage lands, and the data says it will, you want to already know which of your services go dark, how long they can stay that way, and who picks up the phone.
Read Next
More on continuity and infrastructure resilience:
- How Server Imaging Simplifies Disaster Recovery and System Deployment
- Guide to Portable Cloud Integration with Local Software Systems
- The Contact Center Crossroads: The On-Premise vs Cloud Showdown
Frequently Asked Questions
Cloud concentration risk is the danger that one provider failure takes down many of your critical services at the same time. It happens when hosting, SaaS tools, identity, and recovery tooling all share the same provider or region. The risk exists at company level and across whole industries.
Multi-cloud reduces cloud concentration risk for the workloads you actually run on both providers, but it does not eliminate it. Shared SaaS, identity services, and DNS can still create single points of failure. It also adds significant cost and complexity, so most organizations reserve it for a few critical services.
The July 2026 Azure outage showed cloud concentration risk at the regional level. A maintenance automation defect removed network routes in West US, cutting traffic in and out of the region for about five hours. Businesses that relied only on availability zones in that region, or on Microsoft 365 for incident response, lost access regardless of their own architecture.
DORA addresses cloud concentration risk by designating critical ICT third-party providers for direct EU oversight. The first list, published in November 2025, named 19 providers including AWS, Google Cloud, and Microsoft. Financial firms must still map dependencies, test recovery, and maintain exit plans for critical services.
The first step to reduce cloud concentration risk is mapping dependencies for your most critical services down to the provider and region. Include SaaS tools, identity, DNS, and the systems your team uses to respond to incidents. Without that map, you cannot see which services share a failure boundary.
