Multi-Cloud Strategy Cheat Sheet
Key architectural patterns, tooling, and tradeoffs for running workloads across AWS, Azure, and GCP simultaneously.
2 PagesAdvancedFeb 8, 2026
Terraform Multi-Provider Config
Provision resources on two clouds from one Terraform config.
yaml
# providers.tfprovider "aws" { region = "us-east-1"}provider "google" { project = "my-gcp-project" region = "us-central1"}resource "aws_s3_bucket" "backup" { bucket = "my-cross-cloud-backup"}resource "google_storage_bucket" "primary" { name = "my-primary-bucket" location = "US"}
Common Drivers for Multi-Cloud
Key common drivers for multi-cloud to know.
- Avoiding Vendor Lock-in- Preserve leverage in pricing negotiations and reduce single-provider risk
- Best-of-Breed Services- Use each provider's strongest offering (e.g. BigQuery for analytics, Azure AD for identity)
- Regulatory/Data Residency- Some jurisdictions or contracts require specific providers or regions
- Mergers & Acquisitions- Combined companies often inherit workloads on different clouds
- Disaster Recovery- A secondary provider protects against a full outage of the primary
Abstraction & Tooling
Key abstraction & tooling to know.
- Terraform- Single IaC tool with providers for AWS, Azure, GCP, and hundreds more
- Kubernetes- Common workload abstraction layer portable across EKS, AKS, GKE
- Crossplane- Kubernetes-native control plane for provisioning multi-cloud infrastructure
- Service Mesh (Istio/Linkerd)- Consistent networking, security, and observability across clusters/clouds
- Identity Federation- SSO/SAML/OIDC to unify authentication across providers
Pitfalls to Avoid
Key pitfalls to avoid to know.
- Least-Common-Denominator Design- Avoiding all provider-specific features can sacrifice reliability and cost benefits
- Data Gravity- Large datasets are expensive/slow to move; plan data placement carefully
- Duplicated Operational Overhead- Each provider needs its own monitoring, IAM, and cost management setup
- Cross-Cloud Egress Cost- Data transfer between clouds is often billed at premium rates
Crossplane Composite Resource Across Clouds
Define a single abstract API that provisions equivalent resources on either AWS or GCP.
yaml
apiVersion: apiextensions.crossplane.io/v1kind: Compositionmetadata: name: managed-database.aws labels: provider: awsspec: compositeTypeRef: apiVersion: platform.example.org/v1alpha1 kind: XDatabase resources: - name: rdsinstance base: apiVersion: rds.aws.upbound.io/v1beta1 kind: Instance spec: forProvider: engine: postgres instanceClass: db.t3.medium region: us-east-1 patches: - fromFieldPath: spec.parameters.storageGB toFieldPath: spec.forProvider.allocatedStorage
DNS-Based Multi-Cloud Failover (Route 53)
Route traffic to a secondary cloud provider automatically on primary health-check failure.
json
{ "Type": "A", "Name": "api.example.com", "SetIdentifier": "primary-aws", "Failover": "PRIMARY", "AliasTarget": { "HostedZoneId": "Z35SXDOTRQ7X7K", "DNSName": "aws-alb-1234.us-east-1.elb.amazonaws.com" }, "HealthCheckId": "aws-primary-hc-id"}{ "Type": "A", "Name": "api.example.com", "SetIdentifier": "secondary-gcp", "Failover": "SECONDARY", "AliasTarget": { "HostedZoneId": "Z2FDTNDATAQYW2", "DNSName": "gcp-lb-5678.example.com" }}
Cross-Cloud Cluster Mesh (Cilium ClusterMesh)
Enable pod-to-pod connectivity and service discovery between clusters on different clouds.
bash
# Enable clustermesh on each cluster with a unique cluster ID/namecilium clustermesh enable --context eks-us-east \ --service-type LoadBalancercilium clustermesh enable --context gke-us-central \ --service-type LoadBalancer# Connect the two clusters bidirectionallycilium clustermesh connect \ --context eks-us-east \ --destination-context gke-us-central# Verify connectivity and global service statuscilium clustermesh status --context eks-us-east --wait
Data Consistency Patterns Across Clouds
How to handle state when workloads span providers.
- Active-Passive Replication- Primary writes to one cloud; async replication to a standby in another for DR only
- Active-Active with CRDTs- Conflict-free replicated data types allow concurrent writes in multiple regions/clouds without coordination
- Event-Sourced Sync- Publish domain events to a cross-cloud message bus (e.g. Kafka with MirrorMaker 2) rather than replicating databases directly
- Read Locality, Write Affinity- Serve reads from the nearest cloud/region but pin writes to a single authoritative cloud to avoid conflict resolution
- Split-Brain Risk- Network partitions between clouds can let both sides believe they're primary — design explicit fencing/quorum
Cross-Cloud Governance Controls
Policy and access patterns needed once more than one provider is in scope.
- Policy as Code (OPA/Sentinel)- Enforce the same guardrails (encryption, tagging, region allow-lists) across every provider's Terraform plan
- Centralized Secrets Management- A provider-agnostic vault (HashiCorp Vault) avoids duplicating secrets stores per cloud
- Unified Identity Broker- Federate AWS IAM, Azure AD, and GCP IAM through a single OIDC provider instead of managing three separate identity systems
- Cross-Cloud Audit Aggregation- Ship CloudTrail, Azure Activity Log, and GCP Audit Logs to one SIEM for a single incident-response view
- Blast Radius Isolation- Keep account/subscription/project boundaries per environment so a compromised credential on one cloud can't pivot to another
Pro Tip
Don't pursue multi-cloud for its own sake — a true active-active multi-cloud architecture multiplies operational complexity; most organizations get 80% of the risk-reduction benefit from a single primary cloud plus a cold/warm DR plan on a second provider.
Was this cheat sheet helpful?
Explore Topics
#MultiCloudStrategy#MultiCloudStrategyCheatSheet#CloudComputing#Advanced#Terraform#Multi#Provider#Config#CheatSheet#SkillVeris
