"Multi-cloud" sounds like a strategy. Often it's an aspiration, sometimes a religion, occasionally a real architectural choice. The reality: multi-cloud is harder than it sounds, the benefits are smaller than promoted, and the costs are larger.
This page is the honest assessment.
Several different things, often conflated:
The hardest version. One application running on AWS and GCP simultaneously, capable of failover or load distribution.
Workload A on AWS; workload B on GCP. Each is single-cloud; the company is multi-cloud.
Could run on any cloud, currently runs on one. Theoretical multi-cloud.
Sometimes called "multi-cloud" but isn't. AWS us-east-1 + AWS us-west-2 is multi-region.
The first is technically demanding; the others are mostly just "we use multiple clouds."
The classic argument. If AWS raises prices or has problems, having alternatives provides leverage.
The honest counter: AWS rarely raises prices for existing customers; the lock-in argument is more theoretical than empirical. The cost of multi-cloud often exceeds any reasonable benefit from leverage.
GCP's BigQuery and ML services are arguably better than AWS equivalents. Azure dominates for Microsoft-stack integrations. Different clouds have different strengths.
This is the strongest practical argument: use the best service for each job, not the same vendor for everything.
Some regulations require multi-cloud. Financial services, healthcare, government. Compliance trumps technical preference.
If AWS has a major outage, GCP keeps you running. This is theoretical for most workloads — full cloud failures are extremely rare and brief.
Each cloud has different services, IAM, networking, billing. Operating multi-cloud means knowing all of them at depth. Most teams are good at one cloud and adequate at others.
CloudFormation only does AWS. Bicep only does Azure. Terraform handles all but with provider-specific resources. Most operational tools have favorites.
Cross-cloud traffic is expensive. Egress fees from cloud A; ingress costs to cloud B (sometimes free); latency between them. Architectures that cross cloud boundaries pay this constantly.
Monitoring, logging, security, deployment all need to work in both clouds. Twice the integration work, twice the licensing if vendors charge per cloud.
Your data lives in one cloud. Moving it costs egress fees. Replicating to multiple clouds means double storage cost and ongoing replication work.
Use BigQuery for analytics on GCP; serve user traffic from AWS. The cross-cloud is for analytics, where the workload tolerates higher latency.
Acquired company runs on Azure; primary infrastructure on AWS. Migrating costs more than coexisting.
EU operations on EU clouds; US operations on US clouds.
For ultra-critical workloads, DR in a different cloud. The complexity cost is real but the resilience benefit is real for the right workloads.
Designing every component to abstract over cloud differences. The abstractions are leaky; the cost is large; the portability rarely gets exercised.
Better: pick one cloud; build well; reconsider only if a specific reason emerges.
The companies that have actually switched primary clouds report years of work. The promise of easy portability is largely fiction.
Kubernetes APIs are similar across providers but the surrounding infrastructure (load balancers, storage, identity, etc.) is provider-specific. Full portability doesn't materialize.
Container images run anywhere. The application is portable; the surrounding infrastructure (load balancer, secrets, logging) is per-cloud but commodity.
Single tool; per-cloud modules. Doesn't make code portable but makes infrastructure code consistent across clouds.
Object storage: S3, GCS, Azure Blob are similar. A small abstraction layer hides differences.
Databases: PostgreSQL is PostgreSQL. RDS, Cloud SQL, Azure Database for PostgreSQL — all just hosted PostgreSQL.
These abstractions are cheap; use them.
Don't abstract away DynamoDB to "any key-value store." The abstraction loses what makes DynamoDB valuable.
For most companies:
For specific cases multi-cloud earns its place. For most companies, it's overhead pretending to be strategy.