Moving stateless application code between clouds is relatively straightforward — containers are portable, Kubernetes manifests are largely portable, and compute is fungible. The hard problem in multi-cloud is always data.
Data Gravity
Data Gravity is the concept that as data accumulates, it becomes increasingly difficult and expensive to move. Applications and services are pulled toward where the data lives, not the other way around. The more data you have in one place, the more services you build around it, and the more those services depend on low-latency access to that data.
Consider a concrete example: you have 5 petabytes (PB) of customer photos stored in AWS S3. Your image processing pipelines, your CDN configuration, your analytics jobs, and your backup systems all run in AWS because that's where the data is.
Moving 5 PB to another cloud:
- At a sustained 10 Gbps connection, takes approximately 11 days of continuous transfer
- Costs roughly $150,000 in AWS egress fees alone (at ~$0.09/GB for the first 10 TB, scaling down for volume — but 5 PB is still enormous)
- Requires rebuilding every downstream service that reads from that data
This is data gravity in action. The data doesn't move; everything else orbits it.
Egress Fees: The Hidden Tax on Multi-Cloud
Egress fees are charges cloud providers levy for data leaving their network. Ingress (data coming in) is typically free. Egress is not.
| Provider | Egress to Internet (first 10 TB/month) |
|---|---|
| AWS | ~$0.09/GB |
| Azure | ~$0.087/GB |
| GCP | ~$0.08/GB |
In a multi-cloud architecture where services on AWS regularly call services on GCP, you pay egress fees on every cross-cloud API call. For high-throughput systems, this can easily exceed the cost of the compute itself.
The Exit Strategy Illusion
Many regulators — particularly in financial services and healthcare — require organizations to maintain a documented "Cloud Exit Strategy": a plan for leaving a cloud provider if they become unavailable, insolvent, or non-compliant.
Because of data gravity and egress costs, a realistic exit strategy almost never looks like "fail over to Azure in 15 minutes." A realistic exit strategy looks like:
- Tier 1 (Stateless compute): Can be redeployed to another cloud in 2–4 hours using existing container images and Terraform modules.
- Tier 2 (Managed databases): Can be restored from cross-cloud backups in 4–8 hours, with some data loss window.
- Tier 3 (Large object storage): Can be rebuilt from replicated backups in 2–3 weeks, with significant operational effort.
Documenting this honestly — rather than claiming "we can fail over instantly" — is what regulators and auditors actually want to see. A credible, tiered exit strategy with realistic RTOs (Recovery Time Objectives) is more valuable than an aspirational claim of instant portability.
True active-active multi-cloud capability, where live traffic and data are simultaneously served from two providers with automatic failover, is achievable but requires enormous ongoing investment. Very few organizations outside of the largest internet companies actually operate this way.
A common interview question for senior platform roles is: "How would you design a cloud exit strategy?" Weak answers describe instant failover. Strong answers acknowledge data gravity, tier the workloads by migration complexity, assign realistic RTOs to each tier, and explain that the goal is a credible, documented plan — not a marketing claim. Mention egress fees as a concrete cost factor to demonstrate you understand the economics.