Multi-cloud management is harder than the marketing makes it sound. The right tools: Terraform or Pulumi for infrastructure, a unified observability layer, and a clear reason to be multi-cloud. Without the clear reason, multi-cloud is just operational overhead.
Table of contents
- Why be multi-cloud at all
- The infrastructure layer
- The observability layer
- The identity layer
- The data layer
- The Terraform state management
- The cost allocation challenge
- FAQ
Why be multi-cloud at all
Three legitimate reasons:
- Best-of-breed services. The team that uses AWS for compute, GCP for BigQuery, and Cloudflare for the CDN is using each cloud’s strongest service.
- Vendor leverage. The team that is multi-cloud has negotiating leverage with each provider.
- Regulatory. Some data must stay in specific regions; some workloads must avoid specific providers.
The illegitimate reasons: “we want to be cloud-agnostic” (rarely works), “the CTO read an article” (not a strategy), “we want to use the best of both” (usually means double the work).
The infrastructure layer
The right tool for multi-cloud infrastructure is Terraform or Pulumi. Both support every major cloud provider through first-class providers. The team that uses one tool across all clouds has a consistent infrastructure layer.
The team that uses the cloud-specific tool on each cloud (CloudFormation on AWS, Deployment Manager on GCP, ARM templates on Azure) has three infrastructure pipelines to maintain. The team that picks Terraform has one.
The observability layer
The team that runs three clouds has three observability stacks by default (CloudWatch, Cloud Monitoring, Azure Monitor). The right answer is a unified observability layer:
- Datadog or New Relic for metrics and logs across clouds.
- Grafana Cloud or Honeycomb for the open-source-friendly path.
- Sentry for application errors across clouds.
The team that has a unified observability layer sees a single dashboard for the entire fleet. The team that uses three separate stacks has three dashboards and three on-call rotations.
The identity layer
The hardest part of multi-cloud is identity. The team that uses AWS IAM has a different identity model from the team that uses GCP IAM. The right answer is a unified identity layer:
- Auth0 or Okta for user identity across clouds.
- Workload identity federation for service-to-service auth (AWS IAM Roles Anywhere, GCP Workload Identity, Azure Managed Identity).
The team that picks a unified identity layer has the same users, the same roles, and the same permissions across clouds.
The data layer
The hardest part of multi-cloud is data. The team’s data on AWS is not directly accessible from GCP. The right patterns:
- Replicate the data. Use a cross-cloud replication tool (DMS, Striim, or a custom pipeline).
- Use a multi-cloud data warehouse. Snowflake, BigQuery Omni, or Databricks.
- Avoid cross-cloud data flows. The team that processes data on the cloud where the data lives has the simplest architecture.
The team that moves data across clouds for every transaction has a latency and cost problem.
The Terraform state management
The right way to manage Terraform state across multiple clouds:
- Remote state per cloud. S3 for AWS, GCS for GCP, Azure Blob Storage for Azure. The team that uses remote state has shared, durable state storage.
- State locking. S3 with DynamoDB, GCS with locking, Azure Blob with leases. The team that locks state prevents concurrent
terraform applyfrom corrupting state. - Workspace per environment. dev, staging, prod in separate state files. The team that uses workspaces has isolated environments.
- Module reuse. One VPC module, one database module, one cluster module. Reused across AWS, GCP, Azure with provider-specific configuration.
The team that uses remote state with locking and workspaces has clean Terraform workflows. The team that uses local state has a debugging nightmare when state files get out of sync.
The cost allocation challenge
Multi-cloud makes cost allocation harder:
- Tagging consistency. AWS uses tags; GCP uses labels; Azure uses tags with different rules. The team that wants consistent tagging uses a tag policy that enforces the same tags everywhere.
- Cross-cloud data transfer. Data transferred between clouds is expensive ($0.02-$0.09/GB). The team that minimizes cross-cloud data transfer has lower bills.
- Showback vs chargeback. Showback is reporting cost per team; chargeback is billing teams. The team that implements showback first, chargeback later, has a smoother rollout.
The team that uses a FinOps platform (Cloudability, Vantage, Kubecost) has unified cost visibility across clouds. The team that has separate dashboards per cloud has to manually reconcile.
FAQ
Is multi-cloud worth it?
Sometimes. The team that uses GCP for BigQuery and AWS for compute has a real reason. The team that runs the same workload on two clouds for no reason is doing double the work.
What’s the best multi-cloud tool?
Terraform for infrastructure. Datadog or Grafana for observability. Auth0 or Okta for identity. No single tool does everything across clouds.
How do I avoid vendor lock-in?
You don’t, fully. The team that uses cloud-specific managed services (Lambda, BigQuery, Cosmos DB) is locked in. The team that uses Kubernetes on every cloud is less locked in, but pays an operational tax.
Should a small startup be multi-cloud?
Almost certainly not. The operational overhead is not worth it. The team that becomes multi-cloud should do so because of a specific reason, not a general philosophy.
Is multi-cloud cheaper than single-cloud?
Rarely. The operational overhead usually costs more than the savings. The team that picks multi-cloud for cost reasons is usually disappointed.
What’s the biggest multi-cloud risk?
Identity sprawl. The team that has IAM in three clouds has three identity systems to manage. A breach in one is a breach in three if the credentials are shared.
How do I avoid vendor lock-in with multi-cloud?
Use Kubernetes (EKS, GKE, AKS) for compute. Use managed Postgres (RDS, Cloud SQL, Azure Database) for databases. The team that uses these has portable workloads. The team that uses Lambda, BigQuery, or Cosmos DB is locked in.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: