Multi-cloud strategy: when and how to use more than one provider
The conversation around multi-cloud has shifted. A few years ago it was mostly theoretical - a talking point at conferences. Today, many South African businesses run workloads across two or more cloud providers out of strategic intent, acquisition history, or simple pragmatism.
But multi-cloud is not automatically better than single-cloud. It introduces real complexity that must be managed deliberately. This guide helps you decide when multi-cloud makes sense, what challenges to anticipate, and how to architect for it effectively.
What multi-cloud actually means
Multi-cloud means using two or more public cloud providers - typically some combination of Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP) - to host different workloads. It does not mean running the same workload simultaneously across providers (that is a different pattern with different trade-offs).
A common multi-cloud reality in South Africa looks something like this:
- Microsoft 365 and Azure Active Directory on Azure
- Data analytics and machine learning workloads on AWS or GCP
- Specific SaaS applications hosted on their vendors’ preferred cloud
- Legacy applications still running in a local data centre or colocation facility
This is a multi-cloud environment whether you planned it or not.
When multi-cloud makes strategic sense
Avoiding vendor lock-in
Concentrating all workloads with a single provider creates dependency. If that provider changes pricing, degrades service, or experiences a region-wide outage, your options are limited. Distributing workloads across providers gives you leverage and flexibility.
That said, true portability requires investment in abstraction layers, container orchestration, and infrastructure-as-code practices. Simply running VMs on two different clouds does not protect you from lock-in if you are deeply integrated with provider-specific services.
Best-of-breed services
No single cloud provider excels at everything. Azure integrates deeply with the Microsoft ecosystem. AWS offers the broadest range of services and the most mature infrastructure. GCP leads in data analytics and machine learning. A multi-cloud approach lets you place each workload where it runs best.
Compliance and data sovereignty
Some regulatory frameworks or client contracts require data to reside in specific geographies or on specific platforms. South African financial services firms, for example, may need to keep certain data within the country while using global cloud services for non-regulated workloads.
Mergers and acquisitions
When businesses merge, they often inherit different cloud environments. Rather than forcing a costly and risky consolidation, a managed multi-cloud approach lets you operate both environments efficiently while rationalising over time.
Resilience
While single-cloud providers offer multi-region redundancy, a catastrophic provider-level failure - however unlikely - would be an existential event for a single-cloud customer. Multi-cloud provides an additional layer of resilience for businesses with very high availability requirements.
The real challenges
Multi-cloud is not free. These are the costs and complexities you must budget for.
Operational complexity
Each cloud provider has its own management console, CLI, APIs, identity model, networking model, and pricing structure. Your team needs skills across all of them, and your operational tooling - monitoring, logging, security, deployment - must work across providers.
This is where a strong cloud architecture and engineering capability is essential. Without it, multi-cloud quickly becomes multi-chaos.
Skills and staffing
Finding engineers who are deeply proficient in even one cloud platform is challenging in the South African market. Expecting your team to maintain expertise across two or three is often unrealistic. Budget for training, certifications, and potentially external support.
Cost management
Cloud cost optimisation is difficult enough with a single provider. Across multiple providers, you need unified visibility, consistent tagging strategies, and cross-platform cost analytics. Without deliberate FinOps practices, costs spiral.
Data gravity
Data is expensive to move between clouds. Once a large dataset resides on one platform, the applications that process that data tend to follow. This creates a gravitational pull that can undermine your multi-cloud strategy. Plan your data architecture carefully - decide early where your primary data stores will live and minimise cross-cloud data transfer.
Security and identity
Maintaining a consistent security posture across providers requires unified identity management, consistent network security policies, and centralised logging and monitoring. A fragmented security model - different tools and policies per cloud - creates blind spots that attackers exploit.
Networking
Connecting workloads across cloud providers and on-premises infrastructure requires careful network engineering. Private connectivity options (Azure ExpressRoute, AWS Direct Connect), SD-WAN solutions, and consistent DNS and firewall management all add layers of complexity.
Architecture patterns for multi-cloud
Workload partitioning
The simplest and most common pattern: assign entire workloads to the cloud provider that best suits them. Your ERP runs on Azure, your data lake runs on AWS, your containerised microservices run on GCP. Each workload is optimised for its platform without requiring cross-cloud integration.
Pros: Simple to operate, each workload fully leverages provider-native services. Cons: Limited portability, potential for siloed operations.
Abstraction layer
Use Kubernetes (or a managed Kubernetes service like AKS, EKS, or GKE) as an abstraction layer that allows workloads to run on any underlying cloud. Pair this with infrastructure-as-code tools like Terraform that support multiple providers.
Pros: Greater portability, consistent deployment processes. Cons: Limits your ability to use provider-native managed services, adds operational overhead.
Active-passive failover
Run your primary workload on one cloud and maintain a standby environment on another for disaster recovery. This provides cross-provider resilience without the complexity of running production on multiple clouds simultaneously.
Pros: Strong resilience, manageable complexity. Cons: Standby environment still costs money, failover must be tested regularly.
Data mesh
Distribute data ownership across domains, each potentially on a different cloud, while maintaining governance and discoverability through a centralised data catalogue. This pattern suits large organisations with diverse data needs.
Pros: Aligns with organisational structure, enables best-of-breed data platforms. Cons: Complex governance, requires mature data management practices.
Practical guidance for South African businesses
Start with why
Do not adopt multi-cloud because it sounds modern. Start with a clear business rationale - regulatory requirement, best-of-breed need, risk mitigation, or inherited environments. If a single cloud provider meets your needs, the operational simplicity of staying with one is a genuine advantage.
Invest in your foundation
Before going multi-cloud, ensure you have:
- Infrastructure as code. Terraform, Pulumi, or a similar tool that works across providers
- Centralised identity. A single identity provider (typically Azure AD / Entra ID in South Africa) with federation to other clouds
- Unified monitoring. A platform like Datadog, Grafana, or a cloud-native SIEM that aggregates data from all environments
- Consistent tagging and cost allocation. A standard taxonomy applied across all providers
- Strong infrastructure management practices that extend across environments
Build skills deliberately
Identify which cloud skills you need based on your workload distribution. Invest in certifications and hands-on labs for your core team. For platforms where you lack depth, engage a managed services partner rather than stretching your team too thin.
Govern centrally, operate locally
Establish central governance - security policies, cost management, compliance requirements, architecture standards - that applies across all clouds. But allow individual platform teams to operate within those guardrails using provider-native tools and best practices.
Plan for connectivity
Work with your network engineering team or provider to design connectivity that is resilient, secure, and cost-effective. Avoid routing all cross-cloud traffic through the public internet - private interconnects and SD-WAN solutions provide better performance and security.
Re-evaluate regularly
Your multi-cloud strategy should evolve with your business. Reassess workload placement annually. If a provider adds a service that consolidates a workload, consider simplifying. If a new compliance requirement emerges, adjust accordingly.
When single-cloud is the better choice
Be honest about when multi-cloud is not worth the overhead:
- You have fewer than 100 users and limited IT staff
- Your workloads are predominantly Microsoft-based (M365, Dynamics, Power Platform) and Azure serves them well
- You do not have the budget for cross-cloud tooling and skills development
- Your risk appetite does not require cross-provider resilience
There is no shame in a well-executed single-cloud strategy. Simplicity has its own value.
Next steps
Whether you are managing an accidental multi-cloud environment or planning a deliberate strategy, the key is intentionality. Understand your drivers, invest in the foundational capabilities, and govern consistently.
Reach out to our team to discuss your cloud strategy. We can help you assess your current environment, define the right approach, and build the architecture and operations to support it.