The Pitch and the Reality
The multi-cloud pitch is compelling. Avoid vendor lock-in. Leverage best-of-breed services from different providers. Negotiate from a position of commercial strength. Achieve resilience through cloud provider diversity. Each of these arguments has merit. Together they form a narrative that is used to justify multi-cloud investments across the enterprise technology market.
The operational reality of multi-cloud is different in important ways. Not different enough to invalidate multi-cloud as a strategy, but different enough that organisations that adopt multi-cloud based on the vendor pitch without understanding the operational reality will pay significantly more and achieve significantly less than they expected.
The distinction between strategic multi-cloud (using different cloud providers for different use cases based on best-fit capability) and operational multi-cloud (running the same workload across multiple cloud providers simultaneously) is crucial. The former is common, manageable, and often appropriate. The latter is rare among enterprises outside the largest and most cloud-mature organisations, and for good reason.
What Multi-Cloud Actually Costs to Operate
The cloud providers do not advertise the operational overhead of multi-cloud because it is not their interest to do so. But the cost categories are identifiable and, with experience from enterprise deployments, quantifiable.
Skills multiplication is the most immediate operational cost. Each cloud platform has its own service catalogue, its own networking model, its own identity and access management system, its own billing model, its own operational tooling, and its own support processes. Running two cloud platforms requires a team with expertise in both; running three requires expertise in three. The depth of expertise required to operate each platform effectively is not achievable by distributing existing skills across more platforms. Multi-cloud demands more total cloud expertise than single-cloud, not the same expertise deployed differently.
The talent market compounds this. Cloud engineers are expensive across all the major platforms. Cloud engineers who are expert in two platforms are scarcer and more expensive than engineers expert in one. The multi-cloud skills premium in the talent market is real and increasing.
Integration complexity between cloud environments is the second major cost category. Data that needs to move between cloud environments incurs egress costs from the originating cloud. Networking between cloud environments requires either cross-cloud VPN or private connectivity. Security posture management across two or three cloud control planes requires tools and processes that do not exist in single-cloud environments. The integration layer that makes multi-cloud environments coherent is an infrastructure investment that single-cloud environments do not require.
Tool fragmentation follows skills multiplication. Each cloud platform has native operational tooling that works within that platform and requires adaptation to work across platforms. The monitoring solution that provides excellent insight into AWS workloads provides limited insight into Azure workloads and vice versa. The infrastructure-as-code tooling that works well with one provider’s abstractions requires significant additional work to manage across provider boundaries. The multi-cloud tooling market exists to solve this problem, but the tools add their own cost and their own operational overhead.
Management overhead is the aggregation of the above. Two vendor relationships instead of one. Two billing models, two support channels, two security audit processes, two compliance validation programmes. The management overhead scales roughly linearly with the number of cloud providers rather than with the volume of workloads on each provider, which means that the overhead is disproportionately high for small workloads on a secondary cloud provider.
When Multi-Cloud Is Actually the Right Answer
Given the operational overhead, the conditions under which multi-cloud is genuinely the right strategy are more specific than the vendor pitch suggests.
Regulatory or data sovereignty requirements that mandate specific data residency in jurisdictions where the primary cloud provider does not have qualifying regions can require use of a secondary provider with qualifying infrastructure. This is a genuine multi-cloud requirement driven by external constraint rather than strategic preference.
Specific capability requirements that are only available from a particular cloud provider justify running those workloads on that provider even when the primary estate is elsewhere. An organisation whose primary cloud is Azure but whose data science team requires specific GPU instance types that are only available on AWS or GCP is making a rational best-of-breed decision for that workload, not a strategic multi-cloud commitment.
Commercial risk management for very large cloud consumers can justify multi-cloud as a negotiating strategy, but only at a scale of cloud commitment where the commercial leverage it creates exceeds the operational overhead it imposes. This threshold is higher than most organisations reach.
Acquisition integration is a frequent de facto multi-cloud driver: the acquired company’s cloud estate is on a different provider than the acquirer’s. Managing this transition requires either migration cost to consolidate or ongoing multi-cloud operational overhead. The decision should be made explicitly rather than by default.
The Architecture Decision That Most Organisations Make Incorrectly
The architectural mistake that most multi-cloud strategies make is designing for portability rather than for capability. The portability-first design uses only the lowest common denominator of cloud services that works across multiple providers, avoiding provider-specific services that would create lock-in. This approach limits the organisation to services that are available in functionally equivalent form from multiple providers, which is a significant constraint on the available service catalogue.
The consequence of portability-first design is that the organisation is paying cloud prices for services that could have been run on cheaper infrastructure, and is not using the cloud-native services that provide the most value in cloud-native application design. The lock-in that portability-first design avoids is theoretical: most organisations do not migrate cloud providers on a timescale short enough for portability to provide practical benefit. The capability limitation that portability-first design imposes is concrete and immediate.
The alternative is capability-first design: choose the cloud provider whose native services best support each workload type, use those native services fully, and manage the resulting provider dependency through commercial negotiation and contractual terms rather than through architectural portability. The commercial negotiation approach to managing provider dependency is more effective at the workload volumes most enterprises operate than the architectural portability approach.
The Honest Board-Level Assessment
The board question about cloud strategy is not “should we be multi-cloud?” It is “what is our cloud provider strategy and what are we optimising for?” The answers to that question are different for different organisations and different for different workload categories within the same organisation.
The organisation that has made explicit, documented choices about which workloads run on which providers, why, and what the operating model is for each combination, is in a better position than the organisation that is multi-cloud by accumulation without a deliberate strategy. The strategy may conclude that a primary-secondary model, or a workload-type-specific model, or even a single-provider model, is the right answer. What matters is that the answer is deliberate, and that the operating model matches the complexity of the chosen strategy.
The vendor who tells you multi-cloud is easy is selling something. The practitioner who has operated multi-cloud at scale will tell you exactly where the complexity lives and what it costs.