Multi-Cloud Architecture
Multi-cloud architecture uses services from more than one public cloud provider. It assigns workloads and shared controls to providers while accounting for cross-cloud networking, identity, data, operations, cost, and failure.
itCloud computing | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: Multi-Cloud Architecture
Multi-cloud architecture means using more than one public cloud provider, which sounds like acquiring several kitchens because one saucepan was busy. It is really a placement strategy. A second provider earns its keep only when it supplies something the first one cannot: regional presence, a differentiated capability, an inherited platform, or a genuinely independent workload.
The first useful distinction is between three shapes. Portfolio placement keeps separate workloads on separate providers. Partitioned application puts parts of one application on different providers. Redundant deployment runs equivalent copies in more than one place. They look related on a diagram. Their operational bills arrive in quite different envelopes.
The surprise is that the provider list is not the difficult part. The difficult part is the boundary, any cross-provider dependency such as a request, identity check, DNS lookup, or data copy. Every boundary needs an owner and a planned response when it fails. A private connection is still not a substitute for routes, DNS, encryption, firewalls, or a decision about what happens after the connection has developed opinions.
Data is where architectural optimism becomes accounting. Name the system of record, the authoritative source for each data set. Then state where copies may live, how stale they may be, who can write, and how conflicts are handled. A replica with no authority rule is not an extra safety net. It is an argument that has not happened yet.
Portability helps selectively. Common packaging and versioned infrastructure definitions can make delivery repeatable. They do not make provider identities, managed services, quotas, network behavior, or diagnostic tools identical. Standardize the parts whose benefit exceeds their maintenance cost, then keep enough native detail to find the real problem during an incident.
Read the Course tab for the topology choices and shared foundations. Use the Cheatsheet when drawing a boundary or planning a failure drill. The Practice tab turns the placement record into a reviewable design, and Field Notes covers the costs that tend to hide behind the phrase "common control plane." The quiz is there to check that no diagram has quietly persuaded you that two providers are resilience by themselves.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.nist.gov/publications/nist-cloud-computing-reference-architecture-0
Supports
- The NIST Cloud Computing Reference Architecture provides a vendor-neutral taxonomy for cloud actors, service models, and management responsibilities
- A cloud architecture can separate provider, consumer, broker, auditor, and carrier responsibilities
- https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/manage/hybrid/server/best-practices/vmware-ubuntu-template
Supports
- Multi-cloud means using multiple cloud providers concurrently
- A multi-cloud strategy should align business drivers, vision, principles, metrics, and technology choices
- Common operations across environments require consistent practices and centralized visibility
- https://docs.cloud.google.com/architecture/hybrid-multicloud-patterns/drivers
Supports
- Multi-cloud architecture is a means to meet business and technical objectives rather than a goal by itself
- Placement considerations include data sovereignty, cost, provider capability, lock-in, reliability, management complexity, security, performance, and skills
- Cross-provider resilience requires assessment of data movement, capability parity, security, manageability, and team skills
- https://docs.cloud.google.com/architecture/hybrid-multicloud-patterns-and-practices?hl=en
Supports
- Architecture patterns define components, their functions, and their communication
- Distributed patterns place workloads or components in suitable environments
- Redundant patterns deploy equivalent workloads in multiple environments for capacity, resilience, development, or testing
- https://docs.cloud.google.com/architecture/hybrid-multicloud-secure-networking-patterns/design-considerations
Supports
- Cross-environment network performance includes bandwidth, latency, packet loss, and jitter
- Connectivity decisions should assess performance, security, cost, reliability, and scalability
- Multi-cloud networking needs integrated DNS and a unified security posture with visibility across environments
- https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-multicloud/introduction.html
Supports
- Legitimate reasons for and against multi-cloud require balancing business value with complexity and risk
- Multi-cloud strategy includes business alignment, governance, workload boundaries, integration, security, and team structure
- https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-multicloud/tenet-4.html
Supports
- Splitting contiguous workloads across providers adds data movement, synchronization, consistency, security, and operating complexity
- Messaging, loose coupling, bulk transfer, and operational independence can reduce cross-provider impact
- https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-multicloud/tenet-5.html
Supports
- Workload placement should consider technical requirements, business needs, and provider strengths
- Applications benefit from placement near primary data
- Data ownership, classification, transfer method, latency, cost, and operational effects belong in placement decisions
- https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-multicloud/tenet-8.html
Supports
- Multi-cloud security spans identity, data, network, endpoint, asset, and audit concerns
- A unified security operations and observability model should retain provider-native controls
- https://cloud.google.com/blog/topics/hybrid-cloud/how-to-do-multicloud-right-according-to-experts
Supports
- Practitioner guidance recommends defining the business value of multi-cloud before adopting it
- Portability across providers has material workload and data movement costs
- Multi-region experiments and chaos engineering expose constraints before a cross-provider design
- https://www.hashicorp.com/products/terraform
Supports
- Terraform provides infrastructure lifecycle workflows across cloud, private datacenter, and SaaS infrastructure
- https://azure.microsoft.com/products/azure-arc/
Supports
- Azure Arc extends Azure management, governance, and security services to resources outside Azure
- https://cloud.google.com/anthos
Supports
- Google Cloud Anthos provides a Kubernetes-oriented platform for hybrid and multi-cloud environments
- https://www.flexera.com/
Supports
- Flexera One provides visibility and governance capabilities across cloud and related technology estates
- https://www.cloudbolt.io/
Supports
- CloudBolt provides hybrid and multi-cloud management, governance, and optimization capabilities