Multi-cloud consulting
A second provider is often added for a single workload and then treated as if it shared identity, networking and cost allocation with the first. This engagement maps the actual trust, data and operational seams.
Who this engagement is for
Platform and SRE teams that already have production traffic on two or more of AWS, Azure, Google Cloud and Alibaba Cloud, or that must keep a second provider for residency or commercial reasons.
Information required to begin
- Which providers are in production versus evaluation
- Which identities and networks already cross providers
- Data residency and sovereignty constraints
- Who owns incidents when a dependency spans both clouds
Engineering process
- Consultation to separate active multi-cloud from aspirational diagrams
- Identity, network and data-path review per provider
- Written operating-model notes: who changes what, and how failover is tested
Deliverables
- Current-state assessment of the multi-cloud seams
- Target architecture for identity and network trust
- Risk register for split-brain operations and data gravity
Provider-specific scope
- AWS IAM Identity Center and workload roles
- Microsoft Entra ID and Azure RBAC
- Google Cloud Workforce and Workload Identity Federation
- Alibaba Cloud RAM and Resource Directory where used
Limitations
- We do not recommend multi-cloud as a default. Many teams should stay on one provider and document why.
- Active-active across providers is out of scope unless you already have a tested data plane.
What is not included
- Vendor negotiation or marketplace procurement
- Building a custom multi-cloud control plane product
Author
Written by Ankit Mehta. Methods used in this engagement are documented in the related guides below.