What goes down if your cloud provider fails?
The short answer
To see what goes down when a cloud provider fails, trace the dependencies upward: from the region or platform to the systems running on it, to the business services those systems support, to the customers and obligations behind them. The result is the blast radius: every service, customer and obligation one failure hits, ranked by impact.
Your CMDB knows the server. It doesn't know which customers stop paying.
It's 10:00 and a cloud region is down. Five minutes in, someone pulls a CMDB export from last quarter. App owners get paged one by one. The first answer to "who is affected?" sounds like this: "Probably payments. Maybe more."
The information exists. It sits in different places. Asset tools describe the technology. Continuity plans describe the processes. Contracts describe the suppliers. Nobody has connected them, so the impact gets reconstructed under pressure, one phone call at a time.
One outage, three levels of impact
Every outage travels through the same three levels. Take an identity provider failing at 14:00 in a SaaS company:
- Technology
Every service that authenticates through the identity provider stops accepting logins. - Services
Login, the customer API and billing stop. Internal tools follow. - Customers and obligations
Enterprise customers can't log in. SLA credits start to accrue. Your largest accounts want an answer.
In a bank, the same chain looks different. The core payments platform and its identity provider run in one cloud region, and both go down. Card payments, online banking and outgoing transfers stop. The impact tolerance clock starts, and so does incident reporting to the supervisor.
The blast radius is the whole failure chain, all three levels together. Mapping only the first one tells you what broke. The other two tell you what it costs.
Look for the hidden shared layers
The biggest surprises sit in the layers nobody lists as a business application: network, identity, DNS, certificates, shared databases, monitoring. In a large organization's model, the network, the identity provider and the core data centers often sit under hundreds of other assets. A failure there has downstream impact on services that look unrelated on paper.
Your suppliers add another layer. A SaaS vendor you chose to diversify away from one cloud provider often runs on that same provider, sometimes in the same region. Follow third-party chains as far as your contracts and their disclosures allow.
Filter the blast radius by what matters
A full blast radius in a large organization is too big to read in one go. Filter it by the questions leadership will ask first:
- Which customer segments or tiers are hit?
- Which regulated services or critical functions are affected?
- Which SLAs and reporting deadlines start running?
- Which business units need to activate their continuity plans?
That turns a dependency graph into a decision: who to call, what to tell customers, which plans to activate.
Map it before the outage
Pick any system. Can you name everything it takes down? Run that question for your top five platforms and providers before something fails. The results feed three decisions: where a second region or provider is worth the cost, which exit plans you need for critical vendors, and which customer communications to prepare per segment.
A practical way to begin
- List your top platforms and providers: cloud regions, identity provider, network, core SaaS vendors.
- For each one, list the systems that run on it or authenticate through it. Cloud inventories and CMDB exports are enough to start.
- Connect those systems to the business services they support.
- Connect the services to customer segments and obligations: SLAs, contracts, regulatory reporting.
- Rank the providers by how many critical services they take down, and start with the top one.
How we do this in resimate
In resimate, Blast Radius shows every customer, service and obligation a failure hits. Select any asset, from a cloud region to a single vendor, and see the impact across every level, filtered by regulation, business unit or customer segment. It takes seconds instead of hours, and it works before the outage as well as during it. Teams go live in 4 to 6 weeks, on the data they already have.