Multi-cloud makes sense when a specific requirement forces it: a regulator or customer that demands a particular provider or provider independence, a service on another cloud that is clearly better for one workload, or an acquisition that arrived with a second cloud. It rarely makes sense as general insurance against lock-in or outages, because running the same system on two providers multiplies platform work while the failover it promises is hard to make real. If you do run more than one cloud, split by workload, standardize identity, infrastructure as code, CI/CD and observability across providers, and keep chatty traffic inside one cloud.
Key takeaways
- Name the requirement before the architecture. "Avoid lock-in" is not a requirement; "customer X needs us deployed in Azure" is.
- Workload segmentation (each system on the cloud that suits it) is the multi-cloud pattern that most often works. Active-active across providers is the one that most often disappoints.
- Every additional cloud adds a landing zone, an identity model, a network, a security toolchain and on-call knowledge. Budget for it explicitly.
- Federate identity between clouds with short-lived credentials. Long-lived keys copied between providers are the most common multi-cloud security failure.
- Egress charges and latency make cross-cloud chatter expensive. Move data in batches or event streams, not request by request.
- For most teams, multiple regions in one cloud plus a tested exit plan beats two clouds.
What counts as multi-cloud
Terms first, because much of the debate comes from people meaning different things:
| Setup | What it means | Is it "multi-cloud"? |
|---|---|---|
| Several SaaS vendors | Email on one vendor, CRM on another, code hosting on a third | No. Everyone does this; it needs vendor management, not architecture |
| Workload segmentation | Each system runs on one cloud, different systems on different clouds | Yes, the most common working form |
| Hybrid | Public cloud plus your own data centers | Related; the same identity and network problems |
| Cross-cloud DR | Primary on one provider, recovery environment on another | Yes, and expensive to keep honest |
| Active-active across providers | The same system serving traffic from two providers at once | Yes, and rarely worth it |
Good reasons and weak reasons
| Reason | Verdict | What to check |
|---|---|---|
| Customer requires deployment in its cloud or marketplace | Good | Whether the requirement covers the whole product or one component you can package separately |
| Regulator or contract requires provider independence | Good, read the text closely | Many rules require a tested exit strategy and concentration-risk management, not active use of two providers. The EU's DORA for financial entities is an example |
| One service is clearly better on another cloud | Good, for that workload | Whether data movement to that service is cheap and infrequent enough |
| Acquisition brought a second cloud | Real, often temporary | Whether consolidation is cheaper than operating both long term |
| Avoiding lock-in | Weak | Lock-in lives in data, managed services and skills. Two clouds give you two lock-ins |
| Surviving a provider outage | Weak for most | Multi-region on one provider covers most failure modes at a fraction of the effort |
| Negotiation leverage | Weak | Leverage needs credible migration ability, which an exit plan provides more cheaply |
What each additional cloud costs you
Before deciding, list what you will build and run twice. This is the part vendor slides leave out.
- Landing zone: account or subscription or project structure, guardrail policies, logging and audit pipeline.
- Identity: role model, workload identity, break-glass access, access reviews.
- Network: address plan, connectivity, DNS, firewalls, private endpoints.
- Security tooling: posture management, threat detection, vulnerability scanning, key management.
- Delivery: pipelines, artifact registries, deployment credentials, environment promotion.
- Operations: monitoring, alerting, runbooks, and people on call who can debug the second cloud at three in the morning.
- Compliance evidence: every control proven for each provider.
- Commercial: split spend means smaller commitments on each provider and less discount leverage on both.
If the requirement does not clearly outweigh that list, stay on one cloud.
Patterns that work
| Pattern | How it works | When it fits | The hard part |
|---|---|---|---|
| Workload segmentation | Each system lives on one cloud; systems integrate through APIs or events | Most real multi-cloud estates | Clear placement rules so teams do not pick a cloud by habit |
| Analytics on another cloud | Operational data stays put; batched exports feed a warehouse elsewhere | One provider's analytics or AI service is a better fit | Egress volume and the freshness the business actually needs |
| Edge and origin split | A CDN, WAF and DNS layer from one vendor in front of origins on a cloud | Almost everyone; it is the cheapest form of provider diversity | Origin protection so traffic cannot bypass the edge |
| Deploy into the customer's cloud | The product is packaged to run in the customer's account or tenant | B2B products with data residency or security buyers | Supporting software you do not fully control the runtime of |
| Cross-cloud disaster recovery | Data replicated to a second provider with a recovery environment ready to build | A regulator or contract requires provider independence for recovery | Keeping the recovery path tested as the primary changes every week |
Cross-cloud disaster recovery deserves a warning. It is the pattern people choose for resilience and the one most likely to fail when needed, because the recovery environment drifts from the primary between tests. If you go this way, apply the same discipline as any disaster recovery tier: defined recovery objectives, automated rebuilds, and scheduled failover tests that actually move traffic.
Standardize the layers that cross clouds
The rule is simple: standardize the layers that people and pipelines touch every day, and let each cloud's infrastructure be native underneath.
Identity: one source of truth, short-lived credentials
People should sign in through one identity provider, federated into every cloud. Machines should never hold long-lived keys for another cloud. Every major provider can trust tokens issued by the others.
Here is an AWS workload, running under an IAM role, getting access to Google Cloud through Workload Identity Federation with no service account key:
gcloud iam workload-identity-pools create aws-pool \
--location=global \
--display-name="AWS workloads"
gcloud iam workload-identity-pools providers create-aws aws-prod \
--location=global \
--workload-identity-pool=aws-pool \
--account-id=123456789012
gcloud iam service-accounts add-iam-policy-binding \
analytics-loader@my-project.iam.gserviceaccount.com \
--role=roles/iam.workloadIdentityUser \
--member="principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/aws-pool/attribute.aws_role/arn:aws:sts::123456789012:assumed-role/analytics-exporter"
gcloud iam workload-identity-pools create-cred-config \
projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/aws-pool/providers/aws-prod \
--service-account=analytics-loader@my-project.iam.gserviceaccount.com \
--aws \
--output-file=gcp-credentials.jsonThe generated file contains no secret. The Google client libraries read it (via GOOGLE_APPLICATION_CREDENTIALS), sign a request with the AWS role's own credentials, and exchange it for a short-lived Google token. The same idea works in the other directions with AWS IAM OIDC providers and Azure federated credentials. Our cloud IAM guide maps the identity concepts across all three providers.
Infrastructure as code: one tool, native modules
Use one IaC tool across clouds (Terraform or OpenTofu are the common choice) with providers and modules written natively for each cloud. Do not build a "cloud-agnostic" module that hides the differences; it ends up exposing the lowest common denominator and leaking every difference anyway.
infra/
modules/
aws/ network, eks-cluster, rds-postgres
gcp/ network, bigquery-dataset, gke-cluster
live/
aws/prod/ one state per environment and cloud
gcp/prod/
policies/ shared policy checks run in CI against every planDelivery: one pipeline platform, federated deploy credentials
One CI/CD system deploying to every cloud through OIDC federation, with the same promotion rules and the same approval gates. Teams should not need to learn a second delivery process to ship to the second cloud.
Observability: one backend, open instrumentation
Instrument with OpenTelemetry and send everything to one backend, so an engineer following a request across clouds uses one query language and one trace view. Provider-native tools still matter for provider-level signals (service health, quota and billing events), so forward those into the same place.
Posture and cost
Run security posture checks and cost allocation across all providers with the same rules and the same reporting. Our guides to cloud security posture management and FinOps cover both; the FOCUS billing format lets one cost pipeline read every provider's bill.
Networking and data transfer
Cross-cloud networking is where the costs and the outages hide.
Plan addresses first. Allocate non-overlapping IP ranges for every VPC and VNet across all clouds and on-premises networks before connecting anything. Overlaps found later mean NAT workarounds or rebuilding networks.
Connect in steps. Site-to-site IPsec VPN between provider gateways is quick to set up and fine for modest, non-latency-sensitive traffic. For steady high-volume traffic, use dedicated interconnects (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect) meeting in a colocation facility or through a network-as-a-service provider; Google's Cross-Cloud Interconnect provides managed links from Google Cloud to other providers.
Respect egress economics. Data leaving a provider is billed per gigabyte, and cross-cloud traffic pays it on every request. Design so that request-time calls stay inside one cloud, and data crosses providers asynchronously: event streams, batched exports, replicated snapshots. The difference between "export changed rows hourly" and "query the other cloud per request" shows up in both the latency graph and the bill.
Know the exit rules. All three major providers now waive egress charges for customers moving their data off the platform when they leave, under conditions you must request and meet. In the EU, the Data Act, which has applied since September 2025, phases out switching charges and allows only cost-based egress charges when customers use several providers in parallel. Neither makes day-to-day cross-cloud traffic free.
Decide placement on paper
Without written placement rules, teams pick a cloud by habit and the estate drifts into accidental multi-cloud. A short decision record per workload keeps it deliberate:
workload: fraud-scoring
placement: gcp
reason: model training and serving use a managed ML platform the team already operates there
data_in: transaction events streamed from aws, batched every 5 minutes
data_out: risk scores published back to aws event bus
egress_estimate_reviewed: true
identity: aws role federated to gcp service account, no keys
exit_plan: model artifacts and features exported nightly to object storage in aws
owner: risk-platform
review_date: 2027-04-01What goes wrong in production
Failover that exists only on the diagram. The second cloud's environment was built once, tested once, and has drifted with every change since. Secrets, feature flags, DNS records and data replication lag break the failover nobody rehearsed. If you cannot run the failover on a Tuesday afternoon, it will not work during an incident.
Keys copied between clouds. A service account key for one cloud stored as a secret in another, never rotated, with broad permissions. This is the multi-cloud credential leak waiting to happen. Federate instead.
The egress surprise. A pipeline that copies raw data across providers daily, or a service that calls a database in another cloud per request. The bill arrives a month later. Review every cross-cloud data flow for volume before it ships.
Lowest common denominator. To stay portable, teams self-manage databases, queues and search clusters instead of using managed services, and pay for it in operational load and incidents. Portability you never use is pure cost.
The second cloud nobody can debug. On-call engineers are fluent in the primary provider and lost in the secondary one. Incidents there take longer every time. Either staff and train for both, or keep the second cloud's footprint small and simple.
Single points that were not counted. Two clouds, but one DNS provider, one identity provider, one CI system and one secrets store. Those may be good choices; just name them, protect them, and stop claiming the system has no single provider dependency.
When to stay on one cloud
If you have no customer, regulatory or clear workload-fit requirement, one cloud is the better strategy. You go deep on one platform, use managed services freely, concentrate commitments for better rates and keep one operational model. Get resilience from multiple Availability Zones and, where the business case exists, multiple regions. Manage lock-in with an exit plan: know how you would export your data, which services you would need to replace, and test the data export once a year.
Frequently Asked Questions
What is the difference between multi-cloud and hybrid cloud?
Multi-cloud means running production workloads on two or more public cloud providers. Hybrid cloud means combining a public cloud with your own data centers or private infrastructure. Many organizations are both, and the engineering problems of identity, networking and observability across environments are largely the same.
Does multi-cloud improve availability?
Only if you build and regularly test real failover between providers, including data replication, DNS and secrets, which is expensive and rarely done well. For most systems, running across multiple zones and regions of one provider delivers more availability per unit of effort. Multi-cloud by itself mostly adds more things that can fail.
Does multi-cloud prevent vendor lock-in?
Not by itself. Lock-in lives in your data, your use of managed services and your team's skills, and running two clouds just gives you two sets of each. A documented and tested exit plan for each critical system reduces lock-in risk more cheaply than running everything twice.
Is Kubernetes enough to make an application cloud-agnostic?
No. Kubernetes gives you a consistent way to deploy and run containers, but storage classes, load balancers, identity, networking and every managed service around the cluster still differ by provider. It makes moving the compute layer easier, not the whole system.
How do you connect AWS, Azure and GCP privately?
Start with site-to-site IPsec VPNs between the providers' VPN gateways. For higher bandwidth and steadier latency, use dedicated interconnects that meet in a colocation facility, a network-as-a-service provider, or Google's Cross-Cloud Interconnect. Plan non-overlapping IP ranges across all clouds before you connect anything.
When should a startup consider multi-cloud?
Rarely before there is a concrete requirement, such as a large customer that requires deployment in its own cloud or a regulator that demands it. Early on, the extra platform work slows product delivery more than any lock-in risk justifies. Keep a clean exit plan instead and revisit when a requirement appears.
Need help deciding on multi-cloud?
We help teams decide whether a second cloud is worth it, and when it is, we build the identity, network and delivery layers so it stays operable. If we build it, we are on the pager for it, so we design for the incident at three in the morning, not the architecture review.