Multicloud

Multicloud means using more than one public cloud provider. The first thing to notice about the term is that it is absent from the standard taxonomy: NIST lists four deployment models — private, community, public, and hybrid — and running two public clouds is not one of them. Nor does using two make an estate hybrid in the standard sense, which asks additionally that the parts be bound together so that data and applications can move between them. Descriptions here follow NIST and the Google Cloud architecture guidance, checked in September 2026.

That absence is a hint rather than a criticism. Multicloud is not an architecture; it is a procurement and operational situation. Which is why two organizations that both call themselves multicloud can have nothing in common, and why how do we do multicloud has no general answer.

Deliberate or accumulated

The distinction that predicts how much trouble an estate is in has nothing to do with which providers are involved.

Deliberate means a constraint forced it and someone can still state the constraint: a residency rule, a system that cannot move, a capability only one provider offers, an acquisition, or concentration risk. There is a stated boundary, a chosen integration point, and an owner for both sides.

Accumulated means it happened: teams chose independently, a proof of concept stayed in production, a vendor arrived with its own cloud. What exists is several partial platforms, each with its own identity, monitoring, and patching, and the cost is paid in incidents rather than in a budget line.

The responses differ. A deliberate estate should be operated, with the boundary kept narrow. An accumulated one needs a decision — consolidate, or make it deliberate — and the one option that keeps costing without deciding is leaving it as it is. A useful first step for the second case is to name one place where new workloads go by default, which stops the growth while the existing estate is worked through.

The documented reasons, and what each is worth

The Google Cloud guidance lists the common drivers. Three of them hold up well and one needs qualifying.

Most availability requirements are met inside one provider, using multiple zones and regions that the provider operates. The narrower case for a second provider is a provider-wide failure, an account-level event, a regulatory demand for independence, or being able to leave — and naming which one applies is what makes the design arguable.

What it costs, in four places

The same guidance is direct about the bill: “common challenges associated with developing a multicloud strategy include the following: increasing management complexity. Maintaining consistent security. Integrating software environments. Achieving consistent cross-cloud performance and reliability.” In practice that lands in four recurring costs.

• Identity. Either federate to one authoritative directory or maintain two sets of accounts and two joiner-mover-leaver processes. The second is how access outlives employment.
• Policy. Each non-negotiable rule needs two implementations in mechanisms that do not inherit the same way — which is a reason to keep the list of such rules short.
• Observability. Documented as a trap: each cloud’s own tools produce “siloed visibility, which prevents building advanced threat intelligence across the entire environment,” while a centralized view “avoids the need for manual correlation between different tools and dashboards from different platforms.” Choose the single destination before the first cross-environment incident.
• Skills. Each platform needs people who know its failure modes, and on-call must cover both. A team expert in one and adequate in the other has one cloud and a liability.

All four recur, so they belong in total cost of ownership rather than in a project budget. The way to reduce them is to standardize the interface teams use — one pipeline, one policy repository, one monitoring destination — rather than to pretend the platforms are interchangeable. An abstraction layer that claims to make two clouds identical adds a third system to operate and leaks at the points that matter.

What it does not fix

Being in two clouds and being able to move between them are different properties, and only the second is expensive. A service built against one provider’s managed database, identity model, and messaging still has to be rebuilt to run elsewhere; holding an account with the other provider changes none of that.

So the useful form of a portability position is an estimate per significant system — foundation redesign, data transfer, dual running, retraining — stated as an exit cost. A team that can name that number for its three most important systems has more real optionality than one with accounts everywhere.

Two boundaries are worth keeping straight. Multicloud is not the same as hybrid cloud, which is a composition of different deployment models with portability between them. And it does not reduce concentration risk unless the second environment can actually run without the first — a demanding property, and a testable one. How these conditions are designed for is worked through in Two Clouds, Twice the Operations.

References: NIST SP 800-145, The NIST Definition of Cloud Computing; Google Cloud Architecture Center, Drivers for hybrid and multicloud architectures; Google Cloud Architecture Center, Other considerations.