Organizations generally favor one cloud, but a multicloud approach is a popular way to differentiate where workloads are run.
In this post, we dig deeper into the multicloud setup, the reasons for this approach, its benefits and risks, and how you can manage it optimally.
We will cover:
What is multicloud?
Multicloud is an approach where you run workloads across two or more cloud providers (for example, Microsoft Azure and Oracle Cloud, or AWS and Google Cloud). In most multicloud setups, workloads run in one cloud at a time instead of being split across providers by default, although some architectures span clouds when needed.
Teams adopt multicloud to choose the best-fit platform for each workload (capabilities, cost, performance, data residency, or existing tooling) and to reduce dependence on a single provider.
A multicloud setup can include public clouds, private clouds, or both. Hybrid cloud describes the integration of a public cloud with a private cloud or on-premises infrastructure. You can be hybrid without being multicloud (on-prem + one provider), and multicloud without being hybrid (two public clouds).
Companies choose multicloud for both technical and business reasons. We’ll cover them in the sections below.
Technical reasons for using a multicloud setup
From a technical standpoint, a multicloud approach is adopted mainly to fulfill the expectations described in the architectural Quality Attributes – QA (formerly known as Non-Functional Requirements – NFR).
First, we need to understand that the modern approach to designing applications creates modularity, which enables easier migrations between different cloud vendors.
1. Disaster recovery
This is one of the most common scenarios for a multicloud setup. This approach must be considered carefully. Every cloud vendor offers various tools and approaches to achieve a very robust disaster recovery. For example, AWS has an approach called Fault Tolerance, which involves using multiple regions to save data and operations.
Resilience
Every provider experiences outages. Some do not impact the business much, but some are very severe. Using a multicloud setup limits this danger, and can even remove it completely. Again the organization must be very aware of the costs of this approach, which extend beyond just doubled monthly bills.
2. Flexibility
The possibility to select services from different vendors allows architects and engineers to choose the best option. One of the most common examples is when an organization uses AWS as their main vendor, but they use BigQuery in Google Cloud to run analytics.
3. Avoid vendor lock-in
Vendor lock-in has been demonized for years. Depending on the service used, it might play an important role in your SDLC.
Vendor lock-in should be reviewed not just from the perspective of the workload. For example, if you use a serverless approach, the solution will be more tightly integrated with the vendor. If the workload is run on virtual machines or managed Kubernetes, vendor lock-in is limited.
However, vendor lock-in also relates to other elements of the system, like IaC. For example, if the team selects CloudFormation to manage infrastructure on AWS, it will be significantly harder to move some of the workload to Azure.
Business reasons to build multicloud
1. Agility
As your organization and your infrastructure scale, you need to be prepared for change. A multicloud approach enables this flexibility, giving you the freedom to consider solutions from multiple vendors to meet your specific, often fluid requirements.
2. Compliance
Organizations need to follow security and monitoring rules. This is especially important in regulated industries. Although cloud vendors hold all security certificates, both for physical and It security, there might be reasons to select one vendor over another.
For example, one vendor may have better operational support for databases, but another could provide more suitable monitoring systems.
3. Costs
This is probably the most popular reason to differentiate between vendors and use a multicloud approach. Organizations compare the offerings from different vendors and select the cheapest. However, this approach might be misleading.
The cost of the service may be lower, but the burden of maintaining two vendors may raise the bill significantly because you are doubling the code base or hiring more engineers to maintain all vendors.
Are hybrid cloud and multicloud the same thing?
Generally, yes: hybrid cloud and multicloud can overlap, but they’re not the same thing.
Multicloud is about how many providers you use: running workloads across two or more cloud providers (most often public clouds, but it can include private cloud platforms too). Hybrid cloud is about what environments you integrate: connecting a public cloud with a private cloud and/or on-prem infrastructure.
That means:
- Public cloud: Infrastructure operated by a third-party provider (AWS, Azure, Google Cloud, etc.). Compute is typically delivered via multi-tenant shared infrastructure, with isolation at the virtualization and control-plane level. Many providers also offer dedicated/isolated options (for compliance or performance), but they tend to cost more.
- Private cloud / on-prem: Cloud-like infrastructure run for a single organization, usually in its own data center or dedicated facilities (and sometimes hosted by a third party but still single-tenant). It can help with regulatory, data residency, or legacy constraints, but it often trades off elasticity and operational simplicity, since the organization owns more of the operations and skills burden.
With those definitions, hybrid can be a form of multicloud — but only if it involves more than one provider. For example:
- Hybrid but not multicloud: on-prem + AWS (one cloud provider).
- Multicloud but not hybrid: AWS + Azure (two public clouds, no private/on-prem integration).
- Hybrid and multicloud: on-prem/private cloud + AWS + Azure (public + private/on-prem, and multiple providers).
So, while hybrid often looks “multicloud-ish”, it’s only multicloud when the setup includes two or more providers running workloads.
Practical multicloud operating models
Multicloud works best when you choose an operating model intentionally and apply it consistently.
- Primary cloud plus selective secondary – Run most workloads in one primary cloud. Use a second cloud only when it delivers clear value, such as a specific managed service, regional coverage, or vendor constraints.
- Workload partitioning by domain – Split workloads by domain or responsibility, such as customer-facing apps in one cloud and your internal data platform in another. This reduces duplication and is easier to govern than putting everything everywhere.
- Resilience-first multicloud (only when justified) – Utilize multicloud for disaster recovery (DR) or failover only when the business requires it and you’re prepared to operate it end-to-end, including regular testing, runbooks, identity, networking, and data replication. Active-active across clouds is rarely worth the complexity unless your organization is built for it.
- The anti-pattern: Multicloud because you can – If you can’t name the driver for each workload, resilience, regulation, capability, or commercial leverage, multicloud becomes permanent overhead.
Is multicloud a good choice for you?
It is important to emphasize that any decision made regarding the cloud setup is significant and will have a big impact on your business.
In the table below, lists aspects to consider when deciding whether or not to adopt a multicloud approach:
| Area | Advantages | Disadvantages |
| Costs | You may use a cheaper equivalent service, negotiate pricing, or avoid some exit/lock-in costs. | Cost comparisons can be misleading once you include other costs, like network traffic between clouds (In general, all outgoing traffic from your cloud network is paid), potential license cost, and wider skills needed in your teams. |
| Flexibility | A multicloud approach gives you more flexibility when selecting tools. Cloud offerings are similar in general, but some vendors offer much better solutions than others. | It is virtually impossible to find disadvantages for flexibility. The only one might be that you have to follow more vendors to be up-to-date with their solutions and changes. |
| Resiliency | This might be the biggest advantage of multicloud solutions. Scalability, fault tolerance, disaster recovery — all these aspects can be leveraged. | The risk for resiliency lies in the additional layers needed, like network connectivity between two clouds. This is another variable in the whole setup that needs to be controlled. |
| Vendor lock-in | Use of multicloud enforces another approach to specific solutions, like serverless, for example. Every cloud has a different syntax and structure, and serverless services work slightly differently. This forces organizations to plan their adoption optimally to avoid vendor lock-in. | Avoiding vendor lock-in may mean sacrificing the benefits of specific services. |
| Security | Decomposing workload and services between different versions may be seen as increasing compliance and cloud governance. This decomposition allows you to encapsulate different functions in different areas. For example, a workload from Google Cloud can be monitored by tools run on AWS. | Multicloud gives more attack surfaces and increases security costs. Security is also more complex. |
| Skills | Teams broaden expertise and reduce single-platform dependency. | Multicloud requires more skills, which may require a bigger team or limit the proficiency of team members in specific tools. |
| Infrastructure control | You can limit the impact of a bad change to a single provider/environment and standardize workflows. | You’re managing more providers and often more tools: Terraform/OpenTofu, plus cloud-native IaC like CloudFormation and Bicep, plus policy and security layers. |
How can Spacelift help you manage a multicloud setup?
Spacelift is cloud-agnostic, so you can connect your cloud accounts of choice from the platform. It provides native cloud integrations for AWS, Azure, and Google Cloud (GCP), plus a generic OIDC option for other providers. Let’s take a look at features that can help you manage a multicloud setup.
As your infrastructure scales, you are likely to consider solutions offered by other vendors to address your changing needs. Spacelift gives you the flexibility to support not just today’s workloads, but also future challenges that may arise with different stacks, vendors, and technologies.
Multi-IaC approach
Tools like OpenTofu and Terraform allow you to manage your infrastructure without having to use any other tool, but different teams will often favor different tools, so you could end up with multiple IaC solutions in use at any one time. This diversity of tools becomes more likely when you adopt a more complex multicloud setup.
Spacelift prepares you for this, allowing users to define their workloads using multiple tools and wrappers — Terraform, Terragrunt, OpenTofu, AWS CloudFormation, Pulumi, Ansible, and Kubernetes. This flexibility enables you to manage all your infrastructure in one place.
Connections using short-lived credentials
Using short-lived credentials is one of the most secure ways to connect between two services. These types of credentials are issued when requested by an authenticated service and removed shortly after. Spacelift’s cloud integrations are designed to avoid long-lived static credentials by dynamically generating short-lived access tokens. To provide more configuration options, AWS, Azure, and Google Cloud can be configured with OIDC.
The image below shows the configuration for AWS. You can define the Spaces to which the integration is connected, the IAM Role, and the duration of the credential’s life.
Spaces
Spaces allow organizations to organize resources and enforce role-based access control (RBAC). Your multicloud setup can be reflected with all environments and technical accounts, as in the example below:
Using Spaces gives your organization full control over what can be deployed in a specific space or group of Spaces, who can access them, and what the access level is.
Blueprints
The bigger your setup, the bigger your infrastructure, and the more important Blueprints may be to you. With Blueprints, you can enable platform teams to provide self-service infrastructure — the benefits of which are described in the linked article.
Blueprints allow you to use multicloud capabilities without extensive training for everyone. The key element here is that you have one place where your infrastructure is collected, maintained, and controlled in terms of quality and security.
Stacks
To use an analogy from Kubernetes, Stacks are the smallest deployable units in Spacelift. You can organize stacks under Spaces, and use dependencies between them to create a chain of execution. With stacks, you have a 1:1 relation between your infrastructure and code.
Stack dependencies
Spacelift supports Stack dependencies v.2, which lets you chain your stacks to create a comprehensive process of managing infrastructure and pass data across stacks using output references. This significantly speeds up the infrastructure provisioning process and ensures that data between stacks will be valid and proper.
Policies
With Policies, you can control the behavior of executions and access management. This video shows the implementation of security tools in the stack’s execution, but also how powerful policies can be.
The image below presents enforced policies during the stack execution.
Drift detection (and optional reconciliation)
Multicloud increases drift risk (more consoles, more humans, more “quick fixes”). Drift detection helps you continuously verify that reality matches code, and optionally reconcile safely when drift is found.
Visualization
More resources to run and more vendors to manage often mean a more obscure picture of what we actually own in our organization. To ensure this awareness, we need proper visibility of the infrastructure.
Spacelift offers two tools that can help you better understand the current state of your infrastructure. One is stack dependencies, which I described before. The second is the Resources functionality.
Resources allow you to see and organize all deployed resources. You can organize them by type, stacks, and more.
Key takeaways
Multicloud has many flavors — two public clouds, hybrid (on-prem + cloud), or a selective “best service per workload” approach. The strategy can unlock resilience and flexibility, but it can also multiply complexity if you don’t standardize your operating model.
If you adopt multicloud, treat networking, identity, and governance as first-class architecture, right alongside your application design.
Spacelift is here to help you in this journey. With a wide range of functionality and compatibility with multiple clouds and IaC tools, Spacelift is ready to support you and your business to properly create and maintain your multicloud setup.
Does this sound like something your company should be doing? Book a demo with our engineering team to discuss your options in more detail.
Automation and collaboration layer for Infrastructure as Code
Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation and controls to simplify and accelerate the provisioning of cloud based infrastructures.
