<arch.design/>
Principles/Multi-Cloud Strategy
InfrastructureCloudadvanced2018vendor-lock-inresilienceawsgcp

Multi-Cloud Strategy

Distribute workloads across multiple cloud providers to avoid vendor lock-in and improve resilience.

3/5
Operates at: Infrastructure level

Deployment platform — Kubernetes, Docker, cloud config

How it works

Multi-cloud strategy involves using two or more cloud providers (AWS, Azure, GCP) for different workloads or as failover. Motivations include: avoiding vendor lock-in, regulatory requirements for data residency, leveraging best-in-class services from each provider, and negotiating leverage.

Implementation patterns: Active-Active (traffic split across providers), Active-Passive (failover), and Workload-Specific (e.g. ML on GCP, data warehousing on Snowflake, primary on AWS).

Abstraction layers like Kubernetes, Terraform, and service meshes reduce provider-specific coupling.

Why it matters

Cloud outages affect even the largest providers. Multi-cloud provides resilience guarantees that no single provider can match, and prevents strategic dependency on a single vendor.

When to use

  • Enterprise with regulatory or data-sovereignty requirements
  • Workloads where a single cloud outage is unacceptable
  • Best-of-breed service selection across providers

When NOT to use

  • Early-stage companies — operational complexity far outweighs benefits
  • Small teams without dedicated cloud engineers

Trade-offs

+

Resilience against single-provider outages

Significantly higher operational complexity

+

Negotiation leverage with cloud providers

Cannot use provider-specific services without coupling risk

In production

Dropbox

Primary on AWS with secondary DR on GCP for certain workloads

Spotify

Primary GCP + Azure for specific data processing workloads

Industry adoption

3/5Common in specific contexts — used when the problem fits.

Related principles