Multi-Cloud Architecture: The Patterns That Work, and the One That Does Not

Multi-cloud is usually justified by two arguments: avoiding lock-in and improving resilience. Both are real concerns. Neither is well served by the pattern most teams attempt.

The pattern that usually does not work

Running the same application actively across two providers.

The intention is that if one provider fails, the other carries the load. The reality is that you now have:

• Two networking models to design, secure and debug.
• Two IAM systems with different semantics.
• Two sets of operational tooling and two sets of expertise to maintain.
• Data consistency across providers, with egress charges on every byte of replication.
• A lowest-common-denominator architecture, because you can only use services both offer.
• Twice the surface area for configuration mistakes.

The added complexity frequently causes more downtime than the provider outages it was meant to survive. Complexity is itself a failure mode, and it is the one you experience weekly rather than yearly.

This pattern is justified when a regulator or a major customer contractually requires it. It is rarely justified on engineering grounds alone.

The patterns that do work

1. Best-of-breed by capability. Run each component where it is genuinely best or cheapest. Compute and application servers on a cost-effective provider, object storage and CDN wherever the economics are best, and one specific managed service — a data warehouse, a managed Kafka, a particular ML platform — on the hyperscaler that does it well.

This works because the components are loosely coupled by nature. It is how most successful "multi-cloud" estates actually look, and it is closer to sensible purchasing than to distributed architecture.

2. Separate workloads on separate providers. Production on one, development and CI on another. Build farms are cost-dominated and entirely portable, which makes a Hetzner account an obvious home for them regardless of where production lives. There is no cross-provider coupling to manage.

3. Data residency partitioning. EU customers served from an EU provider, US customers from a US one. Each region is independent. This is multi-region with different vendors rather than a distributed system, and it satisfies requirements a single provider may not.

4. Warm standby, not active-active. Primary on one provider, infrastructure code and regular data replication to a second, brought up only in a disaster. Cheaper and far simpler than active-active, with a recovery time measured in hours rather than seconds — which is acceptable for most businesses if stated honestly.

Keeping options open without paying twice

Most of the benefit people want from multi-cloud comes from portability, which you can have without running anything twice:

• Use portable primitives. Containers, PostgreSQL, S3-compatible object storage and standard Kubernetes run everywhere. These are the components with genuine portability.
• Adopt managed services deliberately. A managed service is a real productivity gain and a real dependency. Choose it knowing which it is.
• Keep infrastructure as code. Even provider-specific Terraform is far easier to port than an environment configured by hand.
• Avoid proprietary glue in business logic. Provider-specific event and workflow services are the hardest things to unpick. Keep domain logic in your own code.
• Externalise configuration. Anything hard-coded to one provider's endpoints becomes an obstacle.

This gives you a realistic exit: a migration measured in weeks rather than years, without paying a portability tax every day for an option you may never exercise.

Being honest about lock-in

Some lock-in is worth accepting. A managed database that removes an operational burden is a good trade even though it is harder to leave. A serverless workflow engine that saves months of development may be worth the dependency.

The distinction worth making is between lock-in you chose and lock-in you drifted into. The first is a decision with a known cost. The second is discovered during a migration.

Keep a short, written list of your hardest dependencies. Reviewing it once a year is most of the discipline required — and it is far cheaper than building portability you never use, a trade-off that also runs through the hyperscale versus VPS comparison.

Frequently asked questions

Does multi-cloud improve availability? Only if implemented well, and poor implementations reduce it. Multi-region within one provider is usually a better availability investment for the same effort.

Is Kubernetes a multi-cloud strategy? It makes the compute layer portable. Networking, storage, identity and managed data services remain provider-specific, which is where the work actually is.

How do I estimate migration cost? Inventory the provider-specific services in use. That list is the migration. Compute and storage rarely dominate the effort.

Is using two providers for different things really multi-cloud? It is the version that works. The term usually implies something more entangled and less useful.

The provider comparison sets out what each platform in the catalogue is genuinely strongest at.