What Is Multicloud

What is multicloud?

Multicloud is the use of services from more than one public cloud provider. An organisation might run application workloads in one cloud, analytics in another, identity or collaboration services in a third, and object storage or disaster recovery somewhere else. The clouds do not need to be tightly integrated for the environment to be multicloud, but the organisation does need to manage them as part of one technology estate.

Multicloud is different from hybrid cloud. Hybrid cloud combines public cloud with private infrastructure. Multicloud focuses on multiple public cloud providers. A company can be multicloud, hybrid cloud, both, or neither depending on how its workloads are placed.

The important question is not whether more than one provider is present. Many organisations become multicloud accidentally through team choice, acquisitions, SaaS adoption, analytics projects, or regional requirements. The practical question is whether the organisation has the governance, security, networking, and operational visibility to manage that spread.

Why teams adopt multiple clouds

Capability is a common driver. One provider may have a preferred data platform, another may offer better regional coverage, and another may fit a specific application stack. Teams may choose the best service for each workload rather than forcing every problem into one platform.

Resilience is another reason. Some organisations want critical services to survive a provider outage or regional failure. This can be valuable, but only if the architecture is designed and tested for failover. Simply having accounts in multiple clouds does not make an application resilient.

Negotiating leverage and vendor risk also matter. Depending entirely on one provider can create commercial, technical, and operational lock-in. Multicloud can reduce that risk, but it may introduce new complexity and cost. The tradeoff should be explicit.

Regulation and geography can influence decisions. Data residency, sovereignty expectations, customer contracts, and local performance requirements may lead teams to use different providers in different markets.

Common multicloud patterns

One pattern is workload placement by strength. A team might use one cloud for customer-facing applications and another for analytics or machine learning. The environments are connected through data pipelines, APIs, and identity controls rather than full application portability.

Another pattern is active-passive resilience. A primary cloud handles normal production traffic while another provider holds backups, replicated data, or standby infrastructure. This can reduce outage risk, but it requires regular restore and failover tests.

An active-active design runs production across multiple providers at the same time. This is much harder. Teams must solve traffic routing, data consistency, session handling, observability, security policy, and incident ownership across providers. It is usually reserved for high-criticality services with strong engineering maturity.

A fourth pattern is decentralised adoption. Different business units use different clouds. This may be acceptable if central governance provides identity, security baselines, inventory, cost controls, and incident visibility.

Governance and ownership

Multicloud needs clear standards. Each provider has its own names, services, permissions, network model, logging system, and billing structure. Without shared policies, teams end up with inconsistent controls and blind spots.

Central governance should define minimum requirements for identity, administrator access, logging, encryption, network exposure, tagging, backup, vulnerability management, and incident response. These requirements should be implemented through templates, policy-as-code, and normal engineering workflows where possible.

Ownership must be visible. Every cloud account, project, subscription, workload, storage bucket, API, and public endpoint should have a business owner and technical owner. Unknown assets are a security and cost problem.

Governance should not mean forcing every team to use identical services. The value of multicloud is workload fit. The goal is consistent control evidence and operating discipline, not identical architecture everywhere.

Security implications

Identity is the hardest part for many multicloud environments. Each provider has its own identity and access model. Teams should use strong federation, least privilege, multi-factor authentication, controlled break-glass access, and regular permission review. Long-lived keys and unmanaged service accounts are frequent sources of compromise.

Network exposure should be reviewed across all providers. Public storage, management ports, permissive firewall rules, and shadow APIs can appear in any cloud. External attack surface management and route-level monitoring become more important as the estate spreads.

Data movement also needs control. Analytics, replication, backups, and application integration can move sensitive records between providers. Teams should know which copy is authoritative, which copies are temporary, how data is encrypted, where it is stored, and when it is deleted.

Security monitoring should be normalised enough for incident responders to use. Logs do not need to look identical, but responders need to correlate identity events, network changes, application traffic, storage access, and security findings across providers.

Operational and cost challenges

Multicloud can increase the skills burden. Engineers and security teams must understand multiple consoles, APIs, failure modes, and pricing models. This can slow incident response if knowledge is concentrated in a few people.

Tooling can become fragmented. Separate deployment systems, monitoring dashboards, vulnerability scanners, and ticketing workflows make it harder to answer basic questions: what changed, who owns it, what is exposed, and whether controls are working.

Cost can be difficult to compare. Providers price compute, storage, support, data egress, managed services, and discounts differently. Moving data between clouds can be especially expensive. A workload that seems cheaper in one provider may cost more once network transfer, operations, and duplicate tooling are included.

Availability planning can also be misunderstood. A multicloud design may still depend on one identity provider, DNS service, CI/CD system, database, or third-party API. Those shared dependencies can become single points of failure.

Misconceptions

Multicloud does not automatically prevent vendor lock-in. If each workload relies heavily on provider-specific services, the organisation may have several lock-ins instead of one. That may be acceptable when the benefit is clear, but it should be acknowledged.

Multicloud does not automatically improve security. It can reduce some concentration risk, but it also expands the number of configurations, identities, logs, and data paths that must be managed. Security improves only when controls are consistent and visible.

Multicloud also does not require every application to be portable across providers. Full portability can be expensive and may prevent teams from using valuable managed services. A more practical goal is often exit planning: know what would be difficult to move, why, and what mitigation exists.

Evaluating a multicloud strategy

A good multicloud strategy starts with reasons. For each provider, define the workloads, business driver, required controls, owner, data classification, and expected lifecycle. Remove accidental or unused environments where the reason no longer exists.

Review the shared control plane: identity, inventory, logging, policy, secrets, networking, incident response, backup, and cost management. Then test operational scenarios. Can teams revoke a compromised credential across providers? Can they find every public endpoint? Can they restore a critical dataset? Can they route around a regional outage? Can they explain a cost spike?

Multicloud is valuable when it gives the organisation better capability, resilience, or flexibility than a single-provider model at an acceptable complexity cost. It becomes risky when provider diversity is mistaken for governance. The mature version is not more clouds for its own sake; it is deliberate workload placement with consistent security and operational evidence.