What is multi-cloud deployment?
Plain-English definition, real use cases, honest trade-offs, and the tooling that makes it economical. The glossary entry we wish existed when we started building vxcloud.
The one-sentence definition
Multi-cloud deployment is running an application across two or more public cloud providers simultaneously — by intent, not by accident.
That last clause matters. Most companies are accidentally multi-cloud (the marketing team uses one SaaS that runs on AWS, the data team uses another that runs on GCP, the website is on Vercel which is also AWS). That isn't a multi-cloud strategy — that's vendor sprawl. A multi-cloud deployment is when you deliberately design an application to run on more than one cloud, with the supporting infrastructure (identities, networking, observability, deployment pipelines) to make that operationally tractable.
The spectrum is wide. On the small end, "multi-cloud" might mean one production cloud plus a warm-standby DR copy in a second cloud. On the large end, it might mean a globally distributed application where every region picks the best-priced cloud and customer requests route to the nearest one. Both are valid; both fit the definition.
How a multi-cloud deployment actually works in practice
Three architectures cover almost every real multi-cloud deployment we've seen.
- Active-passive (DR pattern). Primary application runs on Cloud A. A continuously updated copy runs on Cloud B in standby mode. Database replication is the hardest part — usually via logical replication or a cross-cloud streaming pipeline. On failover, DNS shifts to Cloud B. Used by: financial services, healthcare, anyone with regulatory recovery-time objectives.
- Component split. Different parts of the application run on whichever cloud is best for that component. E.g. core API on AWS (best general-purpose compute), ML inference on GCP (best TPUs / cheaper GPU spot), edge servers on Linode or Cloudflare (cheapest global egress). Glue is service mesh or async messaging across clouds. Used by: AI startups, latency-sensitive B2C apps.
- Active-active geographic. Same application runs on multiple clouds in different geographies, with traffic routed by DNS or anycast to the nearest. Data sync is eventual via a global database (CockroachDB, Spanner, YugaByte) or partitioned by region. Used by: global SaaS, gaming, content distribution.
Real reasons to deploy multi-cloud
- Vendor leverage: prove that any one cloud's pricing is contestable. Multi-cloud changes how your AWS rep treats your renewal.
- Compliance: GDPR pushes EU data residency; China cybersecurity law pushes Alibaba for in-country data. Both at once requires multi-cloud.
- Disaster recovery: a regional AWS outage is unlikely; an AWS-wide outage has happened. DR in a different provider survives both.
- Cost arbitrage: GPU spot pricing varies 3-5× across clouds in any given week. AI workloads benefit hugely from being movable.
- M&A: the acquired company runs on Azure; yours on AWS. Migration is a year of work — multi-cloud is a Tuesday afternoon.
- Talent: hiring engineers who know GCP is easier in some markets than hiring AWS engineers. Letting teams pick lets you hire faster.
- Sovereign cloud requirements: certain government contracts require provider diversification by policy.
The honest downsides
Multi-cloud is not free. Pretending it is gets teams in trouble around year two when the operational tax compounds.
Specifically, the costs that surprise teams: (1) egress — moving data between clouds is one of the most expensive operations in cloud computing, and your architecture either minimizes inter-cloud chatter or pays for it forever. (2) Identity sprawl — AWS IAM, GCP IAM, Azure AD, and Alibaba RAM are four different systems that need to stay in sync. (3) Observability fragmentation — CloudWatch + Stackdriver + Application Insights + Alibaba CloudMonitor is four dashboards; teams either consolidate via OpenTelemetry early or drown in them. (4) Per-cloud expertise — the engineer who knows EKS deeply does not automatically know GKE.
The tooling that makes multi-cloud tractable
The platform layer is the difference between a working multi-cloud strategy and a slow rollback to single-cloud.
- Infrastructure as Code: Terraform (or Pulumi / Crossplane). Universal abstraction over per-cloud APIs. Mandatory for multi-cloud at scale.
- A multi-cloud control plane: vxcloud, env0, Spacelift, or similar — handles credential storage, RBAC across clouds, and policy enforcement uniformly.
- OpenTelemetry: single observability standard across all clouds, instead of per-cloud monitoring stacks.
- Cross-cloud service mesh (optional): Istio, Linkerd, or Consul Connect for components that cross provider boundaries.
- A unified deploy pipeline: one CI/CD that targets all clouds with the same script. vxcloud's `vxcli deploy` is one example; others build this on Argo CD or Spinnaker.
- Logical-replication-capable database (for DR): Postgres logical replication, CockroachDB, or AWS DMS for cross-cloud data flow.
A worked example: same app, five clouds
What a multi-cloud deploy actually looks like with vxcloud's CLI.
# One application, five clouds. Same flag set, different --cloud + --region.
for cloud_region in "aws:us-east-1" "gcp:us-central1" "azure:eastus" \
"alibaba:ap-southeast-1" "linode:us-east"; do
cloud="${cloud_region%%:*}"
region="${cloud_region##*:}"
vxcli vm create \
--name api-vm-${cloud} \
--cloud "${cloud}" \
--region "${region}" \
--instance-type t3.small \
--key-pair-name PRODKEY
done
# Provision matching managed Postgres in each cloud (for active-active geo)
vxcli cloud database create-rds api-db --cloud aws --region us-east-1 --engine postgres --version 16
vxcli cloud database create-rds api-db --cloud gcp --region us-central1 --engine postgres --version 16
vxcli cloud database create-rds api-db --cloud azure --region eastus --engine postgres --version 16
# Deploy the same FastAPI app to each VM
for cloud in aws gcp azure alibaba linode; do
vxcli deploy fastapi --source-dir ./ \
--app-name api --entry app:app \
--enable-ssl --domain api-${cloud}.example.com --ssl-email [email protected] \
--host "$(vxcli vm get api-vm-${cloud} --json | jq -r .public_ip)" \
--ssh-user ubuntu --key-pair-name PRODKEY
doneMulti-cloud FAQ
Multi-cloud is a tooling problem. We built the tooling.
vxcloud is the platform layer that makes multi-cloud deployment economical for teams under 50 engineers.