Threads titled "Azure outage?" or "anyone else seeing this?" show up on the sysadmin forums with dull regularity. Some turn into confirmed incidents. Plenty turn out to be one team's misconfigured route, a flaky ISP, or nothing at all. What is consistent is not the outage. It is the reflex that follows a week later, when someone senior walks into a meeting and says we need to go multi-cloud.
Here is the unpopular consulting answer: most organizations should not buy that. Not because resilience does not matter, but because the thing being proposed is rarely the thing that would have helped.
Active-Active Multi-Cloud Is Not the Insurance You Think It Is
True active-active means every stateful component runs in two providers at once, with data replicated between them, traffic split between them, and both sides continuously proven correct. That is not a project. That is a permanent tax.
You now maintain two identity models, two networking stacks, two sets of managed service quirks, two billing surfaces, and two on-call runbooks. Your engineers become half-experts in both instead of experts in one. Every deploy has to be right twice. Cross-provider data replication is the hardest part and the part most proposals hand-wave.
The failure mode is predictable. The multi-cloud layer becomes its own source of outages, and the team ends up debugging a replication split-brain at 3 a.m. during a week when both providers were perfectly healthy.
Name Two Numbers, Out Loud, in Writing
Almost every architecture argument I get pulled into is unresolvable because nobody has written down an RTO and an RPO. Recovery time objective: how long can this be down. Recovery point objective: how much data can we lose. Until those exist as numbers with a business owner's name attached, every proposal sounds equally reasonable and the loudest voice wins.
Write them per system, not per company. Your billing database and your marketing site do not deserve the same answer. An RTO of four hours and an RPO of fifteen minutes points at a completely different, and far cheaper, design than an RTO of thirty seconds and zero data loss. The number determines the spend. Doing it the other way round, picking an architecture and then justifying it, is how teams end up paying for capability they never rehearse. This is the first conversation in any honest cloud architecture and infrastructure design engagement.
Know Your Real Blast Radius, Then Buy the Middle Ground
Map which dependencies are genuinely single-provider. Identity, DNS, object storage, and the provider's own control plane are the usual chokepoints. If your deploy pipeline cannot authenticate because the identity service is degraded, your standby region is decoration. Note that a degraded control plane often means existing workloads keep serving traffic while you simply cannot change anything, which is a very different problem from being hard down.
Three things pay for themselves before multi-cloud ever does:
- Backups your primary provider does not control. Different vendor, separate credentials, restore tested on a schedule. Highest value, lowest cost item on the entire list. The same logic applies whether you are on a hyperscaler or moving off shared hosting onto a VPS.
- A rehearsed runbook. Untested failover is a theory, not a capability. If nobody has executed it end to end in the last six months, assume it does not work.
- Detection you trust. Knowing it is the provider and not you, quickly, is most of the response. That is what round-the-clock monitoring is actually for.
For the architecture itself, most shops should target warm standby or a documented rebuild-from-infrastructure-as-code. Warm standby keeps a scaled-down copy alive and ready to take traffic. Rebuild-from-code accepts hours of downtime in exchange for near-zero standing cost, and it works only if someone has actually run the rebuild recently. Both are unglamorous. Both are affordable. Both survive contact with a bad day at your provider.
The Takeaway
Do not let a forum thread set your architecture. Pick your three most important systems this quarter, write an RTO and RPO for each, and get someone from finance to say out loud what an hour of downtime costs. Then check that your backups live somewhere your provider cannot touch, and schedule a restore test on the calendar with a name next to it.
That is the whole job: decide what downtime actually costs the business, then buy exactly that much resilience. Not more, because it is wasted. Not less, because you will find out the hard way.