Multi-Cloud: Strategy or Expensive Insurance? A Reality Check
Farah Qureshi
Principal Cloud Architect, RippleCode
"We need multi-cloud for vendor leverage and resilience" — we hear it in most cloud strategy engagements. Sometimes it's right. More often it's expensive insurance against risks that better contracts would cover. Here's the honest framework.
The costs people underestimate
Multi-cloud means two security models, two networking stacks, two sets of certifications for your team, and lowest-common-denominator architecture that avoids each cloud's best services. That last cost is the killer: you pay hyperscaler prices while using commodity features.
When multi-cloud genuinely makes sense
- Regulatory or data-residency requirements a single provider can't meet
- Acquisitions arriving with entrenched estates on another cloud
- Specific best-of-breed needs (train ML on one cloud, serve enterprise apps on another)
- Genuine concentration-risk mandates from regulators, common in financial services
What to do instead of dogmatic portability
Pick a primary cloud and go deep — managed services, native security tooling, deep team expertise. Keep portability at the edges where it's cheap: containers, Terraform, open-source data layers. Negotiate leverage through committed-use contracts, not architectural hedging.
If you must run multi-cloud
Standardize on Kubernetes and a common observability plane, unify identity, and accept that some duplication is the price of the requirement. Fund a platform team to hide the complexity — or every product team pays it individually.