Is a second cloud provider a real disaster recovery plan?
For most failures, no, because the failures that cause downtime are not provider failures. Bad deployments, deleted data, expired certificates, exhausted quotas and schema migrations account for the majority of real incidents, and a second provider protects against none of them. There is a narrow class of events where cross-provider capability is the only answer, and the plans built for it commonly fail at the same point: the recovery runbook depends on systems hosted by the provider that has gone down.
What failure are you actually protecting against?
Name it before designing anything, because the answer determines whether the mitigation is a backup, a second zone, a second region or a second provider, and the cost difference between those is large. Most disaster recovery programmes that end up spanning providers were never asked this question directly, and would have chosen differently if they had been.
| Failure | How common | Second region helps? | Second provider helps? |
|---|---|---|---|
| Bad deployment or configuration change | The most common cause of downtime | No | No |
| Data deleted or corrupted by your own code | Common | No, it replicates | No, it replicates |
| Single availability zone failure | Occasional | Not needed, zones suffice | No |
| Regional outage | Infrequent | Yes, this is the case for it | Unnecessarily expensive |
| Global control plane or identity outage | Rare | Partly, existing capacity keeps serving | Yes |
| Account suspension or billing dispute | Rare | No, it is account wide | Yes |
| Credential compromise with destructive action | Rare and severe | No, permissions span regions | Yes, if isolated |
Why is a second region usually the right answer?
Because it addresses the realistic failure at a fraction of the complexity. Within one provider you keep one identity model, one network design, one set of tooling and one body of operational knowledge, and you gain the ability to lose an entire region. Data replication between regions is a supported feature of the managed services you already use, rather than a system you have to build.
It is also testable in a way cross-provider plans rarely are. Failing over to a second region can be rehearsed with the same automation used for normal deployment, and the failure modes encountered during rehearsal are familiar ones. This matters more than the architecture, because an untested recovery plan has an unknown recovery time, and unknown recovery times are how outages become long.
The honest limitation is that a second region shares an account, an identity system and a control plane with the first. If the event you fear is one of those, region separation does not help, and that is the boundary at which the multi-cloud conversation legitimately begins. Below that boundary, spending on regions rather than providers buys more recovery capability per pound.
What makes cross-provider recovery hard?
Data, and then everything the runbook depends on. Keeping a usable copy of live data on another provider means continuous replication that you build and monitor yourself, because managed replication does not cross vendors. That path has its own failure modes, its own lag, and its own cost per gigabyte, and a stale replica discovered during an incident is worse than a known backup.
Managed services are the second obstacle. A workload that uses a provider's hosted database, queue, identity service and object store needs equivalents standing on the other side, configured, patched and tested, or it needs to have been written against portable components from the start. This is where the abstraction question and the disaster recovery question meet, and where recovery plans quietly become permanent dual estates.
The failure that actually appears in drills is circular dependency. The recovery runbook needs the CI system, the artefact registry, the secret store, the infrastructure code state, the identity provider and the paging tool, and in most organisations several of those live on the provider that is down. A recovery capability that cannot be invoked during the event it was built for is not a capability, and this is the single most common defect found the first time a cross-cloud plan is exercised.
What does a workable cross-cloud plan look like?
Cold and rehearsed, rather than warm and theoretical. For most organisations the right shape is a current copy of critical data in an open format on the second provider, the infrastructure defined as code that can build the environment there, container images published to a registry that survives the outage, and a written runbook that has been executed end to end at least once. Recovery takes hours rather than minutes, and that is usually acceptable for the events this design exists to survive.
The dependencies have to be relocated deliberately. Artefacts and infrastructure state stored somewhere independent of both providers or duplicated to the second one. Break-glass identities on the second platform that do not rely on federation through a system that may be unavailable. Paging and incident communication on a tool that is not hosted by the provider you are recovering from. Each of these is small on its own, and each has broken a real recovery.
Warm standby across providers is defensible only for a genuinely critical function with a recovery objective measured in minutes, and it should be scoped to that function rather than the estate. Even then, the honest cost includes continuously testing that the standby is capable of taking full load, because standby capacity that has never served production traffic tends to discover its own limits at the worst moment.
How do you test it properly?
Run the drill without the primary provider's console. Declare it unavailable for the exercise: no logging in, no reading configuration from it, no copying a value out of its secret store. That single constraint is what separates a real test from a rehearsal of a plan that quietly assumes the failed system is available, and it typically fails the first two or three attempts for reasons nobody predicted.
Measure the recovery time from the decision to declare, not from the moment the technical work starts. Real recovery includes the time to detect, the time to decide, the time to find whoever holds the break-glass credentials, and the time to verify the restored service is actually correct before traffic is sent to it. Plans routinely quote the middle portion and surprise everyone with the total.
Test the restore rather than the backup. A replication job reporting success proves that bytes moved, not that a database can be brought up from them and that the application works against it. The exercise worth running this afternoon is smaller than a full drill: take yesterday's cross-provider copy of one important dataset, stand it up on the second platform, and have someone who knows the data confirm the last transactions are present and correct.
What recovery objectives does the business actually need?
Fewer than are usually claimed, and asking service by service reduces the cost dramatically. When every system is assigned an aggressive recovery objective by default, the architecture is priced for the strictest case everywhere. When each owner is asked what genuinely happens during four hours of unavailability, most systems turn out to tolerate far more than the blanket figure, and a small number turn out to need more than they were given.
Express the requirement in two numbers per service: how much data loss is acceptable, and how long the service can be unavailable. Then price the architecture that meets them. The cost curve is steep at the short end, and the discussion becomes productive as soon as an owner sees that reducing the target from hours to minutes multiplies the cost, because they will often revise it themselves.
Write down the recovery objectives you have actually demonstrated, alongside the ones that were requested. That gap is the true state of your resilience, and it is the number regulators, insurers and enterprise customers increasingly ask for. Organisations that maintain it find they need far less cross-provider infrastructure than they assumed, because the constraint was never capacity, it was rehearsal.
Common questions
- Does multi-cloud protect against outages?
- Only against a narrow class of them. Bad deployments, data deleted or corrupted by your own code, expired certificates and exhausted quotas cause most real downtime and are unaffected by a second provider. Regional outages are handled far more cheaply by a second region. A second provider genuinely helps with global control plane or identity failures, account suspension, and credential compromise with destructive action, which are rare but severe.
- Is multi-region better than multi-cloud for disaster recovery?
- For most organisations yes, because it addresses the realistic failure at a fraction of the complexity: one identity model, one network design, one set of tooling, and replication supported natively by the managed services already in use. It is also rehearsable with existing deployment automation. Its limit is that regions share an account, identity system and control plane, which is exactly where the case for a second provider begins.
- Why do cross-cloud disaster recovery plans fail?
- Circular dependency, most often. The runbook needs the CI system, artefact registry, secret store, infrastructure state, identity provider and paging tool, and several of those usually live on the provider that is down. The other recurring causes are data replication that has silently fallen behind, and managed service equivalents on the second provider that were configured once and never tested under load.
- What does a realistic multi-cloud recovery design look like?
- Cold and rehearsed rather than warm and theoretical: a current copy of critical data in an open format on the second provider, infrastructure defined as code that can build the environment there, container images in a registry that survives the outage, break-glass identities that do not depend on federation, and a runbook executed end to end at least once. Recovery takes hours, which is usually acceptable for the events it exists to survive.
- How do you test a cross-cloud failover?
- Run the drill with the primary provider declared unavailable: no console access, no reading configuration from it, no copying values out of its secret store. Measure recovery from the moment of decision, including detection, decision, locating break-glass credentials and verifying correctness, not just the technical work. Test the restore rather than the backup, since a replication job reporting success proves bytes moved and nothing about whether a database comes up.
