Multi-cloud is not a second vendor checkbox. It is a second control framework that has to stand up under identity, recovery, networking, and cost pressure.
Outline
Why “just add AWS” is usually an operating-model mistake, not a tooling decision.
Where Azure mental models map cleanly to AWS and where they do not.
The control gaps that appear first: identity, account vending, root-account posture, networking, and FinOps.
A comparison matrix operators can actually use in planning conversations.
A phased path to evaluate AWS without creating cleanup work you will regret.
The real problem with spite migrations
A lot of multi-cloud talk starts from emotion. A board wants negotiating power. A leader wants an exit story. A team is frustrated with a vendor relationship. Someone says the safest answer is to add a second hyperscaler so the organization is “not locked in.”
That logic sounds strategic. In practice, it often skips the hard part. Multi-cloud is not just a second destination for workloads. It is a second operating model, a second control surface, a second set of failure modes, and a second vocabulary for identity, network design, policy, and cost ownership.
If you already run Azure well, AWS is not automatically chaos. But it is not “another subscription” either. The teams that get burned are usually the ones that copy Azure assumptions into AWS, then discover six months later that access assignment, account ownership, recovery, and billing views work differently enough to create drag.
Where Azure instincts transfer cleanly, and where they do not
Some comparisons are straightforward. An AWS account is the closest equivalent to an Azure subscription. AWS Organizations gives you a governance hierarchy that feels directionally similar to Azure Management Groups. VPC peering and Transit Gateway can cover many of the network patterns Azure teams know from VNet peering and hub-spoke designs.
The trouble starts when a familiar word hides a different operating boundary. Azure Resource Groups are lifecycle containers for a solution. AWS Resource Groups exist, but they are tag and query driven collections inside a region. They are helpful, but they do not replace the design role Azure Resource Groups often play in deployment, ownership, and cleanup.
That difference matters because operators need to know where lifecycle control really lives. In Azure, many teams lean on subscription plus resource-group structure. In AWS, the blast radius usually shifts toward account boundaries, OU design, tags, and the way Control Tower or account vending is handled.