Multicloud

Multicloud means using more than one public cloud provider. It is not a separate deployment model in NIST SP 800-145, and provider count alone does not establish the portability required by the NIST hybrid definition. State the arrangement and its tested capabilities separately.

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

How the estate was assembled helps identify which ownership, integration, and operating decisions still need attention.

Deliberate means the organization has evaluated a requirement or benefit, chosen integration points, and assigned ownership. Residency, provider capabilities, acquisitions, or concentration risk can motivate it; the rationale needs review as conditions change.

Accumulated means independent choices produced the estate before there was a shared operating design. Assess duplicated work, access lifecycle, observability, and integration costs rather than assuming every such estate has the same defects.

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

Google Cloud identifies several potential drivers. Each needs a workload-specific case and a statement of the capability it actually provides.

Driver	What it actually gets you
“Heeding laws and regulations about data sovereignty”	Real, and specific. The requirement is met by a particular region and service, so check the obligation rather than assuming a second provider is the answer
“Using the unique capabilities from each CSP”	Name the required capability and compare its value with the added operating cost. Reassess when another provider offers a suitable alternative
“Avoiding vendor lock-in”	Commercial leverage and in-house knowledge of a second platform — not portability of workloads. See below
Improving availability	Test loss of the intended failure domain against recovery time and data-loss objectives, including independent identity, routing, state, and capacity. Demand bursting alone is insufficient

Compare multi-zone and multi-region designs inside a provider before adding another. Provider-operated services still have specific recovery behavior and customer responsibilities. A separate provider can address a different failure or concentration scenario only when its recovery path works without the failed dependency.

What it costs, in four places

Management, security consistency, integration, performance, and reliability all add recurring work. Estimate the responsibilities for each environment instead of treating them only as migration tasks.

• Identity. Define lifecycle authority, authentication, account and group synchronization, permissions, and revocation. Multiple directories can implement one controlled lifecycle. Test effective access removal and the identity path needed during an outage.
• 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. Provide cross-environment visibility with shared identifiers, timing, and investigation workflows. Sensitive application data may need separate storage from operations data. Choose destinations, retention, access, and collection-outage behavior deliberately rather than requiring one repository for everything.
• Skills. Ensure each environment and their connections have trained responders, coverage, and escalation. Include the cost of developing and retaining that capability.

These responsibilities belong in total cost of ownership. Shared interfaces and operating conventions can reduce duplication while implementations remain provider-specific. Compare the value, maintenance effort, and common dependencies of shared tooling rather than equating standardization with one central runtime.

What it does not fix

Operating in two clouds and moving a workload between them are different capabilities, and both can be costly. Managed databases, identity integrations, messaging behavior, and operational tooling may require adaptation or replacement during a move. An account with another provider does not demonstrate that this work is complete.

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. For each important system, use that estimate alongside a tested migration plan to assess whether moving is a feasible option.

Multicloud and hybrid cloud describe different properties. Under NIST, hybrid combines distinct cloud infrastructures with technology enabling data and application portability; it does not require different deployment-model categories. A second environment reduces a specified concentration risk only if the required service can work without the failed dependency. Two Clouds, Twice the Operations explains the design conditions.

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
• Google Cloud, Identity reference architectures
• Google Cloud, Hybrid and multicloud monitoring and logging patterns
• Google Cloud, Cloud bursting pattern