Hybrid Cloud and Multicloud Design

Consider two fictional organizations. One runs its core system in its own datacenter and analytics in a public cloud, joined by a private circuit. The other uses one cloud for most work and another for a machine learning workload. Both describe themselves as hybrid multicloud, although their integration and operating requirements differ.

Separate the deployment arrangement from the capabilities it provides. The questions below concern connectivity, data placement, identity lifecycle, policy, observability, and the skills needed to operate the chosen environments.

Distinguish deployment arrangements from integration capabilities

Hybrid cloud has a specific meaning in NIST SP 800-145: distinct cloud infrastructures remain separate entities but are connected by technology enabling data and application portability. That definition is more specific than the common use of hybrid for any combination of a datacenter and public cloud.

Read the conditions rather than the label. There are two or more cloud infrastructures; they remain distinct; and what binds them provides portability of data and applications. Note the first condition carefully: the definition asks for distinct cloud infrastructures, not for one of each deployment model — and a conventional datacenter is not automatically a cloud infrastructure, since private cloud in the same document means capacity “provisioned for exclusive use by a single organization” with the essential characteristics of cloud computing, self-service among them.

So an estate with a rack of hand-provisioned virtual machines, a cloud account, and a link between them may satisfy neither the first condition nor the third. That is a connected estate — a perfectly reasonable thing to run — and calling it hybrid borrows a capability nobody built. Industry usage is looser than this, which is fine as long as the looser sense is not used to claim portability in a decision.

Multicloud describes using multiple public cloud providers. NIST does not name it as a separate deployment model. Provider count alone does not establish architecture, portability, or resilience; two multicloud estates can have different dependencies and capabilities.

The distinction that actually predicts difficulty is a different one, and it cuts across both words.

	Deliberate	Accumulated
How it arose	A stated requirement or evaluated benefit: residency, a system that cannot move, a provider capability, an acquisition	Independent team choices, retained experiments, or a vendor’s infrastructure
What exists	A stated boundary, a chosen integration point, someone who owns both sides	Several partial platforms, each with its own identity and monitoring
What to measure	Budgeted integration and operations, plus remaining uncertainty	Integration, incident work, and duplicated operations that may not yet have a shared budget
What to do about it	Operate it, and keep the boundary narrow	Decide: consolidate, or make it deliberate. Leaving it undecided is the expensive option

Establish why each environment exists and whether that reason remains valid. An accumulated estate can be brought under deliberate ownership; a deliberate design still needs evidence that its benefits justify its operating cost.

The boundary has physics

Whatever the arrangement, there is now a link between environments, and three properties of it constrain the design more than any product choice does.

Latency has a floor. A sequence of eight dependent round trips accumulates their propagation delays; eight concurrent calls do not necessarily pay eight RTTs on the critical path. Measure processing, queueing, and transfer as well. The fundamentals of throughput and latency explain those components, while a latency guardrail records the workload’s acceptance threshold.

Egress is charged, and asymmetrically. Moving data out of a provider generally costs more than moving it in, so an architecture that reads across the boundary repeatedly has a recurring bill that grows with success — see data transfer cost for the structure. The design response is to move computation to the data rather than data to the computation, which is the whole content of the next point.

Data has gravity. Data gravity describes the tendency for workloads to run near large datasets when transfer time, cost, and access latency make remote processing unattractive. It does not determine placement by itself: available services, security requirements, output size, and operating cost can favor another location.

Use asynchronous exchanges where the response and consistency contract permits delayed completion. Batching can reduce sequential round trips, but adds time waiting to fill a batch and can enlarge payloads and retry units. Compare critical-path latency, concurrency, deadlines, and partial-failure handling before choosing either technique.

Where the reason for the second environment is legal rather than technical, note that none of this settles it: data residency is a constraint about where data may sit, and it is satisfied by a specific region and service rather than by an arrangement of clouds.

Consistency is the real bill

Google Cloud’s architecture guidance identifies recurring challenges in management, security consistency, integration, performance, and reliability. Treat them as operating responsibilities with explicit owners and evidence.

• Identity. Define the authoritative lifecycle source for each identity population, its authentication provider, and how accounts and groups are provisioned and removed. Federation can coexist with several directories: an AD source may synchronize users to Cloud Identity while retaining authentication authority. Test joiner, mover, and leaver handling, effective access, and session or credential revocation rather than treating directory count or SSO alone as proof of control.
• Policy. The same rule — where resources may be created, what must be encrypted, what may not be public — has to be expressed twice, in two mechanisms that do not inherit the same way. Keep the list of non-negotiable rules short precisely because each one costs two implementations, and write the rule in prose once so the two implementations can be compared against it.
• Observability. Arrange cross-environment correlation before incidents: shared identifiers, compatible timestamps and fields, access rules, and an agreed investigation path. Google recommends centralized visibility but also documents separating sensitive application data from operational data. A common view need not mean every record has one storage destination; retention, location, access, and outage requirements determine the collection design.
• Skills. Assign people who can diagnose and recover each environment, with escalation and coverage for cross-environment incidents. Identify gaps and the cost of closing them before relying on the second platform.

Because all four are recurring, they belong in total cost of ownership rather than in a migration budget. The comparison that matters is not the price of two platforms against one; it is the cost of operating two well against the constraint that made the second one necessary.

Standardize interfaces and operating contracts where they reduce repeated work. A common deployment workflow, versioned policy source, and correlated observability can use provider-specific implementations and separate runtime instances. Evaluate any abstraction against the behavior it preserves and its maintenance cost; neither a shared interface nor a single central service is automatically the right operating design.

When a second environment improves availability, and when it does not

A second environment can help with an identified failure scenario when it supplies a working recovery path. Different providers or locations do not by themselves remove shared identity, routing, state, or operational dependencies.

Test the intended loss scenario against a recovery time objective (RTO) and a recovery point objective (RPO). The recovery environment needs suitable data, usable capacity, credentials, and routing within those objectives. Automatic switching still needs tests; a rehearsed manual procedure may suffice for a longer RTO. Check write ownership, replay, and reconciliation so recovery does not introduce conflicting or lost updates.

Three patterns make availability worse rather than better, and all three are common.

• A shared control plane. Map what each shared component is needed for: deployment, scaling, instance startup, or every request. Losing the deployment service may leave existing workloads and independent local recovery mechanisms operating while blocking new releases. A secret fetched at startup affects new instances; a per-request lookup can affect active traffic. DNS record management and authoritative DNS responses are different paths, and caches or TTLs affect when failures become visible. Test the actual dependencies and preserve usable state or independent recovery paths where required.
• A request path that needs both sides. If serving a user requires a call to each environment, the path can only be as available as its worse half, and if the two fail independently it is the product of the two — 99% and 99% giving about 98%. The multiplication needs that independence: two environments whose outages coincide give roughly 99% again, which is why the honest general statement is no better than the weaker side, with the product as the independent case. Either way, splitting a synchronous path across a boundary reduces uptime while appearing to add redundancy.
• A failover that has never run. Untested failover is a belief, not a capability, and it fails in specific ways: stale data, capacity that was never reserved in the standby, a certificate or credential that expired there, a runbook naming people who left. Rehearsing it is the only way to know, and the rehearsal is what most programs skip.

Evaluate multi-zone and multi-region options within one provider against the failure scenarios before adding another provider. Neither placement automatically supplies replication, spare capacity, or working failover; responsibilities vary by service. A provider-wide event, concentration risk, or a regulatory requirement may justify a separate provider. Express the user-facing target as an SLO and verify the recovery design against it.

Cloud capacity can also absorb demand peaks through cloud bursting. This shares some readiness work with failover but has a different success condition: overflow workers may depend on a healthy primary database or load balancer. They can handle excess demand without surviving loss of that primary environment. Test burst response time and failure recovery separately.

What it does and does not do about lock-in

A second provider can improve commercial options when it supplies a viable alternative and the organization can use it. Accounts or a small deployment alone do not establish negotiating leverage for the workloads that matter; assess migration effort, commitments, and operating capability.

It does not make workloads portable. A service built against one provider’s managed database, identity model, and messaging still has to be rebuilt to run elsewhere, and having an account with the other provider changes none of that. Being in two clouds and being able to move between them are separate properties, and the second is the expensive one.

So the useful form of a portability position is an estimate rather than an arrangement: what would it actually take to move this workload — foundation redesign, data transfer, dual running, retraining — stated as an exit cost per significant system. A team that can name that number for its three most important systems has more genuine optionality than one that has accounts everywhere.

One narrow exception is worth allowing: where the concern is not portability but concentration — a single provider account being suspended, or one commercial relationship carrying the whole business — the second environment is the answer, and the requirement is that it works without the first, which is a demanding and testable property.

Design conditions, in the order they bind

If a second environment is going to exist, these conditions decide whether it is operable. They are ordered by how hard each is to change later.

1. Name the reason. Identify the requirement or expected benefit and its owner. If it is no longer valid, compare consolidation and transition costs with the cost of retaining the environment.
2. Choose data placement per dataset. Compare processing location, transfer and replication, service capabilities, security, latency, and operating cost. Record the assumptions that would change the choice.
3. Describe each crossing. State payloads, consistency requirements, deadlines, and failure behavior. Use asynchronous or batched exchanges when their semantics and measured costs meet the workload’s needs.
4. Assign identity lifecycle authority. Distinguish the source of identities, authentication, synchronization, permissions, and revocation. Test access removal and the authentication paths needed during recovery.
5. Design correlation and evidence retention. Define identifiers, timing, queries, alerts, and access across environments. Choose storage destinations by sensitivity and operational requirements, including local buffering and alerts during collection outages.
6. Write the non-negotiable rules once in prose, then implement them per platform and test that both implementations enforce the same thing.
7. Assign ownership of the boundary itself. Its network, its identity federation, its data movement — otherwise it belongs to whoever is on call when it breaks.

Apply those conditions to the reason each environment exists. Deliberate hybrid estates are normal and often permanent — plenty of systems will not move, and a connected datacenter is a reasonable long-term position rather than an unfinished migration. Multicloud as a default posture brings recurring work to maintain consistency across providers. Organizations that operate it well can explain why that additional work is justified by their requirements.

Where it is accumulated rather than chosen, the recoverable move is to stop the growth first — one place where new workloads go by default — and then decide about what exists, workload by workload, using the same isolation reasoning that would apply inside a single provider.

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, Cloud bursting pattern
• Google Cloud, Identity reference architectures
• Google Cloud, Hybrid and multicloud monitoring and logging patterns
• AWS, Static stability
• AWS, Edge network global service guidance