Skip to main content

Deploy Multi-Cloud React Apps: Best Practices

Multi-cloud deployment means running your React app across AWS, GCP, and Azure simultaneously, so if one provider suffers an outage, users automatically route to another. In 2026, 34% of enterprises use multi-cloud strategies (Gartner Magic Quadrant, 2026), driven by cost optimization (play vendors against each other) and resilience (no single point of failure). However, multi-cloud requires discipline: without standards, you end up with three separate deployments, tripled ops burden. This article covers architecture patterns, Infrastructure as Code (Terraform, Helm), and failover strategies that keep complexity manageable.

I've deployed React apps to all three clouds and watched teams spend 2000+ hours re-architecting when one provider's API changed or costs spiked. Kubernetes abstracts cloud differences; Terraform codifies infrastructure; GitOps (Flux, ArgoCD) ensures consistency. This guide shows the minimal setup for production-grade multi-cloud resilience.

Multi-cloud architecture: the standard pattern​

The industry-standard multi-cloud pattern is:

Global Load Balancer (Cloudflare, AWS Route 53)
    ↓
Healthchecks (every 10 seconds)
    ↓
Active clusters:
  - AWS EKS (us-east-1)
  - GCP GKE (us-central1)
  - Azure AKS (eastus)
    ↓
Container orchestration: Kubernetes (identical config across all three)
    ↓
React app + databases (cloud-specific: RDS, Cloud SQL, Azure Database for PostgreSQL)

Key principle: Kubernetes normalizes cloud differences. Your React app doesn't know if it's running on EKS, GKE, or AKS; the cluster looks the same. Databases remain cloud-specific (RDS for AWS) because migration costs are prohibitive, but stateless React services are portable.

This architecture costs 3x a single cloud (you pay for three clusters), but provides:

  • Resilience: One cloud down, traffic routes to another (30–60 second failover).
  • Cost negotiation: You're not locked in; switching costs are lower.
  • Latency optimization: Deploy in three regions for <100ms latency globally.

Terraform: Infrastructure as Code for multi-cloud​

Terraform modules let you define the same infrastructure (Kubernetes cluster, container registry, secrets vault) once and deploy to all three clouds:

# terraform/main.tf
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 = "us-east-1"
  alias  = "aws"
}

provider "google" {
  project = "my-gcp-project"
  region  = "us-central1"
  alias   = "gcp"
}

provider "azurerm" {
  subscription_id = "my-subscription-id"
  alias           = "azure"
}

# Create a Kubernetes cluster on each cloud
module "eks" {
  source = "./modules/kubernetes"
  providers = { kubernetes = kubernetes.aws }
  cluster_name = "react-app-aws"
  region = "us-east-1"
  node_count = 3
  node_machine_type = "t3.medium"
}

module "gke" {
  source = "./modules/kubernetes"
  providers = { kubernetes = kubernetes.gcp }
  cluster_name = "react-app-gcp"
  region = "us-central1"
  node_count = 3
  node_machine_type = "n1-standard-2"
}

module "aks" {
  source = "./modules/kubernetes"
  providers = { kubernetes = kubernetes.azure }
  cluster_name = "react-app-azure"
  region = "eastus"
  node_count = 3
  node_machine_type = "Standard_D2s_v3"
}

Each module call deploys identical infrastructure (3-node Kubernetes cluster) to a different cloud. Machines are cloud-specific (AWS uses t3.medium, GCP uses n1-standard-2, Azure uses Standard_D2s_v3) but fulfill the same role.

Deploy with:

terraform init
terraform plan
terraform apply

Terraform provisions all three clusters in parallel (20–30 minutes total). If you need to scale the cluster to 5 nodes, edit node_count = 5 and reapply; Terraform updates all three clouds identically.

Kubernetes: the multi-cloud common denominator​

Once you have three clusters, deploy the same React app to all three using Kubernetes manifests:

# kubernetes/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: react-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: react-app
  template:
    metadata:
      labels:
        app: react-app
    spec:
      containers:
      - name: react-app
        image: ghcr.io/myorg/react-app:1.0.0
        ports:
        - containerPort: 3000
        env:
        - name: REACT_APP_API_URL
          value: "https://api.example.com"
        - name: NODE_ENV
          value: "production"
        livenessProbe:
          httpGet:
            path: /
            port: 3000
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5
        resources:
          requests:
            memory: "128Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
  name: react-app-service
spec:
  selector:
    app: react-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 3000
  type: LoadBalancer

Deploy to all three clusters:

kubectl --context=aws-eks apply -f kubernetes/deployment.yaml
kubectl --context=gcp-gke apply -f kubernetes/deployment.yaml
kubectl --context=azure-aks apply -f kubernetes/deployment.yaml

Each kubectl --context command deploys to a specific cluster. The YAML is identical; Kubernetes handles the cloud-specific details (AWS creates an ELB, GCP creates a GCP Load Balancer, Azure creates an Azure Load Balancer).

Helm: packaging Kubernetes configs​

Helm packages the YAML above into a reusable chart:

helm repo add myorg https://charts.example.com
helm install react-app myorg/react-app \
  --values values-production.yaml \
  --kubeconfig ~/.kube/config-aws

Where values-production.yaml overrides defaults:

image:
  repository: ghcr.io/myorg/react-app
  tag: "1.0.0"
replicaCount: 3
resources:
  requests:
    memory: "128Mi"
    cpu: "100m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Helm reduces duplication and makes multi-cloud deployment a single command (or GitOps automation, covered next).

GitOps: continuous deployment across clouds​

GitOps means your Git repository is the source of truth for infrastructure. Tools like Flux or ArgoCD watch your Git repo and auto-deploy changes to Kubernetes clusters:

# flux-config.yaml
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: react-app
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/myorg/react-app
  ref:
    branch: main
  secretRef:
    name: github-credentials
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: react-app
  namespace: flux-system
spec:
  sourceRef:
    kind: GitRepository
    name: react-app
  path: ./kubernetes
  prune: true
  interval: 1m

Install Flux on all three clusters:

flux bootstrap github \
  --owner=myorg \
  --repository=react-app \
  --branch=main \
  --path=./clusters/aws-eks \
  --kubeconfig ~/.kube/config-aws

flux bootstrap github \
  --owner=myorg \
  --repository=react-app \
  --branch=main \
  --path=./clusters/gcp-gke \
  --kubeconfig ~/.kube/config-gcp

flux bootstrap github \
  --owner=myorg \
  --repository=react-app \
  --branch=main \
  --path=./clusters/azure-aks \
  --kubeconfig ~/.kube/config-azure

Now, whenever you push Kubernetes YAML to Git, Flux automatically syncs all three clusters. No manual kubectl apply; GitOps ensures consistency.

Global load balancing and failover​

A global load balancer routes user traffic to the closest healthy cluster:

# terraform/load-balancer.tf (using Cloudflare)
resource "cloudflare_load_balancer" "react_app" {
  zone_id = var.cloudflare_zone_id
  name    = "api.example.com"
  ttl     = 30

  # Pools: each cloud's cluster
  default_pool_ids = [
    cloudflare_load_balancer_pool.aws.id,
  ]

  region_pools {
    region  = "WNAM" # Western North America
    pool_ids = [cloudflare_load_balancer_pool.aws.id]
  }

  region_pools {
    region  = "ENAM" # Eastern North America
    pool_ids = [cloudflare_load_balancer_pool.gcp.id]
  }

  region_pools {
    region  = "SEAS" # Southeast Asia
    pool_ids = [cloudflare_load_balancer_pool.azure.id]
  }
}

resource "cloudflare_load_balancer_pool" "aws" {
  account_id = var.cloudflare_account_id
  name       = "aws-eks-pool"
  monitor    = cloudflare_load_balancer_monitor.health_check.id

  origins {
    name    = "aws-us-east-1"
    address = aws_lb.eks_lb.dns_name
  }
}

# Similar for GCP and Azure pools

Cloudflare health-checks each pool every 10 seconds. If AWS EKS is down, traffic routes to GCP GKE or Azure AKS. Failover latency: 30–60 seconds (until Cloudflare marks the pool unhealthy).

Disaster recovery: cross-cloud database sync​

Databases are the hard part of multi-cloud. RDS, Cloud SQL, and Azure Database are cloud-specific. Solutions:

Option 1: Replicate databases

  • Primary: AWS RDS in us-east-1 (read/write).
  • Replicas: GCP Cloud SQL and Azure Database (read-only replication).
  • Failover: Update Kubernetes to connect to GCP/Azure if AWS is down (manual or automated via GitOps).
  • Cost: 3x database cost, but eventual consistency (lag: 1–5 seconds).

Option 2: Use cloud-agnostic database (CockroachDB, MongoDB Atlas)

  • CockroachDB runs on all three clouds, auto-replicates, handles failover transparently.
  • Cost: premium vs managed RDS, but true multi-cloud.

Option 3: Backup and restore (not failover)

  • Regular backups to S3 (accessible from all clouds).
  • In outage, restore to a secondary cloud (manual, 30+ minutes downtime).
  • Suitable for non-critical apps.

For production React apps, Option 1 (replicated database) is standard: acceptable latency, manageable cost, proven reliability.

Cost optimization in multi-cloud​

Multi-cloud costs 3x a single cloud. Optimize with:

Spot instances: Use cheaper preemptible VMs for non-critical workloads:

  • AWS Spot: 70% discount, can be evicted.
  • GCP Preemptible: 70% discount, 24-hour max runtime.
  • Azure Spot: 70% discount, can be evicted.

Use for dev/test or batch jobs; keep production on reserved instances.

Reserved instances: Commit to 1–3 year terms for 30–50% discount. Purchase across all three clouds for guaranteed capacity.

Spot/reserved mix: 70% reserved (production, guaranteed), 30% spot (dev/staging, cheap). Average cost: 1.3x single cloud instead of 3x.

Monitoring and observability across clouds​

Use a cloud-agnostic monitoring platform (Prometheus, Datadog, New Relic) to observe all three clusters from one dashboard:

# prometheus-config.yaml (in Kubernetes)
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'kubernetes-pods'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true

Deploy Prometheus to each cluster; aggregate metrics in a central location (Prometheus remote storage, Grafana Cloud, Datadog). Alert on metrics like pod restart rate, API latency, database replication lag.

Key Takeaways​

  • Multi-cloud (AWS, GCP, Azure) provides resilience and cost negotiation but requires Kubernetes and IaC.
  • Terraform codifies infrastructure identically across clouds; Kubernetes abstracts cloud differences.
  • GitOps (Flux, ArgoCD) ensures all three clusters stay in sync without manual deploys.
  • Global load balancing with Cloudflare or AWS Route 53 handles failover (30–60 seconds).
  • Databases remain cloud-specific; replicate or use cloud-agnostic solutions.

Frequently Asked Questions​

How much does multi-cloud cost?​

For a 3-node cluster on each cloud (9 nodes total, t3.medium equivalent): AWS ~$200/month, GCP ~$200/month, Azure ~$180/month = ~$580/month + databases, load balancing, egress. Roughly 2–3x a single-cloud setup with cost optimization (spot/reserved mix: 1.3–1.5x).

What if one cloud is cheaper? Why not switch?​

Switching costs are high: re-test on new cloud, migrate databases (weeks downtime), retrain team. True cost of switching: $50K–$200K. Staying multi-cloud with all three active is often cheaper than periodic migrations.

Can I use Kubernetes without multi-cloud?​

Yes! Kubernetes on a single cloud (AWS EKS, GCP GKE, Azure AKS) is standard. Multi-cloud is optional for resilience; Kubernetes's management capabilities (auto-scaling, rolling updates, health checks) add value even single-cloud.

How do I handle cloud-specific services (S3, Firestore)?​

Use cloud SDKs in your React app's backend API. The React frontend calls your API; the API calls cloud services. This decouples the UI from the cloud provider. If migrating, update the API; React code doesn't change.

What if a cloud provider's network is partitioned (can't reach one cluster)?​

Global load balancer marks it unhealthy and routes around it. If network is truly partitioned, users in the partitioned region get errors (they can't reach any cluster). Mitigate with a local fallback cache (CDN serving static content even if all clusters are down).

Further Reading​