08 - Multi-Cloud Platform Engineering: Portability and Vendor Lock-in

Multi-Cloud: Strategy and Reality

Multi-cloud is the strategy of using services from two or more cloud providers (AWS, Azure, GCP) to distribute workloads, reduce vendor lock-in risk, and optimize costs. For a platform team, designing a multi-cloud IDP means building abstractions that hide the differences between providers, allowing developers to deploy without worrying about the underlying cloud.

However, multi-cloud is not a silver bullet. It introduces significant complexity in infrastructure management, networking, security, and monitoring. In this article, we will analyze when multi-cloud makes sense, which patterns to adopt, and how to mitigate vendor lock-in without falling into the trap of excessive complexity.

Multi-Cloud Strategies

There is no single multi-cloud strategy. Organizations adopt different approaches based on their needs:

• Active-Active: workloads actively distributed across multiple cloud providers. Maximum resilience but maximum complexity
• Active-Passive: one primary cloud provider with failover to a secondary. Good balance between resilience and complexity
• Best-of-Breed: using the best service from each provider (e.g., AWS for compute, GCP for ML, Azure for enterprise). Optimizes capabilities but complicates governance
• Hybrid: combination of public cloud and on-premise infrastructure. Common in regulated sectors (finance, healthcare)

# Multi-cloud strategy: active-passive with failover
multi-cloud-architecture:
  primary: AWS (eu-west-1)
  secondary: GCP (europe-west1)
  strategy: active-passive

  workload-distribution:
    primary-aws:
      services:
        - all production workloads
        - primary databases (RDS PostgreSQL)
        - primary cache (ElastiCache Redis)
        - primary message queue (MSK Kafka)
      traffic: 100% (normal operations)

    secondary-gcp:
      services:
        - read replicas (Cloud SQL)
        - DR databases (standby)
        - static assets (Cloud CDN)
        - batch processing (BigQuery)
      traffic: 0% (failover only)

  failover:
    trigger: "Primary region unavailable for > 5 minutes"
    rto: "15 minutes"
    rpo: "5 minutes"
    steps:
      1: "DNS failover (Route53 health check)"
      2: "Promote GCP read replicas to primary"
      3: "Scale up GCP compute"
      4: "Verify service health"
      5: "Notify teams"

  data-replication:
    databases: "Async replication, 5-minute lag"
    object-storage: "Cross-cloud sync (rclone)"
    secrets: "Vault replication"
      

Kubernetes as an Abstraction Layer

Kubernetes is the most effective abstraction layer for multi-cloud portability. A containerized application running on Kubernetes can be deployed on EKS (AWS), GKE (GCP), AKS (Azure), or any Kubernetes cluster with minimal changes.

However, portability is not automatic. Areas where cloud specificity emerges include:

• Storage: StorageClass and PersistentVolume differ per provider
• Networking: LoadBalancer, Ingress Controller, and DNS have provider-specific implementations
• IAM: IRSA (AWS), Workload Identity (GCP), Pod Identity (Azure) for pod authentication
• Managed services: managed databases, caches, and message queues are the primary lock-in vector

Cross-Cloud Secrets Management

Secrets management in a multi-cloud environment is particularly critical. Each cloud provider has its own secret management service (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault), and developers should not have to interact with each one separately.

HashiCorp Vault is the most widely adopted solution for centralizing secrets management in multi-cloud environments:

• Centralization: a single management point for all secrets, regardless of cloud
• Dynamic secrets: on-demand generation of temporary credentials (database, AWS IAM, certificates)
• Auto-rotation: automatic secret rotation without application downtime
• Audit: complete log of every secret access for compliance

# Vault: multi-cloud secrets configuration
vault:
  storage:
    type: raft
    ha_enabled: true
    nodes:
      - vault-0.vault.svc (primary)
      - vault-1.vault.svc (follower)
      - vault-2.vault.svc (follower)

  auth-methods:
    # AWS authentication
    aws:
      path: auth/aws
      config:
        access_key: ${VAULT_AWS_ACCESS_KEY}
        secret_key: ${VAULT_AWS_SECRET_KEY}
      roles:
        - name: eks-pods
          bound_iam_principal_arn: "arn:aws:iam::*:role/eks-pod-*"
          policies: [app-secrets]

    # GCP authentication
    gcp:
      path: auth/gcp
      config:
        credentials: ${VAULT_GCP_CREDENTIALS}
      roles:
        - name: gke-pods
          type: iam
          bound_service_accounts: ["*@project.iam.gserviceaccount.com"]
          policies: [app-secrets]

    # Kubernetes authentication (works on any cluster)
    kubernetes:
      path: auth/kubernetes
      roles:
        - name: app-role
          bound_service_account_names: ["app-sa"]
          bound_service_account_namespaces: ["*"]
          policies: [app-secrets]
          ttl: 1h

  secret-engines:
    - path: secret/data/apps
      type: kv-v2
      description: "Application secrets"

    - path: database/
      type: database
      description: "Dynamic database credentials"
      config:
        - name: checkout-db
          plugin: postgresql-database-plugin
          connection_url: "postgresql://{{username}}:{{password}}@checkout-db:5432/checkout"
      

Multi-Cloud Cost Optimization

One of the stated advantages of multi-cloud is cost optimization by choosing the most economical provider for each workload. In practice, this requires sophisticated cost management tools:

• Cost visibility: unified dashboard showing costs per team, service, and cloud provider
• Rightsizing: identifying over-provisioned resources and recommending right-sizing
• Reserved capacity: managing reserved instances, savings plans, and committed use discounts
• Spot/Preemptible: using spot instances for interruption-tolerant workloads
• Tagging policy: mandatory tags for allocating costs to responsible teams

Service Mesh for Cross-Cloud Networking

A service mesh is essential for networking in multi-cloud environments. Istio, in particular, supports multi-cluster configurations that allow services to communicate transparently across different cloud providers:

• Multi-cluster mesh: a single mesh spanning clusters on AWS, GCP, and Azure
• Traffic routing: intelligent routing based on latency, locality, and health status
• Automatic failover: if a service on one cloud is degraded, traffic is redirected
• Cross-cloud mTLS: end-to-end encryption even for communications between different clouds

# Istio: multi-cluster service mesh configuration
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: checkout-service-dr
spec:
  host: checkout-service.checkout.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        h2UpgradePolicy: DEFAULT
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50
    loadBalancer:
      localityLbSetting:
        enabled: true
        failover:
          - from: eu-west-1    # AWS primary
            to: europe-west1   # GCP failover
        distribute:
          - from: eu-west-1/*
            to:
              "eu-west-1/*": 90
              "europe-west1/*": 10