What the adoption numbers hide, what actually goes wrong, and what it takes to build a multi-cloud architecture that holds up under pressure.
Flexera’s 2024 State of the Cloud report puts multi-cloud adoption at 93% of enterprises. That number has become a fixture in vendor decks and analyst briefings, usually deployed as evidence that the decision is already made and the only question is execution speed.
The number deserves more scrutiny than it usually gets.
Most surveys define multi-cloud loosely. An organization running AWS for production workloads and Microsoft 365 for email qualifies. That is categorically different from an enterprise with intentional workload distribution, unified identity federation across providers, consistent security posture, and real-time FinOps instrumentation across AWS, Azure, and GCP. Both count in the 93%.
The 7% who have not moved are not necessarily behind. Many of them have watched the early movers absorb integration debt, unexpected egress costs, and compliance gaps. They are choosing to get the foundation right before distributing complexity. That is not a failure of ambition. It is architectural discipline.
This article is written for technology leaders who are past the question of whether to adopt multi-cloud, and ready to engage with the harder questions of how to do it well.
What Has Actually Changed in Multi-Cloud Since 2023
Two developments have materially shifted the multi-cloud conversation in the last 18 months. Both have implications that generic adoption guides have not caught up with.
1. The VMware Shock Created Real Migration Urgency
Broadcom’s acquisition of VMware and the subsequent licensing restructuring forced thousands of enterprises to re-examine their on-premises hypervisor dependencies. For organizations that relied on VMware for private cloud workloads, the question became operationally urgent: which hyperscaler do we consolidate on, and should we use this moment to distribute workloads across multiple providers rather than recreate single-vendor concentration in the public cloud?
This has been one of the most significant catalysts for genuine multi-cloud adoption in years, driven by cost pressure rather than strategic ambition.
2. GPU Availability Is Now a Workload Placement Variable
The AI infrastructure buildout has introduced a constraint that did not exist in the 2021 multi-cloud playbook. NVIDIA H100 and A100 availability varies by provider and region, and that variation now influences architecture decisions. Organizations with training workloads have found that running inference on a different platform than training is not an edge case. It is sometimes the only viable option.
Practitioner Note
Model portability between providers is not free. PyTorch models generally transfer across environments, but provider-optimized inference runtimes (TensorRT on AWS, ONNX Runtime variants, Azure AI inference) are not interchangeable. Build re-optimization time into your architecture roadmap when planning cross-provider inference.
The Real Challenges: What Actually Goes Wrong
Standard multi-cloud challenge lists cover complexity, cost, security, and integration. Those are accurate but abstract. Here is what organizations actually run into.
1. Identity Federation Is the Hardest Unsolved Problem
Consistent identity across AWS IAM, Azure Entra ID, and GCP IAM is the foundation everything else depends on. OIDC and SAML federation work, but they require deliberate architecture and sustained maintenance discipline. Most organizations end up with identity sprawl: separate service accounts, inconsistent role naming, divergent permission boundaries on each platform.
The risk extends beyond operational overhead. Identity sprawl creates privilege escalation paths that are invisible to any single platform’s security tooling. AWS Security Hub will not surface a lateral movement risk that originates in a misconfigured Azure service principal.
2. Egress Costs Are a Hidden Tax That Compounds at Scale
Data egress pricing remains one of the most underestimated costs in multi-cloud architecture. AWS charges up to $0.09 per GB for outbound data transfer. GCP charges up to $0.08 per GB. Azure is structured similarly. At scale, moving data between platforms for ML training pipelines or federated analytics generates egress costs that routinely offset the savings that drove the workload distribution decision in the first place.
The answer is not to avoid multi-cloud. It is to design data gravity into the architecture from the start. Keep data and compute co-located unless there is a specific, quantified reason to move it.
3. FinOps Maturity Is a Prerequisite, Not an Outcome
Multi-cloud does not reduce cloud costs by default. It introduces more variables and more ways to spend money unintentionally. Organizations that adopt multi-cloud without FinOps tooling already in place consistently report higher spend in their first 12 months than projected.
Mature FinOps in a multi-cloud context requires unified cost allocation tagging enforced at provisioning, chargeback or showback reporting by business unit, anomaly detection at the account and project level, and commitment optimization (reserved instances, savings plans) that accounts for cross-provider positioning. Stitching together CloudHealth, Apptio Cloudability, and native tools like AWS Cost Explorer is non-trivial work.
4. Kubernetes Sprawl Is Real and Expensive to Manage
Kubernetes has become the default abstraction layer for multi-cloud workloads. But multi-cluster management introduces its own overhead: separate control planes, divergent upgrade cycles, inconsistent network policies, and the operational burden of running EKS, AKS, and GKE with different CNI plugins, ingress controllers, and storage classes.
Tools like Anthos, Azure Arc, and AWS EKS Anywhere partially address this, but none are genuinely provider-neutral. Each is a bet on one vendor’s management plane. Multi-cluster Kubernetes management is an area where the tooling has not fully caught up with the architectural aspiration.
5. AI Data Fragmentation Is the New Technical Debt
A feature store on GCP, a data warehouse on Snowflake backed by Azure, and a training dataset in S3 is not an unusual architecture in 2026. It creates compounding problems: pipeline complexity, data consistency gaps, lineage tracking across systems, and governance blind spots that become regulatory exposure for financial services and healthcare organizations.
This is the challenge the 7% are most justified in taking time to address properly. Data architecture decisions made today will constrain AI strategy for years. Getting that foundation right before distributing across clouds is the right call.
A Framework for Evaluating Multi-Cloud Readiness
If your organization is assessing whether and how to move forward, these are the questions that matter more than whether you are in the 93% or the 7%.
| Evaluation Area | What to Assess |
|---|---|
| Identity architecture | Can you federate identity across providers from day one, or will you be retrofitting IAM policy after workloads are already running? |
| Data gravity mapping | Where does your data live today, and which workloads need to stay co-located with it to avoid egress costs? |
| AI infrastructure needs | Do your ML workloads require GPU availability that a single provider cannot guarantee consistently? |
| Egress cost modeling | Have you modeled data transfer costs across your planned architecture at projected production scale? |
| FinOps readiness | Do you have unified cost visibility today, or will multi-cloud billing multiply existing blind spots? |
| Compliance scope | Have you mapped regulatory obligations (HIPAA, PCI-DSS, SOC 2, regional data residency) to each provider’s compliance coverage? |
Where AI Is Accelerating Multi-Cloud Specifically
The claim that AI is driving multi-cloud adoption needs to be unpacked. Here are the specific mechanisms that are actually changing architecture decisions.
- Foundation model API dependencies are creating new concentration risk. Organizations building on OpenAI via Azure, Anthropic via AWS Bedrock, or Google Gemini via Vertex are discovering that model-level lock-in can be harder to escape than infrastructure lock-in. Deliberate multi-provider AI architecture is becoming a risk management strategy.
- Inference cost arbitrage is becoming material at scale. As inference volumes grow, the per-token cost differential between providers running equivalent model architectures is meaningful. High-volume workloads are being routed dynamically based on cost and latency, treating AI endpoints the way CDNs treat content delivery.
- AI governance requirements are diverging by jurisdiction. The EU AI Act, US federal AI policy, and sector-specific frameworks in financial services are creating compliance requirements that vary significantly by region. Multi-cloud architectures that enforce geographic boundaries on AI workloads and their associated data are moving from preference to requirement.
What Good Multi-Cloud Architecture Actually Looks Like
The standard checklist (Kubernetes, FinOps, API-first, containerization) is accurate but insufficient. The practices below separate well-executed multi-cloud from organizations that simply have more than one cloud bill.
1. Design for failure domains, not just redundancy
Resilience in a multi-cloud context is not about replicating everything across providers. It is about understanding your failure domains and ensuring that a single provider outage does not cascade into a business continuity event. That requires deliberate traffic management, tested health check architecture, and runbooks your team has rehearsed before an incident, not during one.
2. Treat security posture as a first-class workload
CSPM tools like Wiz, Orca, or Prisma Cloud are not optional at multi-cloud scale. They are the only way to maintain consistent policy visibility across provider-native security tooling. Organizations that skip CSPM at the start routinely discover their gaps through incidents rather than audits.
3. Define your control plane before you deploy workloads
Whether you standardize on Terraform for infrastructure-as-code, Crossplane for cloud-native control planes, or a platform engineering layer above Kubernetes, this decision needs to be made before you have 40 accounts across three providers. Retrofitting governance onto a sprawling multi-cloud environment costs significantly more than building it into the initial architecture.
4. Build an AI-ready data foundation before distributing compute
If AI is part of your multi-cloud rationale (and for most organizations it should be), invest in a unified data platform before distributing compute across providers. A consistent data lakehouse layer, whether Databricks running across multiple clouds or Snowflake with cross-cloud replication, dramatically reduces the AI data fragmentation problem and provides a governance foundation that regulators will increasingly require.
Ready to build multi-cloud that actually works?
Most organizations know their current cloud architecture has gaps. Few have a clear plan to close them before those gaps become incidents, cost overruns, or compliance findings.
9series offers two ways to start:
The conversation is free. The wrong architecture will not be
Final Thoughts
Multi-cloud is not a destination. It is an operating model that requires sustained investment in tooling, governance, and expertise. The 93% adoption number is real, but it masks enormous variation in how well those architectures are actually performing.
The organizations that will have a durable advantage are not the ones that adopted multi-cloud first. They are the ones that adopted it deliberately: with clear workload placement logic, a data strategy built for AI, and the operational discipline to manage complexity at scale.
If you are in the 7%, you may be closer to that outcome than you think. The question is whether you build that foundation on your own timeline, or on one forced by a compliance audit, a cost spike, or a production incident.
9series can help you move forward with clarity. Start with the free discovery call.
