Definitions
"Don't put all your eggs in one basket" sounds like solid cloud strategy advice. But multi-cloud introduces significant complexity, and the benefits are often overstated. The right choice depends on your specific situation, not on what the industry analysts are recommending this quarter.
Single cloud
All cloud workloads run on one provider (AWS, Azure, or Google Cloud). You go deep on that provider's services, build expertise in their specific tools, and get the best possible volume discounts.
Multi-cloud
Workloads spread across multiple cloud providers. This might be active-active (the same application running on both) or partitioned (different applications on different clouds). The important distinction: this is a deliberate architectural choice, not just "different teams picked different providers."
Hybrid cloud
A combination of cloud and on-premise infrastructure, connected and orchestrated together. For many organisations, this is the realistic starting point, especially during migration when some workloads are still on-premise.
"Multi-cloud by accident", where different teams independently chose different providers, is common. But it's not strategic multi-cloud. It's usually just uncoordinated procurement, and it creates all the costs of multi-cloud without most of the benefits.
Single cloud benefits
Simplicity
One set of tools. One security model. One billing relationship. One set of skills to develop across the team. The operational overhead of managing a single cloud environment is meaningfully lower than managing two or three.
Deeper integration
Native services from the same provider work well together, because they're designed to. Managed databases talk to managed compute, which talks to managed storage, with built-in IAM, monitoring, and logging tying it together. Cross-provider integrations are always clunkier.
Cost efficiency
Committed use discounts (AWS Reserved Instances, Azure Reserved Capacity) are more effective when your entire spend is with one provider. There are no cross-cloud data egress costs. Optimisation is simpler because everything is in one place.
Skills focus
Your team develops deep expertise in one platform rather than spreading thin across several. Hiring is simpler when you're looking for one flavour of cloud skills rather than three. And deep knowledge of one provider almost always delivers more value than surface-level knowledge of all of them.
Multi-cloud benefits
Vendor flexibility
Less dependency on a single provider. In theory, this gives you negotiating power and the ability to move workloads if pricing or service quality changes.
Best of breed
Use each provider's genuine strengths. Google Cloud for ML/AI. AWS for breadth and mature services. Azure for deep Microsoft ecosystem integration. Put workloads where they fit best.
Resilience
Protection against provider-wide outages or business disruption. If one provider has a major incident, workloads on the other continue running. In practice, provider-wide outages are extremely rare. Single-region outages are more common and are handled by multi-region within the same provider.
Compliance
Some regulations or major customers require specific providers. Government work in Australia may mandate certain clouds. If your customer says "Azure only," that's a business requirement, not a technical preference.
Multi-cloud challenges
The pitch for multi-cloud sounds good. The reality is more complicated.
The reality check: Multi-cloud doesn't eliminate lock-in. It creates multiple lock-ins. True portability requires lowest-common-denominator architecture. Skills and tooling complexity increases substantially. And cross-cloud data movement is expensive and slow.
Complexity
Different security models, different networking constructs, different identity systems, different tooling. Your team now needs expertise in multiple platforms. Governance gets harder. Incident response gets harder. Everything gets a bit harder.
Cost
Data egress between clouds is surprisingly expensive. Volume discounts are diluted when spend is split. Management overhead goes up. In our experience, true multi-cloud deployments generally cost more than single-cloud, not less.
Lowest common denominator
To make applications genuinely portable, you can only use features available on all providers. That means giving up each provider's best managed services, which are usually the reason you chose cloud in the first place.
Side-by-side comparison
| Factor | Single cloud | Multi-cloud |
|---|---|---|
| Complexity | Lower | Higher |
| Native features | Full access | Limited for portability |
| Cost efficiency | Better volume discounts | Diluted, plus egress fees |
| Vendor risk | Single dependency | Distributed |
| Best of breed | One provider's strengths | Multiple provider strengths |
| Skills needed | Deep, focused | Broad, shallower |
| Operational overhead | Lower | Significantly higher |
When multi-cloud makes sense
There are legitimate scenarios where multi-cloud is the right call:
- Acquisitions. You've acquired companies already on different providers. Standardising is expensive and risky; multi-cloud is just reality.
- Genuinely differentiated capabilities. One provider has something you can't replicate on another. Google's BigQuery for data warehousing, Azure's Active Directory integration, AWS's breadth of managed services.
- Regulatory mandates. Compliance requires specific providers for certain data or workloads.
- Customer requirements. A major customer contractually requires a specific cloud.
- Extreme resilience. You need cross-provider disaster recovery for genuinely critical systems.
Practical guidance
For most mid-market Australian businesses, the pragmatic path looks like this:
- Choose a primary cloud based on your actual needs, existing investments, and team skills. Don't overthink this. AWS, Azure, and GCP are all excellent.
- Maximise native services on your primary cloud. Don't artificially constrain yourself to portable-only services. Use the managed databases, the serverless compute, the native monitoring. That's where the value is.
- Use a second cloud only when there's specific justification. A customer requirement. A genuinely superior service for a specific workload. Not "because multi-cloud is best practice."
- Containerise where portability genuinely matters. Kubernetes gives you meaningful portability for the workloads that actually need it, without forcing everything through that abstraction layer.
Don't solve problems you don't have. Most organisations will never switch cloud providers. The cost of building everything for theoretical portability often exceeds the cost of an actual migration, if one ever happens.
Frequently asked questions
Isn't vendor lock-in dangerous?
It's a risk, but it's often overstated. Cloud providers compete aggressively on pricing and features. Switching costs are real but finite. The bigger risk for most organisations is under-investing in cloud, using only the lowest-common-denominator services to maintain theoretical portability, and missing out on the managed services that deliver the actual value.
Should we use Kubernetes for portability?
Kubernetes gives you container portability, but that's only one layer. Your application still uses databases, storage, messaging, identity, and dozens of other services. Kubernetes doesn't make those portable. Use it because it's the right tool for your deployment needs, not as a portability strategy.
What does HELLO PEOPLE recommend?
We standardise on AWS. It has the broadest service portfolio, the most mature infrastructure in the Sydney region, and the deepest integration with our AI and data platform work. For specific client requirements, we work with Azure and GCP, but we don't recommend multi-cloud for its own sake.
Key takeaways
- Multi-cloud isn't inherently better than single cloud. It's a trade-off between flexibility and simplicity.
- Single cloud offers lower complexity, deeper integration, better volume discounts, and focused team expertise.
- Multi-cloud introduces multiple lock-ins, diluted discounts, and cross-cloud data egress costs.
- For most organisations, a primary cloud with selective use of others is the pragmatic choice.
