What is multi-cloud?

Using two providers in a lab, or one provider plus Microsoft 365, is not this problem. The architectural event is a second production identity plane and a second production invoice.

What does not merge

Tenancy is documented differently on each platform. An AWS organization has one management account you cannot swap. Azure management groups sit under one Microsoft Entra tenant and can hold subscriptions. Google Cloud’s organization is the root of folders and projects. Alibaba Cloud allows one Resource Directory per eligible management account. There is no API that turns those four trees into one.

Identity evaluation is also native. AWS IAM authenticates a principal and then authorizes against identity policies, resource policies, and organization policies. Azure RBAC assigns a role definition to a security principal at a management group, subscription, resource group, or resource. Google Cloud attaches allow policies to resources in the hierarchy and evaluates inherited bindings plus optional deny policies. Alibaba Cloud uses RAM inside an account and Resource Directory access control policies as a permission ceiling. A group in Entra ID is not an AWS IAM role and is not a Google Cloud principal until you build federation.

Networks do not share a CIDR namespace by default. An Amazon VPC is regional. An Azure virtual network is regional. A Google Cloud VPC is a global resource with regional subnets. Alibaba Cloud VPCs are regional, with vSwitches in zones. Cross-cloud traffic is VPN, Interconnect or ExpressRoute, or the public internet. Each hop has its own routing and its own egress price list.

Billing is equally separate. Consolidated billing inside AWS Organizations does not include Azure. An Azure billing account does not see Google Cloud SKUs. Engineering recommendation: keep a cost-allocation model per provider first, then build a roll-up. Do not wait for a single native invoice.

Prove you have two control planes

Pick one human who should be able to read production in two clouds. On AWS:

aws sts get-caller-identity
aws iam list-attached-role-policies --role-name <role-name>

Account in get-caller-identity is the AWS account you actually hold credentials for. Attached policies are that account’s IAM, not Azure.

On Azure:

az account show --query "{tenantId:tenantId,id:id,name:name}" -o jsonc
az role assignment list --assignee <user-or-object-id> --all \
  --query "[].{role:roleDefinitionName,scope:scope}" -o table

tenantId is the Entra tenant. Scope tells you whether the assignment is tenant-wide or one subscription.

On Google Cloud:

gcloud config get-value project
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --filter="bindings.members:user:NAME@DOMAIN"

If the same person needs a third mapping in Alibaba Cloud RAM, that is a third join. Console path: RAM > Identities > Users.

Interpret the three outputs as three answers to “who is this person.” If you cannot name the identity store for each, you do not have a multi-cloud identity design. You have leftover admin accounts.

Risks and limitations

Multi-cloud as an availability strategy usually fails on DNS, identity, and data gravity, not on VM count. Providers document regional failure domains inside one cloud. They do not document a joint RTO across clouds.

Duplicated landing zones double the guardrail work. AWS SCPs, Azure Policy, Google Cloud organization policies, and Alibaba Cloud access control policies are four languages. A control you wrote in one does not apply in the others.

Network “mesh” diagrams hide packet paths. Private connectivity still terminates on a gateway you own, and encryption, MTU, and failover are your problem. Shared responsibility still applies per provider; see each vendor’s model.

If the reason for a second cloud is a specific APAC region, a regulated data boundary, or an acquisition, say that. Those are design constraints. “Avoid lock-in” is not a topology.

The identity work is the first place multi-cloud becomes real. See Designing multi-cloud identity.