4 MIN READ
Picture the slide deck the consulting firm delivered to the board in 2019. Two clouds, two providers, vendor lock in solved, cost optimised, resilience doubled. The pitch was confident. Six years later, the slide deck has not been updated, and the operations org has been quietly paying for the second cloud account, the second identity system, the second deployment pipeline, and the second bill nobody on the procurement side fully understands. The honest framing matters here, because the multi cloud strategy the executive team approved in 2019 amounts to the strategy the operations org has to make work in 2026, whether the operations org agrees with the strategy or not.
What follows sits as the working version of the honest guide. The shorter version sits as what the cloud architect actually has time to read.
Why the multi cloud pitch was wrong
The lock in myth sits at the top. The pitch said multi cloud would avoid vendor lock in. The lock in the operations org actually faces sits in the abstraction rather than the vendor. Terraform, Kubernetes, Prometheus, the open source stack that sits underneath both clouds, the stack that the operations org has standardised on. Moving workloads between AWS and Azure does not escape that lock in. The abstraction amounts to the lock in, and the vendor can change without changing the lock in at all.
The cost myth comes next. The pitch said multi cloud would optimise the bill. The cost the company actually faces amounts to the cost of duplicate skills (an AWS engineer and an Azure engineer who do not talk to each other), duplicate tooling (two monitoring stacks, two deployment pipelines, two backup strategies), and the management overhead of keeping the two environments from drifting apart. Multi cloud multiplies the cost rather than optimising it. The cloud bill analysis the CFO sees rarely shows the duplicate skills line because that line sits in payroll rather than the cloud bill.
The resilience myth rounds out the trio. The pitch said multi cloud would provide resilience through geographic and provider diversity. The resilience the operations org actually gets amounts to the resilience of the workload that runs in both clouds with cross cloud replication, the workload that the operations org rarely implements because the cost of the cross cloud replication exceeds the cost of the outage it would prevent. Most multi cloud deployments are not actually resilient. They are two single cloud deployments that happen to share a procurement contract.
Why the multi cloud is happening anyway
The acquisition sits as the first reason. The company bought the company that already ran on the other cloud, and the multi cloud the operations org did not choose sits as the multi cloud the operations org inherited. The M&A team delivered the multi cloud. The CFO signed the deal. The cloud architect woke up one Monday with two clouds to manage and a budget that had not grown to match.
SaaS sprawl comes second. The enterprise uses the SaaS product that runs on the other cloud, the SaaS that the line of business bought without asking the operations org, the multi cloud that the procurement lead did not know amounted to a multi cloud decision until the SOC 2 auditor asked for the asset inventory. The multi cloud is happening in the contract the operations org did not see, and the multi cloud is going to keep happening as long as the line of business can buy SaaS with a corporate card.
AI workloads round out the picture. The company uses the AI service that only runs on the other cloud, the AI capability the competitor has and the board wants, the multi cloud that the strategy the operations org cannot refuse. Bedrock lives in one place, Azure OpenAI lives in another, and the workload the data team needs for the demo next quarter lives wherever the model lives. The cloud architect who wants to say no to the AI workload sits as the cloud architect who is going to be overruled by the board, and the cloud architect who plans for the AI workload sits as the cloud architect who is going to be the one who actually has to make it work.
How to make it work if you have to
Pick the primary, because the multi cloud that runs as primary plus secondary sits as the multi cloud the operations org can manage, and the multi cloud that runs as primary plus secondary plus tertiary sits as the multi cloud the operations org will fail at. The primary the operations org invests in sits as the primary that gets the deep expertise, the runbooks, the on call rotation, the well named dashboards. Everything else counts as the secondary, the place the workload goes when the business case demands, the place that gets enough investment to stay running and not a dollar more.
Abstract the workload, not the cloud. The workload that runs in containers on Kubernetes sits as the workload that can move between clouds when the business case demands, and the abstraction the operations org invests in sits as the abstraction the cloud bill can be optimised against. The abstraction the cloud vendor sells (the managed Kubernetes service, the proprietary serverless platform) sits as the abstraction the vendor will use to lock the operations org back in. The Kubernetes that runs on both clouds counts as the Kubernetes that gives the operations org optionality. The proprietary serverless counts as the proprietary serverless that does not.
Consolidate the identity, because the identity that runs across both clouds sits as the identity the operations org can manage, and the identity that runs separately in each cloud sits as the identity the attacker will exploit through the forgotten account. The Azure AD plus the AWS IAM, the Okta plus the Cloud IAM, the consolidated identity the operations org enforces sits as the identity that survives the next acquisition. The cloud architect who picks the primary, abstracts the workload, and consolidates the identity sits as the architect who makes the multi cloud work without burning the operations org out.
The bottom line
Multi cloud in 2026 sits as the real strategy the operations org has been handed rather than the strategy the operations org would have chosen. The pitch was wrong on the lock in, the cost, and the resilience. The reality amounts to the first M&A deal, the SaaS the line of business bought, the AI workload the board demanded. The cloud architect who picks the primary, abstracts the workload, and consolidates the identity makes the multi cloud work without breaking the org. The one who tries to do the multi cloud right runs the operations org out the door.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
