Ask most companies why they’re running workloads across three different cloud providers and the answer is rarely a strategy document. It’s usually some version of “that’s just how it happened” — an acquisition that came with its own infrastructure, a team that picked a different provider than the last one, a vendor negotiation that made sense at the time. Multi-cloud gets described as a deliberate architecture choice a lot more often than it actually is one.
What Genuine Multi-Cloud Strategy Actually Looks Like
Real multi-cloud is a deliberate bet: specific workloads on specific providers because of a genuine capability difference, a regulatory requirement, or a real resilience need that justifies the added complexity. It comes with a stated reason, a plan for keeping skills and tooling current across each provider, and someone accountable for the tradeoff. It’s rare, and it’s usually visible in how deliberately it’s talked about internally.
What Accidental Multi-Cloud Actually Looks Like
It arrived through inheritance, not decision. An acquired company’s infrastructure never got migrated. A vendor’s product only runs on one provider. A team lead had a preference and nobody overruled it. None of these are wrong reasons to end up somewhere — they’re just not a strategy, and treating the result as if it were one hides how much of the current footprint is actually just historical accident.
Nobody can name the reason for the split, only the history. Ask why a specific workload lives where it does, and a genuine multi-cloud strategy gets you a reason tied to the workload. Accidental sprawl gets you a story about who set it up and when — a fact about the past, not a justification that still holds up today.
The cost of the sprawl is diffuse enough that nobody owns fixing it. Running three providers means three sets of tooling, three sets of specialized skills, three security models to keep current, and none of that shows up as a single line item anyone’s incentivized to reduce. It’s a real, ongoing cost that’s just spread thin enough to stay invisible.
Why the Distinction Actually Matters
A genuine multi-cloud strategy is worth the complexity, because the complexity is buying something specific. Accidental multi-cloud sprawl is paying the exact same complexity cost — the tooling, the skills, the security surface — without buying anything a single, deliberately chosen provider wouldn’t have already delivered for less. Same cost. Very different return.
How to Actually Tell Which One You Have
Ask why each workload is where it is, workload by workload. Not “why are we multi-cloud” as a company-wide question, but the specific reason each individual workload lives on its specific provider. A real strategy answers this cleanly. Accidental sprawl produces a lot of “not sure, that’s just where it’s always been.”
Check whether anyone could actually consolidate if they wanted to. If moving a workload off a provider is blocked by a real constraint — data residency, a genuine capability gap, a contractual term — that’s evidence of intent. If it’s blocked mainly by nobody having gotten around to it, that’s evidence of drift.
Look at whether the complexity is buying anything measurable. Genuine multi-cloud usually has a story about resilience, cost arbitrage, or capability that can be pointed to concretely. Accidental sprawl usually can’t produce one beyond “it’s always been this way.”
The Bottom Line
Multi-cloud isn’t inherently good or bad — it’s a tradeoff that’s either being made on purpose or being paid for by accident. The second one is far more common than most infrastructure diagrams suggest, and it costs almost exactly as much as the first without buying any of the benefit. Worth finding out, workload by workload, which one you’re actually running.