multi cloud stands as the the strategy the consulting firm sold the board in 2019 and the operations team has been trying to make work since. The pitch was vendor lock in avoidance, the cost optimisation, the resilience. The reality. the the second cloud account nobody can fully account for, the second identity system nobody wants to manage, the second deployment pipeline nobody maintains, the second bill nobody fully understands. The honest framing matters here, because the multi cloud strategy the executive team approved in 2019 is what the strategy the operations team has to make work in 2026, whether the operations team agrees with the strategy or not.
What follows runs as the working version of the honest guide. The shorter version is what the cloud architect actually has time to read.
Why the multi cloud pitch was wrong
Three reasons, in roughly that order of how much each one hurt the operations team. The first runs as the lock in myth, where the pitch said multi cloud would avoid the vendor lock in, the lock in that the operations team actually faces , the the lock in to the abstraction (the Terraform, the Kubernetes, the Prometheus), the lock in that multi cloud does not solve because the abstraction sits the same regardless of which cloud runs the workload. The second runs as the cost myth, where the pitch said multi cloud would optimise the cost, the cost that the enterprise actually faces is essentially the the cost of the duplicate skills (the AWS engineer plus the Azure engineer), the duplicate tooling (the two monitoring stacks, the two deployment pipelines), the duplicate overhead, the cost that multi cloud multiplies rather than optimises. The third runs as the resilience myth, where the pitch said multi cloud would provide the resilience, the resilience the enterprise actually gets from the multi cloud deployment is, in practice, the the resilience of the workload that runs in both clouds with the cross cloud replication, the resilience that the operations team rarely implements because the cost of the cross cloud replication exceeds the cost of the outage it would prevent.
Why the multi cloud is happening anyway
Three reasons, in roughly that order of how much each one drove the strategy. The first runs as the acquisition, where the enterprise acquired the company that already ran on the other cloud, the multi cloud that the operations team did not choose, the multi cloud that the operations team inherited, the multi cloud that the M&A team delivered. The second runs as the SaaS sprawl, where the enterprise uses the SaaS product that runs on the other cloud, the SaaS that the line of business bought without asking the operations team, the multi cloud that the procurement team did not know was a multi cloud decision. The third runs as the AI workload, where the enterprise uses the AI service that only runs on the other cloud, the AI capability that the competitor has and the board wants, the multi cloud that the strategy the operations team cannot refuse.
How to make it work if you have to
Three moves if you are the cloud architect that has to make the multi cloud work without breaking the operations team. Pick the primary, because the multi cloud that runs as primary plus secondary serves as the multi cloud the operations team can manage, the multi cloud that runs as primary plus secondary plus tertiary serves as the multi cloud the operations team will fail at, the primary that the operations team invests in serves as the primary that gets the deep expertise. Abstract the workload, not the cloud, because the workload that runs in containers on Kubernetes serves as the workload that can move between clouds when the business case demands, the abstraction the operations team invests in serves as the abstraction the cloud bill can be optimised against, the abstraction the cloud vendor sells serves as the abstraction the vendor will use to lock you back in. Consolidate the identity, because the identity that runs across both clouds (the Azure AD plus the AWS IAM, the Okta plus the Cloud IAM) serves as the identity the operations team can manage, the identity that runs separately in each cloud serves as the identity the attacker will exploit through the forgotten account, the consolidated identity that the operations team enforces serves as the identity that survives the next acquisition. The cloud architect that picks the primary, abstracts the workload, and consolidates the identity serves as the architect that makes the multi cloud work without burning the operations team out.
The bottom line
multi cloud in 2026 runs as the real the strategy the operations team has been handed rather than the strategy the operations team would have chosen. The pitch was wrong on the lock in, the cost, the resilience. The reality runs as the first the M&A, the SaaS, the AI workload. The cloud architect that picks the primary, abstracts the workload, and consolidates the identity serves as the architect that makes the multi cloud work without breaking the team. The one that tries to do the multi cloud right serves as the architect that runs the operations team 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.
