Multi-Cloud Infrastructure Setup: AWS, GCP, Azure

Multi-Cloud Infrastructure Setup

Multi-cloud doesn't start with a beautiful architectural diagram on a whiteboard. It starts with a situation: the primary provider went down for three hours and the business lost money. Or: a contract requires data to be stored in the EU, but ML pipelines are cheaper to run on GCP. Or simply: one team historically sits on Azure, another on AWS, and merging them into one account is politically impossible. In all three cases, multi-cloud infrastructure is needed — but its design will be fundamentally different. We design and deploy such solutions turnkey, focusing on real needs, not abstract diagrams.

Two Different Challenges Under One Name

There is Active/Active multi-cloud: the application actually runs in two clouds simultaneously, traffic is balanced between them, and if one fails, the other takes over entirely. This is a complex, expensive architecture. Data synchronization between clouds, global load balancing, identical application versions in two locations — significant operational load.

There is Active/Passive: the primary provider handles traffic, the secondary is warmed up and ready to take over within 15–30 minutes. Data is replicated asynchronously. RPO — 15 minutes, RTO — 30 minutes. This is a realistic option for most projects.

And there is "multi-cloud by specialization": Cloudflare Workers for edge logic, AWS for compute and databases, GCS for cheap cold storage, Vercel for frontend. Each provider does what it does best and cheapest. Connectivity via API is minimal.

Before designing, it's important to understand which of these three challenges we are actually solving.

Why Data Is the Hardest Part of Multi-Cloud?

Compute in multi-cloud is not difficult. Kubernetes works identically in EKS, GKE, and AKS. Terraform manages resources across all three providers. The problem is data. Databases don't natively replicate between clouds.

Replication options for PostgreSQL between AWS RDS and GCP Cloud SQL:

• Logical replication via pglogical — works but requires manual setup and lag monitoring.
• Debezium CDC → Kafka (MSK or Confluent) → Consumer in the target cloud — more reliable but more complex.
• Managed solutions: Google Database Migration Service, AWS DMS — suitable for one-time migration, limited for ongoing replication.

Latency between regions of different providers is 30–80 ms depending on geography. For synchronous requests, this is fatal. Anything that goes cross-cloud must be asynchronous.

Terraform for Multi-Cloud

Single Terraform workspace, multiple providers:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.0"
    }
    google = {
      source = "hashicorp/google"
      version = "~> 5.0"
    }
    azurerm = {
      source = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
  assume_role {
    role_arn = var.aws_role_arn
  }
}

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

Remote state — in S3 with DynamoDB locking, or in Terraform Cloud. State must be single — otherwise outputs from one provider cannot become inputs for another.

Project structure divides by provider:

infrastructure/
  shared/    # common variables, data sources
  aws/
    networking/
    compute/
    databases/
  gcp/
    networking/
    storage/
  ml-platform/
  global/
    dns/      # Cloudflare or Route 53 as global DNS
    monitoring/

Network Between Clouds: How to Connect?

Direct connection between AWS and GCP — via Dedicated Interconnect (GCP) + Direct Connect (AWS) with a common exchange point at a neutral co-location (Equinix, Digital Realty). This is expensive (costs around $2,000/month per port) but provides predictable latency.

For most projects — VPN mesh via WireGuard or Tailscale. Tailscale is especially convenient: agents install on nodes in both clouds, forming a mesh network; all nodes see each other by IP. Configuration is declarative via the Terraform Tailscale provider. Tailscale VPN setup is 10x faster than Direct Connect implementation.

If traffic between clouds only goes through API (HTTP/gRPC) — public endpoints with mTLS are sufficient. Cert-manager issues certificates, SPIFFE/SPIRE provides identity for services regardless of the cloud.

Kubernetes in Multi-Cloud: GitOps and Management

Managing multiple clusters — via fleet management. ArgoCD with ApplicationSet and cluster generators deploys the same applications into EKS and GKE from a single Git repository. Differences between clusters are carried in values-aws.yaml and values-gcp.yaml.

ArgoCD ApplicationSet documentation details the cluster generator feature. Example ApplicationSet:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: backend-service
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            environment: production
  template:
    metadata:
      name: '{{name}}-backend'
    spec:
      project: default
      source:
        repoURL: https://github.com/company/k8s-configs
        targetRevision: main
        path: apps/backend
        helm:
          valueFiles:
            - values.yaml
            - 'values-{{metadata.labels.cloud}}.yaml'
      destination:
        server: '{{server}}'
        namespace: backend

Velero for backups between clouds — PVC snapshots from AWS EBS replicated to GCS as an additional DR layer.

Monitoring and Observability: Single View

Metrics from multiple clouds are collected into a single system. Prometheus federation or VictoriaMetrics with remote_write from each cluster to a central Thanos. Grafana with datasources to both clouds — dashboards show the state of the entire infrastructure.

For distributed tracing — OpenTelemetry Collector in each cluster, export to Jaeger or Grafana Tempo. Traces pass through services in AWS and GCP — the full chain is visible.

Typical Mistakes and How to Avoid Them

Attempting to make the infrastructure completely identical in both clouds is a trap. AWS and GCP have different primitives: Load Balancer Controller in EKS vs GKE Ingress, EBS vs Persistent Disk, Security Groups vs VPC Firewall Rules. Trying to make a one-to-one match wastes time fighting differences, instead of leveraging each provider's strengths.

Abstractions like Crossplane help — but add their own level of complexity and operational overhead.

Step-by-Step: Setting Up Multi-Cloud Terraform

1. Define providers in a single workspace with separate aliases.
2. Create a shared remote state backend (e.g., S3 + DynamoDB).
3. Structure code into modules per provider under a unified infrastructure/ directory.
4. Use outputs from one provider as inputs to another.
5. Apply changes in stages: first networking, then compute, then data.

What Is Included in the Work

Estimated Timelines

We start with an architecture workshop — identify the real task and choose the minimally complex architecture that solves it. We'll evaluate your project in 2 days — just contact us.