Multi-cloud: reasons, challenges, portability and consistent security
In short: Multi-cloud means using two or more public cloud providers. It can offer the best service for each job and reduce dependence on one vendor, but it multiplies skills, tools and configurations. Security stays consistent only when identity, infrastructure code, posture checks and logging are shared across all clouds.
Why organisations go multi-cloud
Multi-cloud is often accidental rather than planned. One team picks Azure because the company uses Microsoft 365, another picks Google Cloud for analytics, and an acquired company arrives running on AWS. Some organisations choose it on purpose:
- To use a specific service that is strongest on one provider.
- To reduce dependence on one vendor and strengthen negotiating position.
- To meet customer or regulatory demands in particular countries.
- To keep an exit plan, which some financial regulators expect for critical services.
Multi-cloud is not automatically more resilient. Running one application across two providers in active-active mode is hard and expensive. Most resilience needs are met well by multiple zones and regions in one provider (see HA and DR).
Portability: how much is realistic?
| Approach | Portability | Trade-off |
|---|---|---|
| Native managed services | Low | Fast to build, rich features, more lock-in |
| Containers on managed Kubernetes | Medium to high | Workloads move more easily; data and networking still differ |
| Open-source databases and messaging | Medium | You may operate more yourself |
| Infrastructure as code (Terraform, OpenTofu) | One tool, but provider-specific resources | Same workflow, different modules per cloud |
Data is usually the hardest thing to move, because of volume, egress charges and differences between database services. Design exit plans around the data, not just the compute.
Keeping security consistent
- Identity: use one corporate identity provider and federate into each cloud with SSO and roles; avoid separate local admin accounts.
- Baseline: write one security standard, then map it to each provider's controls, for example using the CIS Benchmarks for each cloud.
- Code: deploy through pipelines with reusable, reviewed modules and policy-as-code checks.
- Posture: use a CSPM or CNAPP tool that covers all your clouds, so findings appear in one list.
- Logs: send audit logs from every provider to one SIEM, with the same alerting standards.
- People: train staff on each platform you run; skills gaps cause misconfiguration.
Tip: the same idea, such as "storage must not be public", is enforced differently on each cloud (S3 Block Public Access, Azure storage settings, Google Cloud public access prevention). Keep a mapping table so nothing is missed.
Deciding whether multi-cloud is right for you
- Write down the actual reason: a specific service, a regulation, resilience, or a merger.
- Estimate the extra cost of skills, tooling and duplicated landing zones.
- Decide what must be portable and what can stay provider-specific.
- Agree one identity provider, one logging destination and one policy baseline across clouds.
- Review the decision every year; many teams find one primary cloud plus a second for specific needs is enough.
Practice
Does using two cloud providers automatically improve availability?
What is usually the hardest part of moving between clouds?
Name two ways to keep identity consistent across clouds.
Key takeaways
- Multi-cloud means two or more public providers, often by accident.
- Benefits include choice and less lock-in; costs include complexity.
- Portability is limited mostly by data and native services.
- Use one identity provider, shared IaC, cross-cloud CSPM and one SIEM.
- Map one security standard to each provider's controls.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.