Hybrid Cloud

In NIST SP 800-145, hybrid cloud combines distinct cloud infrastructures that remain separate entities while technology enables data and application portability between them. Common industry usage also includes connected datacenter and public-cloud estates; state which meaning applies instead of inferring capabilities from the label.

Three conditions, and the one people skip

Taking the definition apart gives a test rather than a label.

• Distinct cloud infrastructures. Each must satisfy the cloud characteristics in the definition. Two regions or two providers alone do not establish this condition or portability. A conventional virtualized datacenter is not automatically a private cloud.
• They remain unique entities. Nothing is merged; each keeps its own management. This is why “hybrid” is not a migration half-finished.
• Technology enabling data and application portability. Identify what can move and under which conditions. A network connection alone does not establish that capability.

An organization with a datacenter, a cloud account, and a private circuit between them may satisfy the second condition and neither of the others. Whether it satisfies the third depends on something nobody buys by installing a link: can a workload actually run on either side, and can its data be there when it does? If not, what exists is a connected estate — perfectly reasonable, and not the capability the word implies.

The distinction matters because the word gets used to justify decisions. We’re hybrid, so we can move this if the provider disappoints us is a claim about portability, and the definition is explicit that portability is what the binding has to provide. If it was never built, the sentence is false in a way that only becomes visible under pressure.

Private cloud is not a synonym for on-premises

Two terminology traps come from the same paragraph of the standard, and both cause confused conversations.

A private cloud serves a single organization and can be on or off premises. Location and exclusivity alone are insufficient: the infrastructure also needs the essential cloud characteristics, including on-demand self-service, network access, resource pooling, elasticity, and measured service.

A public cloud is open for use by the general public and operates on the provider’s premises in the NIST definition. Public describes its consumer population; it does not mean customer data is publicly accessible.

NIST also defines community cloud for a specific community of organizations with shared concerns. Evaluate a sector-specific deployment against those conditions rather than assigning the label solely from its customer category.

Why organizations end up here

Common reasons for connected or hybrid estates have different review triggers; none should be treated as permanent or temporary solely from its category.

• A system cannot currently move. Hardware, licensing, support, or factory equipment may constrain placement. Revisit when the constraint or available alternatives change.
• A rule requires it. Residency or sovereignty obligations that a given provider region cannot satisfy. Check the obligation against specific regions and services rather than treating it as a general prohibition — data residency is narrower than it is usually asserted to be.
• Assets already exist. A datacenter with years left on its lease, hardware recently bought. A cost argument with a date attached, which is worth revisiting on that date rather than never.
• A migration is in progress. Define completion criteria and review the remaining work. Migration, lease, regulatory, and product constraints can all change over time.

Record the reason, its review trigger, and the capabilities needed while the arrangement remains. An expected end date does not remove the need to operate it safely today.

Operate both environments while they are needed

The practical mistake is treating a hybrid estate as temporary and therefore not worth investing in — which produces an environment with one identity system, one monitoring stack, and one patching process, plus a second environment that has none of them and is nobody’s job.

Give the cross-environment network, identity lifecycle, and data movement named owners. Select asynchronous or batched crossings only where deadlines and consistency allow them. Maintain comparable control outcomes and correlated observability, while allowing separate storage and tools where sensitivity, location, or resilience requires them.

Cloud bursting is NIST’s example of portability between infrastructures, but it is not proof of disaster recovery. Extra workers can use a healthy primary system and fail when that system is lost. Rehearse demand spikes and loss of the primary as separate scenarios. Their readiness work and costs are examined in Two Clouds, Twice the Operations.

References:

• NIST SP 800-145, The NIST Definition of Cloud Computing
• Google Cloud, Cloud bursting pattern
• Google Cloud, Hybrid and multicloud monitoring and logging patterns