Multi-Cloud Strategy in 2026: Avoiding Lock-In Without Creating Chaos

Multi-cloud sounds like the obvious answer to vendor lock-in. If you use AWS, GCP, and Azure simultaneously, no single vendor can hold you hostage. But the reality is messier: most organizations that run multi-cloud do so because of acquisitions, team silos, or "we were already using GCP for ML," not because they planned it.

True multi-cloud architecture — where you deliberately spread workloads across providers — is genuinely complex and expensive. It requires separate IAM systems, networking models, toolchain expertise, and support contracts. Before going multi-cloud, you need a clear answer to: what problem does this actually solve?

This post gives you that framework, plus the Terraform patterns for teams that have a legitimate reason to run across providers.

---

Why Teams Go Multi-Cloud (and Whether It's Worth It)

The honest answer: For most startups and mid-market companies, a well-architected single-cloud deployment is cheaper, simpler, and more reliable than multi-cloud. Go multi-cloud for specific workloads where a specific provider is materially better — not for abstract portability.

---

Multi-Cloud Patterns

Pattern 1: Best-of-Breed (Most Common, Most Practical)

Use the best service for each workload, regardless of provider:

Complexity: Medium. Separate accounts/billing. Requires VPN or private connectivity between providers.

Pattern 2: Active-Active Multi-Cloud DR

Run the same application stack on two providers, with active traffic on both:

User → Anycast DNS (Cloudflare)
  ├── 50% → AWS us-east-1 (primary)
  └── 50% → GCP us-central1 (secondary)

Shared state: Cockroach DB (multi-cloud, cross-region)
              or Neon Postgres (if reads OK from replica)

Complexity: Very high. Shared state across clouds is the hard part. CockroachDB and Neon are the realistic options for SQL; for NoSQL, MongoDB Atlas or DynamoDB Global Tables.

Pattern 3: Cloud Burst

Primary workload on AWS, burst overflow to GCP/Azure when capacity is exhausted. Most relevant for batch compute and ML training.

---

Terraform Multi-Cloud: Project Structure

infrastructure/
  modules/
    compute/
      aws/        ← AWS ECS Fargate module
      gcp/        ← GCP Cloud Run module
      azure/      ← Azure Container Apps module
    database/
      aws/        ← RDS PostgreSQL
      gcp/        ← Cloud SQL
    networking/
      aws/
      gcp/
  environments/
    prod/
      aws.tf       ← AWS provider config
      gcp.tf       ← GCP provider config
      main.tf      ← Orchestrates both
      variables.tf
      outputs.tf

# environments/prod/main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }

  backend "s3" {
    bucket = "myapp-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
  }
}

provider "aws" {
  region = var.aws_region
  default_tags {
    tags = {
      Environment = "production"
      ManagedBy   = "terraform"
      Project     = var.project
    }
  }
}

provider "google" {
  project = var.gcp_project_id
  region  = var.gcp_region
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

AWS Primary Compute Module

# modules/compute/aws/main.tf
resource "aws_ecs_cluster" "main" {
  name = "${var.project}-${var.environment}"

  setting {
    name  = "containerInsights"
    value = "enabled"
  }
}

resource "aws_ecs_task_definition" "api" {
  family                   = "${var.project}-api"
  requires_compatibilities = ["FARGATE"]
  network_mode             = "awsvpc"
  cpu                      = var.cpu
  memory                   = var.memory
  execution_role_arn       = aws_iam_role.ecs_execution.arn
  task_role_arn            = aws_iam_role.ecs_task.arn

  container_definitions = jsonencode([
    {
      name  = "api"
      image = var.image_uri
      portMappings = [{ containerPort = 8080, protocol = "tcp" }]
      environment = [
        { name = "NODE_ENV", value = "production" },
        { name = "PRIMARY_CLOUD", value = "aws" },
      ]
      secrets = [
        { name = "DATABASE_URL", valueFrom = var.db_secret_arn },
      ]
      logConfiguration = {
        logDriver = "awslogs"
        options = {
          "awslogs-group"         = "/ecs/${var.project}-api"
          "awslogs-region"        = var.aws_region
          "awslogs-stream-prefix" = "ecs"
        }
      }
    }
  ])
}

GCP Supplementary Workload Module

# modules/compute/gcp/main.tf — Cloud Run for ML inference
resource "google_cloud_run_v2_service" "ml_inference" {
  name     = "${var.project}-ml"
  location = var.gcp_region

  template {
    containers {
      image = "gcr.io/${var.gcp_project_id}/${var.project}-ml:latest"

      resources {
        limits = {
          cpu    = "4"
          memory = "8Gi"
        }
        # GPU for inference
        # gpu_count = 1
        # gpu_type  = "nvidia-l4"
      }

      env {
        name  = "MODEL_PATH"
        value = "gs://${var.model_bucket}/models/latest"
      }
    }

    scaling {
      min_instance_count = 0  # Scale to zero when idle
      max_instance_count = 10
    }
  }

  traffic {
    type    = "TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST"
    percent = 100
  }
}

# Allow AWS services to invoke via OIDC
resource "google_cloud_run_v2_service_iam_member" "invoker" {
  project  = var.gcp_project_id
  location = var.gcp_region
  name     = google_cloud_run_v2_service.ml_inference.name
  role     = "roles/run.invoker"
  member   = "allUsers"  # Secured via API key; or use workload identity federation
}

Cross-Cloud DNS with Cloudflare

# Cloudflare handles routing between AWS and GCP
resource "cloudflare_record" "api_aws" {
  zone_id = var.cloudflare_zone_id
  name    = "api"
  type    = "A"
  value   = aws_lb.main.dns_name
  proxied = true
}

resource "cloudflare_record" "ml_gcp" {
  zone_id = var.cloudflare_zone_id
  name    = "ml"
  type    = "CNAME"
  value   = trimprefix(google_cloud_run_v2_service.ml_inference.uri, "https://")
  proxied = true
}

# Load balance across clouds (Cloudflare Enterprise feature)
resource "cloudflare_load_balancer" "multi_cloud" {
  zone_id          = var.cloudflare_zone_id
  name             = "api.${var.domain}"
  default_pool_ids = [cloudflare_load_balancer_pool.aws.id]
  fallback_pool_id = cloudflare_load_balancer_pool.gcp.id

  rules {
    name      = "gcp-failover"
    condition = "http.request.uri.path contains \"/ml/\""
    fixed_response {
      # Route ML traffic directly to GCP pool
    }
    overrides {
      default_pools = [cloudflare_load_balancer_pool.gcp.id]
    }
  }
}

---

Cross-Cloud Networking

The two main options for cross-cloud private connectivity:

Option 1: VPN (Low cost, higher latency)

# AWS side
resource "aws_vpn_gateway" "cross_cloud" {
  vpc_id = aws_vpc.main.id
}

resource "aws_customer_gateway" "gcp" {
  bgp_asn    = 65000
  ip_address = google_compute_address.vpn.address
  type       = "ipsec.1"
}

resource "aws_vpn_connection" "to_gcp" {
  vpn_gateway_id      = aws_vpn_gateway.cross_cloud.id
  customer_gateway_id = aws_customer_gateway.gcp.id
  type                = "ipsec.1"
  static_routes_only  = false
}

Cost: $36/month/connection + data transfer fees ($0.02/GB cross-cloud)

Option 2: Interconnect (Low latency, high cost)

AWS Direct Connect + GCP Dedicated Interconnect meeting at a colocation (Equinix). Requires physical circuit provisioning (4–12 weeks lead time).

Cost: $500–$5,000/month depending on bandwidth. Only worthwhile at >1TB/month cross-cloud traffic.

---

Data Egress: The Hidden Tax

Cloud egress fees are the biggest multi-cloud cost surprise:

Key insight: Route all public traffic through Cloudflare — egress to Cloudflare is free from AWS, GCP, and Azure (Bandwidth Alliance). This eliminates internet egress costs almost entirely. Cross-cloud internal traffic still costs $0.08–0.09/GB.

---

Multi-Cloud Cost vs. Single-Cloud

Reality: Multi-cloud costs 40–80% more than single-cloud at equivalent scale. The question is whether the business benefit (negotiating power, compliance, DR) justifies the premium.

---

Working With Viprasol

Our cloud team designs and implements multi-cloud architectures — from simple best-of-breed service selection to active-active DR deployments across AWS and GCP.

What we deliver:

• Cloud strategy review (when multi-cloud makes sense for your business)
• Terraform modules for AWS + GCP + Azure with shared state backends
• Cross-cloud networking (VPN tunnels, private connectivity)
• Cost optimization: egress routing through Cloudflare, reserved instances
• Unified observability across providers with OpenTelemetry + Grafana

→ Discuss your cloud architecture → Cloud infrastructure services

---

See Also

• AWS Cost Optimization Strategies
• Kubernetes and Helm Chart Patterns
• OpenTelemetry Observability
• DevOps and Platform Engineering
• Service Mesh with Istio and Linkerd