Cloud Architecture Advanced

Multi-Cloud Strategy

A deliberate approach to distributing workloads across two or more cloud providers to reduce vendor dependency, satisfy regulatory requirements, or leverage best-of-breed services.

⏱ 11 min read

What it is

A multi-cloud strategy is the intentional use of infrastructure, platforms, or services from more than one cloud provider within the same organisation. This is distinct from cloud diversity by accident (shadow IT, acquired companies) or hybrid cloud (cloud + on-premises). A true multi-cloud strategy involves deliberate placement decisions: which workloads run on AWS versus GCP versus Azure, and why. It encompasses tooling choices (Terraform vs provider-native CDK), networking topology (cross-cloud private connectivity), data placement (which database lives where), and unified operations (single pane of glass for cost, security, and monitoring).

Multi-cloud spans a spectrum: at one end, a company uses AWS for compute-intensive ML (Sagemaker) and Azure for Microsoft-centric productivity integrations (Active Directory, Teams bots) — largely independent workloads coexisting. At the other extreme, the same application is deployed identically on two clouds with active-active traffic distribution and real-time data replication, enabling instant failover if one provider has a regional outage. The latter is enormously expensive to build and operate; most real-world multi-cloud strategies sit somewhere in between.

Why it exists

The primary driver is avoiding vendor lock-in and the negotiating leverage that portability provides. Organisations that can plausibly move workloads between providers are in a stronger position during contract renewals. Regulated industries (financial services, government) may face legal requirements to avoid single-provider dependency for critical systems. Some multi-cloud strategies are driven by latency: a specific cloud provider may have a data centre in a geography (GovCloud, isolated regions) where others do not.

Best-of-breed selection is another driver: Google BigQuery for analytics (columnar query engine maturity), AWS for breadth of managed services, Azure for enterprise identity integration (Entra ID / ADFS federation). Acquisitions also force multi-cloud adoption — a company acquires a GCP-native startup while running its core platform on AWS, and integrating the two systems without full migration requires cross-cloud networking and unified IAM. In practice, organisational politics and existing commercial relationships often outweigh pure technical rationale in multi-cloud decisions.

When to use

Your organisation requires contractual or regulatory proof of portability and must demonstrate that no single provider is a single point of failure for business continuity.
Different business units or acquired subsidiaries already have committed spend or deep expertise on different cloud providers.
You need a specific capability (BigQuery ML, Azure OpenAI Service, AWS Bedrock) that has no comparable equivalent on your primary cloud.
You operate in geographies or sovereign cloud regions where only one provider is certified for your compliance tier, forcing a second provider for other regions.
SaaS product customers demand deployment in the cloud provider of their choice (bring-your-own-cloud / BYOC model).

When not to use

Small engineering teams — operating a single cloud well is hard; operating two or more compounds IAM, billing, networking, observability, and on-call complexity significantly.
When lock-in risk is theoretical — if your primary reason is "what if AWS goes away?", the operational cost of multi-cloud likely outweighs the hypothetical risk mitigation for most organisations.
Data-heavy applications — the data gravity problem (moving terabytes between clouds costs real money and adds latency) makes active-active multi-cloud prohibitively expensive for data-intensive workloads.
When cloud-agnostic abstraction layers reduce capabilities — using the lowest-common-denominator Kubernetes primitives instead of SQS, Aurora, or BigQuery means sacrificing the very features that justify cloud investment.

Typical architecture


┌─────────────────────────┐      ┌─────────────────────────┐
│        AWS Account      │      │     Azure Subscription  │
│  ┌──────────────────┐   │      │  ┌──────────────────┐   │
│  │  Application     │   │      │  │  Application     │   │
│  │  (EKS + ALB)     │   │      │  │  (AKS + App GW)  │   │
│  └────────┬─────────┘   │      │  └────────┬─────────┘   │
│           │             │      │           │             │
│  ┌────────▼─────────┐   │      │  ┌────────▼─────────┐   │
│  │  RDS Aurora      │   │      │  │  Azure SQL (RO)  │   │
│  │  (primary)       │◄──┼──────┼──│  replica         │   │
│  └──────────────────┘   │      │  └──────────────────┘   │
│                         │      │                         │
│  AWS Transit Gateway    │      │  Azure VNet             │
└──────────┬──────────────┘      └──────────┬──────────────┘
           │  IPSec VPN / ExpressRoute        │
           └──────────────┬───────────────────┘
                          │
              Terraform (cross-cloud IaC)
              Datadog (unified observability)
              HashiCorp Vault (unified secrets)

Pros and cons

Pros

Reduces single-provider dependency for business continuity and disaster recovery.
Improves negotiating leverage on pricing and enterprise agreements.
Enables best-of-breed service selection (BigQuery for analytics, AWS for breadth).
Satisfies regulatory requirements for data residency and provider diversity.
Supports BYOC models for enterprise SaaS customers.

Cons

Significantly higher operational complexity: multiple IAM models, billing systems, networking constructs.
Cloud-agnostic tooling (Terraform, Kubernetes) sacrifices provider-native capabilities and developer experience.
Data egress costs between clouds can be substantial (typically $0.08–0.09/GB).
Security posture is harder to enforce consistently across different provider security models and tooling.
Engineering team expertise must span multiple clouds, increasing hiring and training costs.

Implementation notes

The foundation of a viable multi-cloud strategy is cloud-agnostic infrastructure tooling. Terraform (with provider-specific modules) is the de-facto standard: define a module/service abstraction that provisions an EKS cluster on AWS or an AKS cluster on Azure from the same interface. Kubernetes as a common runtime layer allows workload portability at the container level, though you must still deal with provider-specific storage classes, load balancer annotations, and IAM integrations. Use Istio or Linkerd for service mesh across clusters; Skupper or Submariner for cross-cloud service discovery without leaking cloud-provider DNS.

For identity, federate both providers to a single enterprise IdP (Okta, Microsoft Entra ID / Azure AD) using OIDC federation rather than maintaining separate IAM users in each cloud. AWS IAM Identity Center and Azure's workload identity federation both support OIDC. Unified secrets management with HashiCorp Vault or AWS Secrets Manager with cross-cloud replication reduces the risk of configuration drift. For cross-cloud networking, AWS Transit Gateway with a VPN attachment to Azure VNet (or ExpressRoute / AWS Direct Connect for dedicated circuits) provides private connectivity; plan CIDR ranges across providers at the outset to avoid conflicts.

Common failure modes

Accidental multi-cloud without strategy: Acquired companies or shadow IT projects create multi-cloud sprawl without governance, leading to duplicated costs and security gaps rather than intentional resilience.
Data gravity underestimated: Architectures that assumed petabyte-scale datasets could freely move between clouds discover egress costs and latency make cross-cloud data movement impractical.
Abstraction layer regressions: Teams using only Kubernetes primitives to achieve cloud-agnosticism miss out on DynamoDB, Aurora Serverless, or Pub/Sub, effectively paying cloud prices for commodity compute.
Inconsistent security controls: Security teams apply tight guardrails on the primary cloud but miss the second cloud's IAM misconfigurations, creating an asymmetric attack surface.
Operational fatigue: On-call engineers must be proficient in two provider consoles, two networking models, and two sets of managed service failure modes — incident resolution times increase significantly.

Decision checklist

Have you quantified the data egress costs of replicating your data volumes across clouds at your current and projected scale?
Do you have engineering capacity to maintain expertise (certifications, runbooks, on-call rotation) across all targeted cloud providers?
Is the primary driver a genuine technical or regulatory need, or is it a perception of risk that may not materialise?
Have you decided on a cloud-agnostic abstraction layer and accepted the feature trade-offs it entails?
Is there a unified identity federation plan across all providers to prevent IAM sprawl?
Do you have a unified observability strategy (single pane of glass) that works across all provider telemetry formats?

Example use cases

Financial services firm: Core banking on Azure (Microsoft-centric enterprise stack + ADFS), ML fraud detection on AWS SageMaker with cross-cloud training data delivered via Snowflake's multi-cloud data sharing to avoid raw egress costs.
Global SaaS provider (BYOC): Deploys tenant environments on the customer's preferred cloud (AWS, GCP, or Azure) using the same Helm charts, with Terraform workspaces and a per-tenant configuration model stored in the vendor's control plane.
Government agency: US-classified workloads on AWS GovCloud (required by FedRAMP High), EU citizen data on Azure Government-equivalent sovereign regions (required by GDPR residency commitments), connected via dedicated private circuits.

Cloud Landing Zones — provides the account/subscription structure that governs each cloud provider's environment.
Cloud Networking — cross-cloud VPN and PrivateLink patterns for secure multi-cloud connectivity.
Disaster Recovery Patterns — multi-cloud active-active is the most expensive DR strategy.
Infrastructure as Code — Terraform multi-provider modules are the execution mechanism for multi-cloud IaC.