Multi-Cloud Strategy

Category: Cloud

Learning Path: What → Why → Architecture → Setup → Real Examples → Production → Interview Prep

---

What is Multi-Cloud Strategy?

Multi-cloud means deliberately using more than one public cloud provider. Good reasons: avoid vendor lock-in for critical infrastructure, use best-of-breed services (GCP BigQuery + Azure AKS), regulatory requirement to keep data in specific regions. Bad reasons: "just in case" without a real use case. Multi-cloud adds significant operational complexity — every tool must work across clouds, team must know multiple platforms, costs increase.

Why Multi-Cloud Strategy?

The tools that make multi-cloud manageable: Terraform abstracts cloud APIs behind a common HCL language — one team skills set, multiple cloud providers. Kubernetes means the same manifests deploy to AKS, EKS, or GKE with minimal changes. Crossplane extends Kubernetes to provision cloud resources (databases, queues) using K8s-native YAML. Unified observability (Datadog, Prometheus federation) spans clouds.

Why this exists (the hook)

Picture a company that grew by acquisition: the original team built everything on AWS, then acquired a startup that had already built its product on Azure. Migrating the acquired team's entire stack to AWS would take a year and risk breaking a working product; running both indefinitely with zero coordination means two separate on-call rotations, two separate security postures, and two teams that can't share infrastructure knowledge. Multi-cloud strategy is the discipline of deciding, deliberately, how much to unify versus how much to just let run in parallel — and doing it for a reason, not by accident.

Analogy

Think of multi-cloud like a company operating in two countries after a merger, rather than everyone learning to speak the other office's language and file the other country's paperwork by hand for every process, a well-run multi-national standardizes what it can (a common project-management tool, a common reporting format) while accepting that some things — local tax law, local hiring rules — genuinely can't be unified and have to be handled per-country. Terraform, Kubernetes, and unified observability are the "common project-management tool" of multi-cloud: they reduce duplicated effort on the parts that really can be standardized, while each cloud's actual IAM model, networking primitives, and pricing structure remain genuinely different — the multi-cloud equivalent of local tax law that no abstraction tool actually eliminates.

How it fits together (diagram)

                 ┌─────────────────────────────┐
                 │   Terraform / Pulumi (IaC)   │  ← one config language,
                 └──────────────┬──────────────┘     provider-specific blocks
                                 │
        ┌────────────────────────────────────────────────┐
        │                                                  │
   ┌────▼────┐                                       ┌─────▼────┐
   │   AWS   │◄──── VPN / Direct Connect / ExpressRoute ────►│  Azure  │
   │  (EKS)  │         cross-cloud networking            │  (AKS)  │
   └────┬────┘                                       └─────┬────┘
        │                                                    │
        └─────────────► Unified observability ◄──────────────┘
                    (Datadog / Prometheus + Thanos)

Kubernetes workload manifests are the one thing that's genuinely
portable as-is across the bottom row. Storage, serverless, and IAM
are NOT — those stay cloud-specific no matter which tool you use.

Try it yourself (2 minutes)

Think through a company you know (or a hypothetical one) that uses two different SaaS tools for the same job — two chat apps, two ticketing systems, two cloud providers. List three real costs of that duplication (retraining, inconsistent data, doubled admin overhead) and one real benefit (if any exists). If you can't name a concrete benefit beyond "it happened by accident" or "just in case," that's exactly the signal a multi-cloud proposal without a named driver should raise — the same reasoning this section's "good reasons vs. bad reasons" list applies to an actual cloud migration decision.

---

Learning Modules

Module 01 — Why Multi-Cloud?

Reasons, risks and honest trade-offs

Multi-cloud means deliberately using more than one public cloud provider. Good reasons: avoid vendor lock-in for critical infrastructure, use best-of-breed services (GCP BigQuery + Azure AKS), regulatory requirement to keep data in specific regions. Bad reasons: "just in case" without a real use case. Multi-cloud adds significant operational complexity — every tool must work across clouds, team must know multiple platforms, costs increase.

Topics covered:

# VALID MULTI-CLOUD REASONS:

# 1. Best-of-breed services
#    Use GCP BigQuery for data analytics (best in class)
#    Use Azure AKS + Entra ID for enterprise K8s (deep AD integration)
#    Use AWS Lambda for serverless (largest ecosystem)

# 2. Regulatory / data sovereignty
#    Customer data MUST stay in India (use Azure India region)
#    EU customer data MUST stay in EU (use AWS EU regions)
#    DR requirement in different provider (bank regulation)

# 3. Acquisition / merger
#    Company A uses AWS, acquires Company B using Azure
#    Short-term: run both, migrate gradually

# 4. Avoid critical single-vendor dependency
#    Kubernetes control plane on AWS, DR on Azure
#    Database primary on Azure, replica on GCP

# HIDDEN COSTS OF MULTI-CLOUD:
#   - Engineers need expertise in 2-3 platforms (expensive)
#   - Data transfer between clouds = egress fees ($$$)
#   - Different APIs, different IAM models, different networking
#   - Double the monitoring, double the security tooling
#   - CI/CD pipelines must deploy to multiple targets

# WHEN NOT TO DO MULTI-CLOUD:
#   - Small team (< 20 engineers)
#   - No clear business requirement
#   - "Just in case" reasoning
#   - If the answer is cloud-agnostic containers anyway

Module 02 — Cloud-Agnostic Tools

Terraform, Kubernetes, Crossplane

The tools that make multi-cloud manageable: Terraform abstracts cloud APIs behind a common HCL language — one team skills set, multiple cloud providers. Kubernetes means the same manifests deploy to AKS, EKS, or GKE with minimal changes. Crossplane extends Kubernetes to provision cloud resources (databases, queues) using K8s-native YAML. Unified observability (Datadog, Prometheus federation) spans clouds.

Topics covered:

# Terraform multi-cloud — one module, multiple providers

# providers.tf
terraform {
  required_providers {
    aws   = { source = "hashicorp/aws",   version = "~> 5.0" }
    azurerm = { source = "hashicorp/azurerm", version = "~> 3.0" }
    google = { source = "hashicorp/google", version = "~> 5.0" }
  }
}

provider "aws" {   region = "us-east-1" }
provider "azurerm" { features {} }
provider "google" { project = "my-project" }

# Same K8s manifest deploys to AKS, EKS, GKE:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  # Works on any K8s — cloud-agnostic
  # Only cloud-specific part: StorageClass and LoadBalancer annotations

# Crossplane — provision cloud resources via K8s YAML
apiVersion: database.azure.crossplane.io/v1beta1
kind: PostgreSQLServer
metadata:
  name: prod-db
spec:
  forProvider:
    resourceGroupName: prod-rg
    location: eastus
    sku:
      tier: GeneralPurpose
      capacity: 4
  writeConnectionSecretToRef:
    name: prod-db-conn     # Secret injected into K8s automatically

# Unified monitoring across clouds:
# Datadog agent deployed on each cluster (AKS + EKS)
# Single Datadog workspace shows all clouds
# Or: Prometheus federation — each cluster scrapes locally,
# central Thanos aggregates across all clusters

Module 03 — Multi-Cloud Patterns

Active/active, primary/DR, data mesh

Three common multi-cloud patterns: (1) Primary + DR: run everything on AWS, DR on Azure. Lower complexity, higher availability. (2) Active/active: both clouds serve production traffic via global load balancer. Highest availability, highest complexity, stateless only. (3) Data mesh: business domains own their data in the cloud that fits best — payments on Azure, analytics on GCP BigQuery.

Topics covered:

# Pattern 1: Primary AWS + DR Azure
# Primary: All production traffic on AWS (EKS + RDS)
# DR: Warm standby on Azure (AKS + Azure SQL)
# Replication: Database streaming replication cross-cloud via VPN
# Failover: Route53 → Azure Traffic Manager (DNS switch)

# Pattern 2: Active/Active
# AWS us-east-1 + Azure East US both serving 50% traffic
# Global load balancer: AWS Global Accelerator or Cloudflare
# Challenge: stateless only (or distributed cache like Redis)
# Data: Cosmos DB multi-region or CockroachDB multi-cloud

# Pattern 3: Best-of-breed per domain
# Payment processing:     Azure (deep .NET/MSSQL ecosystem)
# Data analytics:         GCP (BigQuery is unmatched)
# AI/ML workloads:        AWS (SageMaker ecosystem)
# Web/API serving:        Any cloud via K8s

# Multi-cloud networking options:

# Option A: VPN tunnels (simplest)
# AWS VPC ←IPSec VPN→ Azure VNet
# Bandwidth: up to 10 Gbps
# Latency: adds ~2-5ms
# Cost: VPN gateway fees both sides

# Option B: Dedicated interconnect
# AWS Direct Connect + Azure ExpressRoute to same co-location
# Bandwidth: 100 Gbps
# Latency: lowest possible
# Cost: $$$$ but required for financial/healthcare

# Option C: Overlay network (Cilium Cluster Mesh)
# Pod-to-pod connectivity across AKS and EKS
# Same K8s NetworkPolicy across both clusters
ciliumclustermesh connect \\
  --context aws-prod \\
  --destination-context azure-prod

---

Production Example

# Multi-Cloud — Interview Answer Framework

# Q: "How would you design a multi-cloud strategy for our company?"

# FIRST QUESTION BACK: "What is the business driver?"
# If no clear driver → recommend single cloud first
# If clear driver → design for that specific need

# ANSWER for "avoid vendor lock-in" driver:
# "I build on cloud-agnostic abstractions:
#  1. Kubernetes for compute — same manifests on AKS, EKS, GKE
#  2. Terraform for IaC — same team skills, different providers
#  3. PostgreSQL-compatible databases — RDS, Azure SQL, Cloud SQL
#  4. Standard container images — registry mirrors in each cloud
#
#  I do NOT try to abstract storage or serverless —
#  those are too different across clouds to abstract effectively.
#
#  For the first 12 months: master one cloud (Azure).
#  Month 13+: add second cloud for specific DR or regulatory need.
#  Never go multi-cloud just for theoretical flexibility."

# TOOLS SUMMARY:
# IaC:            Terraform (all clouds)
# Containers:     Kubernetes (AKS/EKS/GKE)
# GitOps:         ArgoCD (multi-cluster, multi-cloud)
# Monitoring:     Datadog or Prometheus + Thanos
# Secrets:        HashiCorp Vault (multi-cloud)
# Networking:     Cilium Cluster Mesh or VPN tunnels
# CI/CD:          GitHub Actions or Azure DevOps (cloud-agnostic)

---

Interview Prep

!!! tip "PSR Formula"

Answer every question: Problem → Solution → Result. 45-90 seconds max.

Common Interview Questions

??? question "What is Multi-Cloud Strategy and why would you use it in production?"

Problem: Depending entirely on one cloud provider means that provider's pricing changes, service limits, regional outages, and roadmap decisions become your organization's problem with no leverage or fallback. Solution: multi-cloud is the deliberate use of more than one public cloud provider, chosen for a specific driver — avoiding critical vendor lock-in, using each provider's genuinely best service for a given workload (best-of-breed), or meeting a regulatory data-residency requirement no single provider satisfies alone. Result: done for a real reason, multi-cloud buys negotiating leverage and resilience against provider-specific failure; done as generic risk hedging with no named driver, it just adds a second full platform's worth of operational cost (tooling, staffing, security surface) without a matching benefit — which is why "should we go multi-cloud" should always be answered with "why, specifically?" first.

??? question "How does Multi-Cloud Strategy work internally? Explain the architecture."

Problem: Running workloads across genuinely different cloud APIs, IAM models, and networking primitives would be unmanageable without a common abstraction layer. Solution: the practical architecture rests on a small set of cloud-agnostic tools: Terraform (or Pulumi) provides one IaC language across providers via separate provider blocks; Kubernetes provides one workload API that runs on EKS, AKS, or GKE with only minor provider-specific differences (storage classes, load-balancer annotations); a network layer (VPN tunnels, dedicated interconnects, or a mesh like Cilium Cluster Mesh) connects the clouds; and unified observability (Datadog, or Prometheus federation with Thanos) gives one view across all of it. Result: the abstraction is real but leaky — teams still need to understand each cloud's actual primitives underneath, which is why multi-cloud never eliminates the need for cloud-specific expertise, it only reduces day-to-day duplication of effort.

??? question "What are the main components of Multi-Cloud Strategy?"

Problem: "Multi-cloud" can mean very different architectures depending on the goal, so a learner needs to know the actual pattern options rather than treating it as one thing. Solution: the three common patterns are (1) Primary + DR — all production traffic on one cloud, a warm/cold standby on a second cloud purely for disaster recovery, the lowest-complexity multi-cloud pattern; (2) Active/active — both clouds serve live production traffic simultaneously behind a global load balancer, the highest availability but highest complexity, and realistically only works for stateless workloads or ones backed by a genuinely multi-cloud-capable database; (3) Best-of-breed / data mesh — different business domains or workload types are deliberately placed on whichever cloud does that specific job best (e.g., analytics on GCP, enterprise identity-heavy workloads on Azure). Result: most real multi-cloud deployments are Primary + DR or best-of-breed, not active/active — active/active's operational complexity is rarely justified outside genuinely mission-critical systems.

??? question "How do you handle failures in Multi-Cloud Strategy?"

Problem: Multi-cloud is sometimes proposed specifically as a resilience strategy, but naive implementations can introduce new failure modes (cross-cloud networking dependencies, inconsistent failover automation) rather than eliminating existing ones. Solution: for a Primary + DR pattern, failover has to be tested regularly, not just configured once — DNS-based failover (Route 53 to Azure Traffic Manager, for example) needs a health-check mechanism that actually detects the primary cloud being down, and database replication across the VPN/interconnect link needs monitoring for replication lag, since a stale standby is not a real DR target. For active/active, failure handling means the global load balancer routing away from an unhealthy region/cloud automatically, and the data layer (a multi-region-capable database) tolerating one side going away without losing writes. Result: the DR/failover mechanism itself is only as reliable as its last real test — an untested multi-cloud failover path is a false sense of security, not actual resilience.

??? question "What is your production experience with Multi-Cloud Strategy?"

Problem: This question is really asking whether you've operated a genuine multi-cloud setup under real constraints, not whether you can define the term. Solution (framework to answer with your own specifics): describe an actual multi-cloud driver you worked with (an acquisition that merged two different cloud estates, a regulatory requirement, a specific best-of-breed service choice), a real challenge it created (cross-cloud egress costs that were higher than expected, an IAM/identity federation setup that took longer than planned, inconsistent monitoring across the two platforms), and the concrete decision you made in response. Result: name the measurable outcome — a real answer names a specific driver and a specific tradeoff encountered, not a generic "we used multiple clouds for resilience." Adapt this with your own actual experience; if you haven't operated real multi-cloud, it's more credible to say so and describe how you'd approach it than to fabricate an example.

??? question "How do you monitor and observe Multi-Cloud Strategy in production?"

Problem: Running separate monitoring stacks per cloud means no single view of system health, doubled on-call runbook complexity, and blind spots at exactly the boundary (cross-cloud networking, cross-cloud data replication) where multi-cloud-specific failures actually occur. Solution: unified observability is not optional overhead in multi-cloud, it's close to a prerequisite — either a SaaS platform (Datadog, New Relic) with agents deployed in every cloud reporting to one workspace, or self-hosted Prometheus federation where each cluster scrapes its own metrics locally and a central Thanos or Cortex instance aggregates across all of them. Cross-cloud-specific signals worth watching explicitly: VPN/interconnect link health and latency, cross-cloud data transfer volume (which is also a cost signal), and replication lag on any cross-cloud database. Result: the goal is one dashboard and one alerting pipeline regardless of which cloud an issue originates in — if an incident response starts with "which cloud's monitoring do I check first," the observability setup isn't actually unified yet.

??? question "What are the security considerations for Multi-Cloud Strategy?"

Problem: Multi-cloud multiplies the attack surface a security team has to reason about — separate IAM models, separate default network configurations, and separate compliance tooling per provider, with no single provider's security console giving a complete picture. Solution: the practical baseline is federated identity — a central IdP (Okta, Entra ID, Google Workspace) with each cloud trusting it via OIDC/SAML, rather than maintaining separate IAM users per cloud that drift out of sync; a CSPM tool (Cloud Security Posture Management — Wiz, Prisma Cloud, or similar) that gives one unified view of misconfigurations across all clouds instead of checking each provider's native tool separately; and consistent encryption/network-isolation policy enforced the same way regardless of which cloud a workload runs on, rather than each team reinventing it per cloud. Result: the single biggest multi-cloud security risk in practice is inconsistency — a security control that's enforced rigorously on the primary cloud but only loosely applied on the secondary one, because it wasn't built with both platforms in mind from the start.

??? question "How does Multi-Cloud Strategy compare to alternatives?"

Problem: The real alternative to multi-cloud isn't "no cloud," it's single-cloud with strong internal practices (multi-AZ, multi-region within one provider, disciplined IaC and tagging) — and multi-cloud is frequently reached for to solve problems that single-cloud resilience already solves more cheaply. Solution: single-cloud, multi-region design handles the large majority of realistic availability requirements (a whole-region outage) at a fraction of multi-cloud's operational cost, since it avoids the second platform's IAM model, networking primitives, and tooling entirely. Multi-cloud earns its cost specifically when the requirement genuinely cannot be met within one provider — a named regulatory mandate, a best-of-breed service gap large enough to matter, or a real vendor-dependency risk for something business-critical. Result: the honest comparison is "multi-cloud is more resilient against one specific risk (whole-provider failure or lock-in) at a real, ongoing cost" — not "multi-cloud is strictly more resilient," since it introduces its own new failure surfaces (cross-cloud networking, inconsistent security posture) that single-cloud multi-region design doesn't have.

??? question "Explain Why Multi-Cloud? in Multi-Cloud Strategy."

Problem: "Why multi-cloud" is the question every proposal for it should have to answer explicitly, because the honest default answer for most organizations is "don't." Solution: valid reasons are specific and nameable — best-of-breed services (using GCP BigQuery for analytics while running primary infrastructure elsewhere, because BigQuery is genuinely the strongest option for that need), regulatory/data-sovereignty requirements that no single provider's regions satisfy, an acquisition that merged two companies already on different clouds, or avoiding a critical single-vendor dependency for something the business genuinely cannot afford to lose to one provider's outage. The invalid reason, stated directly, is "just in case" — generic risk hedging with no specific driver, which trades a certain ongoing cost for a hypothetical benefit. Result: any real multi-cloud proposal should be able to name its specific driver in one sentence; if it can't, the default answer should be to master one cloud first.

??? question "Explain Cloud-Agnostic Tools in Multi-Cloud Strategy."

Problem: Without a shared toolchain, multi-cloud means maintaining entirely separate skill sets, IaC codebases, and operational practices per provider — which multiplies the very complexity multi-cloud is often adopted to manage. Solution: Terraform (or Pulumi) abstracts provider APIs behind one configuration language, so a team's IaC skills transfer across AWS/Azure/GCP even though each provider block still needs provider-specific resource knowledge underneath. Kubernetes provides one workload deployment model that runs with minimal changes on EKS, AKS, or GKE. Crossplane extends that further, letting Kubernetes-native YAML provision actual cloud resources (a managed database, a queue) through the same GitOps workflow as application deployments. Unified observability (Datadog, or Prometheus federation) closes the last gap — one place to see health and cost across every cloud in use. Result: these tools reduce, but don't eliminate, multi-cloud's operational cost — they're the difference between "multi-cloud is barely manageable" and "multi-cloud is manageable for a team with the discipline to actually standardize on them," not a way to make multi-cloud free.

---

Official Resources