Multi-Cloud — Fundamentals

The hook: this is the section that actually contradicts marketing slides

Vendor conference slides love "multi-cloud strategy" diagrams with clean arrows between three cloud logos. Real multi-cloud is messier: two different IAM models to keep in sync, egress bills that show up a month after the architecture decision was made, and a team that now needs working knowledge of two consoles instead of one. This section is deliberately concrete about the actual tools and the actual costs, not the slide-deck version.

Analogy

Multi-cloud tooling is like international business travel gear: a universal power adapter (Terraform) solves the "different plug shape" problem everywhere, and a translation app (Kubernetes as a common workload API) solves the "everyone speaks a different language" problem reasonably well for basic requests — but neither one makes local customs, local law, or local business etiquette (each cloud's actual IAM model, networking primitives, and pricing) suddenly the same everywhere. The adapter and the app reduce friction; they don't erase the fact that you're operating in genuinely different places.

What is multi-cloud?

Multi-cloud means using services from more than one public cloud provider simultaneously, deliberately — for example: AWS for machine learning workloads (SageMaker has one of the deepest ML ecosystems), Azure for Kubernetes and enterprise identity (AKS plus tight Entra ID/Active Directory integration), and GCP for analytics (BigQuery is a frequent standout for large-scale data warehousing). Each cloud is used for what it does best, rather than one provider trying to be everything.

Multi-cloud is different from hybrid cloud. Hybrid cloud = one public cloud connected to your own on-premise data center. Multi-cloud = multiple public cloud providers (AWS, Azure, GCP) — no on-premise component required.

Multi-cloud by design vs. by accident

Most organizations that end up multi-cloud got there by accident — different teams independently chose different clouds, or an acquisition brought in a company already running on a different provider. Managing this unplanned multi-cloud reality is harder than deliberately designing for it, because there was never a single point where tooling, IAM federation, and observability were chosen consistently. The tools and patterns below apply to both scenarios — whether multi-cloud was a deliberate decision or something the organization now has to make manageable after the fact.

Why organizations go multi-cloud

|---|---|---|

Multi-cloud challenges

|---|---|---|

Tools that make multi-cloud manageable

|---|---|---|

Terraform multi-cloud in practice

# providers.tf — configure multiple clouds in one codebase
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 {}
  subscription_id = var.azure_subscription_id
}

provider "google" {
  project = var.gcp_project
  region  = "us-central1"
}

# Primary workload on AWS, warm DR standby on Azure —
# each resource block targets its own provider explicitly.
resource "aws_instance" "primary" {
  ami           = var.primary_ami
  instance_type = "t3.medium"
  tags          = { Role = "primary" }
}

resource "azurerm_linux_virtual_machine" "dr" {
  name                = "dr-standby-vm"
  resource_group_name = azurerm_resource_group.dr.name
  location            = "eastus"
  size                = "Standard_B2s"
  tags                = { Role = "dr-standby" }
}

One Terraform codebase, two provider blocks, and each resource declares which cloud it belongs to explicitly — this is what "Terraform abstracts the API, not the platform" means in practice: the workflow (plan/apply, state management, modules) is shared, but each resource type is still fully cloud-specific underneath.

Multi-cluster Kubernetes in practice

A common way to run the same Kubernetes-based application across AKS and EKS simultaneously combines three pieces:

# ArgoCD ApplicationSet — deploy the same app to every registered cluster
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: myapp-multi-cluster
spec:
  generators:
    - clusters: {}   # targets every cluster ArgoCD knows about (AKS + EKS)
  template:
    metadata:
      name: '{{name}}-myapp'
    spec:
      source:
        repoURL: https://github.com/org/myapp-manifests
        targetRevision: main
        path: k8s/overlays/{{name}}
      destination:
        server: '{{server}}'
        namespace: myapp

Common multi-cloud architecture patterns

|---|---|---|

Multi-cloud networking options

|---|---|---|

Multi-cloud adds real operational complexity — know the tradeoffs before choosing it

Every one of the tools and patterns above reduces multi-cloud's cost; none of them makes it free. The recurring, real costs to weigh before committing to a multi-cloud architecture:

How it fits together (diagram)

   Deliberate multi-cloud (has a named driver)     Accidental multi-cloud (no driver)
   ─────────────────────────────────────────       ───────────────────────────────────
   Best-of-breed / regulatory / M&A / lock-in       Different teams picked differently,
   avoidance — chosen up front                      or inherited via acquisition

              │                                                │
              ▼                                                ▼
   ┌──────────────────────────────────────────────────────────────────┐
   │        Cloud-agnostic tooling layer (reduces, doesn't erase,      │
   │        the real cost below)                                      │
   │  Terraform/Pulumi (IaC)  │  Kubernetes (workload API)  │ Vault    │
   │  Datadog/Prometheus (observability)  │  CSPM (security posture)  │
   └──────────────────────────────────────────────────────────────────┘
              │                                                │
              ▼                                                ▼
   ┌─────────────────┐                              ┌─────────────────┐
   │   Cloud A (AWS)  │◄──── VPN / Interconnect ────►│  Cloud B (Azure) │
   └─────────────────┘                              └─────────────────┘

Real, ongoing costs that never fully go away regardless of tooling:
skills gap · data egress fees · security/IAM inconsistency · 2x ops overhead

Try it yourself (2 minutes)

Take the "Why organizations go multi-cloud" table above and, for each reason, write one sentence describing what evidence would actually prove that reason applies to a real organization (not just "resilience" as an abstract word, but a specific, named regulatory citation, a specific service capability gap, or a specific dollar figure for vendor-lock-in risk). If you can't write a concrete sentence for a given reason, that's a sign the reason is being used as a justification rather than an actual driver — the same test a real multi-cloud proposal should be put through before it's approved.