The Strategy That Was Mostly Theater
In 2023, a Fortune 500 retailer announced an aggressive multi-cloud strategy at the board level. In 2025, internal audit found that 96 percent of production workloads ran on a single cloud, with the second cloud holding mostly development environments and a small set of disaster recovery instances. The multi-cloud strategy was theater. The actual posture was single-cloud.
Flexera's 2024 State of the Cloud report found 89 percent of enterprises claim multi-cloud strategy. Honest analysis of actual workload distribution suggests roughly 30 percent run meaningful multi-cloud workloads (Flexera, "2024 State of the Cloud Report"). The gap is the gap between strategy slides and engineering reality.
Multi-cloud is not always wrong. Multi-cloud is often wrong. The question worth answering is what drives it for your specific use case, not whether the strategy sounds sophisticated in a board deck.
Coined Frame: The Three Honest Drivers
Three drivers genuinely justify multi-cloud architecture. Everything else is theater or post-hoc rationalization.
Driver 1 - Specific capability not available on primary cloud. Some capabilities differ meaningfully across cloud vendors. Specific AI/ML services, specific industry-vertical compliance certifications, specific geographic coverage. If you need a capability only one vendor offers, you use that vendor for that workload regardless of primary cloud choice.
Driver 2 - Regulatory or sovereignty requirement. Some jurisdictions require data residency in specific clouds, in specific regions, with specific operators. EU sovereignty initiatives, China-specific deployments, and certain government workloads all create genuine multi-cloud requirements.
Driver 3 - Acquisition or business reality. Two companies merged. They run different clouds. Migration to one cloud would cost more than running both. Maintaining both is the honest answer.
What does not justify multi-cloud: avoiding vendor lock-in (the cost of multi-cloud exceeds the cost of single-cloud lock-in for most enterprises), negotiating leverage (real but small relative to the operational cost), and architectural elegance (multi-cloud is operationally less elegant than single-cloud).
The honest application of these three drivers usually results in narrower multi-cloud than the strategy slides suggest. A primary cloud serving 80-95 percent of workloads, plus specific secondary cloud usage for the cases the drivers actually require.
What Multi-Cloud Actually Costs
Three cost categories make multi-cloud expensive.
Operational complexity. Two cloud platforms means two sets of services to learn, two security models, two identity systems, two networking patterns, two monitoring stacks. The headcount cost is real and recurring. Enterprises running meaningful multi-cloud typically need 30-50 percent more cloud engineering capacity than equivalent single-cloud enterprises.
Tooling fragmentation. Most cloud-native tooling is optimized for a single cloud. Multi-cloud tooling exists but is generally less mature. The teams running multi-cloud either accept fragmented tooling or invest heavily in abstraction layers, both of which have ongoing costs.
Network egress. Moving data between clouds incurs egress charges from both providers. For workloads that span clouds with frequent data movement, the egress alone can dominate the cost calculation.
These costs are predictable for teams that go in with eyes open. The teams that adopt multi-cloud strategy without pricing these costs are usually the teams that quietly converge back to single-cloud over time.
The Patterns That Actually Work
Three multi-cloud patterns produce defensible value in practice.
Pattern A - Workload-specific multi-cloud. Primary cloud runs most workloads. Specific workloads run on a different cloud for capability or compliance reasons. The two clouds operate as separate environments with limited data exchange. This is the most common successful pattern.
Pattern B - Geographic multi-cloud. Different geographic regions use different clouds based on regulatory requirements or local provider strength. Each region operates relatively independently. Common for enterprises with significant operations in China, Europe, and the US.
Pattern C - Disaster recovery multi-cloud. Primary cloud runs production. Secondary cloud holds disaster recovery capability with periodic data replication. The DR cloud is not actively used at full scale but provides resilience against primary cloud failures. This pattern has cost overhead but provides genuine business continuity value for some workloads.
Patterns that look like multi-cloud but are actually theater: marketing claims that workloads can run anywhere when in practice they run in one place, abstraction layers that pretend to enable multi-cloud but cannot be tested because they were never used, multi-cloud strategies that exist to satisfy board diligence questions.
The Tools That Help
Genuine multi-cloud architectures benefit from specific tooling.
Kubernetes as a workload abstraction. Containerized workloads can run on any cloud's managed Kubernetes service with minor configuration changes. The portability is real for cloud-native workloads, less real for workloads with cloud-specific dependencies.
Terraform or equivalent for infrastructure as code. Cross-cloud infrastructure management is meaningfully easier with provider-agnostic IaC tools than with cloud-native tools.
Cross-cloud observability platforms. Datadog, New Relic, Dynatrace, Grafana Cloud. Single pane of glass for workloads spanning clouds simplifies operations meaningfully.
Cross-cloud identity. Federated identity through Okta, Azure AD, or equivalent that works across cloud providers. The alternative is per-cloud identity management which becomes unwieldy fast.
These tools do not make multi-cloud cheap; they make it operationally manageable.
What Logiciel Does Here
Logiciel works with engineering leadership on honest multi-cloud assessment: which workloads genuinely benefit, which workloads should consolidate, and what operational pattern fits the actual driver set.
The Cost-Performance Cloud Architecture framework covers the cost-side analysis. The Cloud Migration Patterns framework covers the migration considerations when multi-cloud is the right answer.
A 30-minute working session is enough to assess your current multi-cloud posture honestly against the three drivers.
Frequently Asked Questions
Should I adopt multi-cloud to avoid vendor lock-in?
Usually no. The operational cost of multi-cloud exceeds the benefit of reduced lock-in for most enterprises. Lock-in is real but the cost of mitigating it through multi-cloud is typically higher than the cost of accepting it.
How do I evaluate whether a multi-cloud strategy is theater or real?
Look at actual workload distribution. If less than 20 percent of production workloads run on the secondary cloud, the strategy is mostly theater. Real multi-cloud has meaningful workload distribution across the participating clouds.
Which cloud should be my primary?
Whichever fits your workload profile, ecosystem familiarity, and pricing structure best. The major three (AWS, Azure, GCP) are all credible primary clouds. The choice depends on specifics more than on general comparison.
How does AI affect multi-cloud strategy?
AI capability differences between major clouds are real and growing. Specific AI services (Vertex AI, Bedrock, Azure AI Foundry) have different feature sets. Some workloads will naturally pull toward the cloud with the best AI fit, which can create multi-cloud where the primary cloud lacks AI capability.
Is hybrid cloud the same as multi-cloud?
No. Hybrid cloud is a specific pattern combining on-premises with public cloud. Multi-cloud is using multiple public clouds. The distinction matters because the drivers and patterns differ. Many enterprises use both patterns simultaneously. Sources: - Flexera, "2024 State of the Cloud Report" - Gartner, "Multi-Cloud Strategy Research," 2024
