Cloud concentration risk has always existed — what's new is that it's starting to show up denominated in currency instead of uptime percentages. A report from the UK's Cyber Monitoring Centre and Parametrix this July put a number on what most enterprises have only ever gestured at: a 24-hour outage in AWS's Dublin region could cost UK firms roughly £1 billion in direct revenue losses; a comparable outage in the Northern Virginia region, around £650 million — figures that exclude supply-chain and downstream customer impact entirely. AWS disputed the methodology. The dispute itself is beside the point. The headlines focused on probability — how likely, how rare, how "acceptable" a 99.99% SLA makes the risk sound. That's the wrong question. The number worth sitting with isn't how often this happens. It's how much it costs when it does, and how few organizations have ever tried to calculate that figure for their own architecture — cloud concentration risk, quantified instead of assumed.
The Blind Spot in Every Cloud Cost Model
Every enterprise with a cloud strategy has a cost model. Most are reasonably sophisticated — they track spend by service, reserved-instance utilization, licensing exposure, egress, the slow bleed of idle resources nobody decommissioned. Some go further and model migration cost, the one-time hit of moving a workload from A to B.
None of that models what happens when the workload can't move at all, on the timeline that matters, because it's concentrated somewhere it can't get out of fast enough. Concentration exposure, dependency exposure, single-region exposure — these don't appear as line items anywhere, because they're not costs you pay continuously. They're costs you pay once, catastrophically, on a day you didn't pick. A financial model that only counts recurring spend is structurally blind to the biggest number on the page.
This isn't a cloud strategy failure of diligence. It's a category error. Teams are pricing the infrastructure they're running. They're not pricing cloud concentration risk — the infrastructure they're not diversified out of — and that second number is frequently larger than the first.
The Architectural Decision Nobody Prices
Every placement decision an architecture team makes carries an implicit cloud concentration risk bet, whether anyone frames it that way or not. Single region. Single cloud provider for a given service tier. Single identity provider gating access to everything downstream. Single control plane orchestrating a fleet that looks distributed until you ask what happens if the orchestrator goes dark.
None of these decisions are wrong on their face. Concentration is frequently the correct engineering call — it's cheaper, it's simpler to operate, it reduces the surface area for configuration drift. The problem isn't that concentration exists. The problem is that it's adopted as a default without ever being priced as a liability. An architect who chooses single-region deployment because the workload doesn't justify multi-region complexity has made a defensible decision. An architect who ends up single-region because nobody ever asked the exposure question has made an accident that happens to look like a decision.
Your cloud provider isn't your HA strategy by default, and the SLA on the account doesn't change that — provider SLAs cap what the vendor owes you, not what the outage costs you. Not every concentrated dependency needs mitigation. All of them need to be understood well enough that "we accept this" is a decision someone actually made, not a default nobody noticed.
Cloud Concentration Risk Is an Economic Variable
Here's the inversion that actually matters, and it's a small one: most resilience conversations start with "how likely is this to happen." The economically useful version of the question starts somewhere else — "what does it cost if this dependency is unavailable for 24 hours," asked before anyone gets to probability. Treating cloud concentration risk as an economic variable, not a reliability footnote, is what makes that reordering possible.
That ordering matters because probability is genuinely hard to estimate and easy to argue about. Hyperscaler regional failure rates are low, and reasonable people can spend a long time debating whether "low" means quarterly, annual, or once-a-decade. Cost, by contrast, is knowable right now, from data you already have — revenue-per-hour by workload, the labor cost of an all-hands incident response, contractual SLA penalties, the reputational cost of a customer-facing outage during a peak window. You don't need to agree on probability to agree on magnitude. And magnitude is what makes a board pay attention, because boards are underwritten in dollars, not uptime percentages.
This is why concentration risk has an identity problem inside most organizations: it gets filed as an availability/reliability concern and routed to infrastructure teams, when the framing that actually gets budget approved is a financial-exposure concern routed to the people who own risk capital. Same underlying architecture. Completely different conversation, depending on which vocabulary you use to describe it.
A Simple Exposure Model
The UK study's own figure is a useful trigger, not a template you can copy onto your own environment — its number is scoped to a specific regional dependency and a specific national market. What's reusable is the shape of the calculation underneath it. Something close to this, deliberately not mathematically precise, works as a working model:
Exposure = Business Impact × Duration × Dependency Concentration
01 — Business Impact
Revenue, contractual penalty, and operational cost per hour of the dependency being unavailable, for the specific workload in question — not the org-wide average.
02 — Duration
The realistic outage window for the failure class you're pricing — not the SLA's target, and not the vendor's best-case number. Use your own postmortem history or public incident data for the provider, not the marketing page.
03 — Dependency Concentration
How much of the affected capability sits behind this single point, expressed as a fraction. A workload split evenly across two regions has roughly half the concentration exposure of the same workload sitting entirely in one.
Run this per critical dependency — region, provider, identity system, control plane — and you get a ranked list of where your organization's actual cloud concentration risk sits. It won't survive an actuary's audit, and it isn't meant to. It's meant to move the conversation from "we think this matters" to "here's the number, and here's what drove it," which is the only version of that conversation an executive sponsor can actually act on.
What Boards Are Actually Paying For
Once exposure has a number attached, the mitigation conversation changes shape. Multi-region deployment, secondary providers, operational redundancy — none of these get purchased because uptime is a nice-to-have. They get purchased because a board or an executive sponsor was shown a liability number large enough to justify the spend to close it, or specifically to justify not closing it because the number wasn't big enough to matter.
That second outcome is not a failure state. A workload with low business impact, short realistic duration, and low concentration might correctly stay concentrated — the exposure number says so, explicitly, instead of by default. That's the entire point of doing the math: it turns "we should probably diversify this" from a gut call into a decision with a number behind it, in either direction.
What boards are actually buying when they fund resilience work isn't availability. It's a reduction in cloud concentration risk that was already a liability on the books, priced or not. The organizations that get this backwards — that pitch multi-region as an uptime improvement — routinely lose the budget conversation to teams pitching something with a hard-dollar payback. The organizations that pitch it as concentration-liability reduction, with the exposure number attached, tend to win it. Same architecture. Different vocabulary. Different outcome in the budget meeting.
Exposure estimates like this one are only meaningful if the continuity assumptions behind them can actually be executed when the dependency fails — a validated recovery mechanism that nobody can actually operationalize into resumed business function is its own separate boundary, distinct from the exposure question this post is asking.
Architect's Verdict
Cloud concentration risk has always had a price. What's changing is that studies are starting to put a number on it, which means "we hadn't thought about it that way" is no longer a defensible position for the teams whose job is thinking about it that way.
The mistake isn't concentrating critical workloads — concentration is frequently correct engineering, and diversifying everything by default is its own expensive failure mode. The mistake is not knowing the number. An architect who can't produce a rough exposure figure for their organization's top three dependencies isn't making a risk-informed placement decision. They're making a placement decision and calling it risk-informed after the fact.
Price the exposure first. Decide on mitigation second. Everything else is guessing with better vocabulary.
Originally published at rack2cloud.com
Top comments (0)