Eighty-seven percent of enterprises are running workloads across more than one cloud provider. Fewer than a third can tell you whether that decision is delivering better outcomes than a single-provider approach would. That is not a cloud problem. It is a strategy problem.
Cloud & Infrastructure · Business Infomatics Research Desk
Multi-cloud became the default enterprise posture through a combination of deliberate choice and organisational drift. Some of it was intentional — risk diversification, avoiding vendor lock-in, workload placement that matched specific cloud provider strengths in AI, or geographic requirements that a single provider couldn't meet. Some of it happened because different business units made independent procurement decisions, because acquisitions brought inherited cloud environments, or because a software vendor required a specific platform. The result, in most large organisations, is a cloud estate that looks less like an architecture and more like an accumulation.
The gap between the theoretical benefits of multi-cloud and the operational experience of running it is wide — and it is widening as the number of cloud-native services, governance requirements, and cost management obligations compounds with each additional provider. Gartner's 2025 infrastructure survey found that enterprises running three or more cloud providers reported average management complexity scores 4.8 times higher than single-cloud organisations. Their per-workload cloud costs were 34 percent higher. Their mean time to detect security incidents was longer. And their engineering teams spent a disproportionate share of their time on cloud plumbing rather than product development.
87% of enterprises use multiple clouds. Only 31% manage it as a coherent strategy. Source: Gartner Infrastructure Survey, 2025.
87% of enterprises are multi-cloud. Only 31% describe it as a managed strategy rather than accumulated complexity. (Gartner, 2025)
Why Multi-Cloud Became the Default — And Why That Doesn't Make It Right
The arguments for multi-cloud have always had genuine merit. No single cloud provider offers the best-in-class service across every category. AWS dominates in breadth of services and maturity of its platform. Google Cloud leads in AI and machine learning infrastructure. Azure is the natural choice for organisations deeply embedded in the Microsoft ecosystem. For organisations with specific workload requirements, matching the workload to the provider that handles it best is a legitimate architectural decision.
The vendor lock-in argument is also real, at the price and performance negotiation level. Organisations that have demonstrated credible willingness to move workloads between providers have extracted better commercial terms than those who negotiated from a position of complete dependency. The leverage is real, but it requires maintaining genuine optionality — which means investing in portability that most organisations do not actually maintain at the workload level.
What is less often acknowledged in multi-cloud strategy discussions is the cost of maintaining genuine portability. It requires architecture discipline that conflicts with the natural tendency to use platform-native services — the managed databases, the serverless compute, the AI pipelines — that are the primary source of cloud productivity advantages. Every platform-native service that a workload depends on is a portability constraint. The organisations that have genuinely maintained workload portability across providers have typically done so by avoiding the native services that make each platform valuable, which largely defeats the purpose of using those platforms.
Multi-cloud budget: where spend was planned vs. where it actually lands. Networking egress, management tooling, and security overhead consistently exceed projections. Source: Flexera State of the Cloud 2025.
The Operational Costs That Don't Appear in Cloud Vendor Proposals
Egress Fees Are the Hidden Tax on Multi-Cloud
Cloud providers charge for data transferred out of their networks — egress fees that are modest per gigabyte but add up quickly at enterprise data volumes and have no equivalent in on-premises environments. In a single-cloud architecture, data movement is largely within the provider's network and attracts minimal charges. In a multi-cloud architecture where workloads on different providers need to communicate — or where data needs to be centralised from multiple clouds for analytics — egress becomes a material cost that was not in the original business case.
AWS, Google Cloud, and Azure all announced some reduction in egress fees in 2024 under regulatory and competitive pressure, but the fees remain significant at scale. Enterprises running active multi-cloud workloads with inter-cloud data flows regularly report egress costs running at 15 to 25 percent of their total cloud bill — a figure that rarely appeared in the TCO analysis that justified the architecture.
Management Tooling Multiplies With Provider Count
Every cloud provider has its own identity and access management system, its own cost management interface, its own monitoring and observability toolchain, its own security configuration framework. Managing these separately across three providers does not cost three times as much as managing one — the complexity compounds non-linearly because the integration points between systems multiply with each addition. The cross-cloud visibility tools that attempt to abstract this complexity — Datadog, CloudHealth, Apptio Cloudability — add their own cost and their own integration requirements.
Operational complexity and management cost scale non-linearly with cloud provider count. Three providers introduces nearly 5× the complexity of one. Source: Business Infomatics analysis, Gartner data 2025.
4.8× higher management complexity for enterprises running 3+ cloud providers vs. single-cloud. Accompanied by 34% higher per-workload cost. (Gartner, 2025)
Security Posture Is Harder to Maintain Across Provider Boundaries
A coherent security posture requires consistent policy enforcement across every environment where workloads run. In a single cloud, this is achievable — there is one policy framework, one identity system, one network perimeter model to configure and maintain. In a multi-cloud environment, the security configuration effort multiplies with the number of providers, and the attack surface grows because the interfaces between cloud environments create additional exposure points that each individual provider's security model was not designed to protect.
The organisations with the most mature multi-cloud security postures invest in cloud-agnostic security platforms — CASBs, cloud security posture management tools, centralised SIEM — that sit above individual provider security frameworks and enforce consistent policy across all of them. This investment is substantial and ongoing, and it does not eliminate the underlying complexity — it manages it at additional cost.
What a Coherent Multi-Cloud Strategy Actually Requires
Cloud governance maturity model: four levels from reactive accumulation to optimised strategic placement. Most enterprises are at Level 1 or 2. Source: Business Infomatics framework.
Workload Placement as a Deliberate Architectural Decision
The starting point for multi-cloud strategy that actually works is a deliberate workload placement framework — a set of criteria that determines which provider is the right home for each workload, based on technical requirements, cost profile, regulatory constraints, and strategic considerations. This framework should be documented, enforced through architecture review processes, and revisited as provider capabilities and pricing evolve.
Effective workload placement criteria typically include: regulatory and data residency requirements that mandate specific geographies or certifications; workload-specific requirements that map to a provider's differentiated services — a machine learning pipeline that depends on Google's TPU infrastructure, a .NET application that integrates deeply with Azure Active Directory; cost optimisation for specific workload types where one provider's pricing model is materially more favourable; and continuity requirements where active-active cross-cloud redundancy is genuinely necessary rather than theoretically desirable.
FinOps Needs a Multi-Cloud Practice, Not a Multi-Cloud Dashboard
Cloud cost management in a single-cloud environment is achievable with the provider's native tooling, supplemented by a FinOps practice that owns commitment management, tagging discipline, and cost allocation. In a multi-cloud environment, the same practice needs to operate across multiple provider billing models, multiple commitment mechanisms — reserved instances, savings plans, committed use discounts — and multiple cost reporting formats that do not map directly to each other.
The organisations managing multi-cloud cost effectively have built FinOps as an organisational capability, not just a tooling investment. They have a dedicated practice with ownership over multi-cloud cost visibility, and they have embedded cost accountability into engineering teams with the granularity to attribute cost to the product areas that generate it. The tooling — third-party platforms that aggregate multi-cloud spend — supports this practice but does not replace it.
The Platform Engineering Response
The most effective long-term response to multi-cloud complexity is building an internal platform that abstracts cloud provider specifics from development teams — providing standardised infrastructure primitives, deployment pipelines, observability, and security controls that work consistently regardless of which cloud provider a workload runs on. This is the platform engineering model that leading technology organisations have adopted, and it is what enables them to manage multi-cloud complexity without that complexity consuming the engineering capacity that should be building product.
Platform engineering is a substantial investment that pays back over years, not quarters. It requires dedicated engineering team capacity, strong technical leadership, and organisational commitment to building internal tooling as a product. For organisations not ready to make that investment, a more pragmatic approach is consolidating to two cloud providers with genuinely differentiated workload placement logic — not three or four accumulated over time — and building consistent governance across those two before expanding further. The governance maturity required to manage three clouds well is genuinely different from what most organisations have built.
