A company runs its application in two clouds. When the primary provider fails, the second deployment is healthy, but it cannot decrypt its configuration because the key-management service is still in the first cloud. The company has redundant servers and a single point of failure.
Multi-cloud can reduce supplier concentration, but the value depends on which dependencies move with the application.
Provider diversity is not necessarily application failover
Microsoft's multicloud overview describes organizations using multiple providers for different workloads and services. That can improve access to specialized capabilities, reduce commercial dependency or reflect an acquisition. It does not automatically create a disaster-recovery system for each application.
If accounting runs in one cloud and customer support in another, an outage may affect a smaller portion of the business. Neither workload necessarily has a replacement. Running the same customer function across both providers is a separate design, with additional cost and operational requirements.
Start with the failure you need to survive. A provider outage, loss of a specific managed database and inability to obtain capacity require different responses.
Draw the dependencies, including the recovery controls
An application may need identity, secrets, DNS, certificates, images, queues and a durable database before it can accept useful traffic. A standby cluster can be running without any of those dependencies being independent.
AWS's multi-region dependency guidance covers the need to make required resources available in the recovery region and avoid reliance on a failed primary region for failover controls. The same reasoning applies when the recovery site belongs to another provider.
A shared monitoring service might be tolerable if the application continues without it. A shared identity provider required for every login is more consequential. Identify dependencies according to the customer function they can prevent, not just the company that supplies them.
Recovery procedures deserve the same treatment. If the only infrastructure deployment system, secret store or administrator login depends on the failed cloud, it may be impossible to activate the standby in time.
Portable containers do not make data portable
A container image can simplify packaging an application for another platform. It does not reproduce a managed database's consistency model, permissions, event delivery guarantees or network policies. Those surrounding services determine whether the application behaves correctly in the new environment.
Google Cloud's multicloud deployment guidance discusses redundant storage, cross-cloud connectivity, differences in security tooling and the expense of maintaining standby capacity. The application needs both a portable executable and a compatible operational environment.
The data layer often requires the most work. Two front ends do not provide independent order processing if both depend on the same inaccessible record of accepted transactions. Asynchronous replication can lag; accepting writes independently can create conflicts. A recovery design needs an explicit decision about which site may become authoritative and how the old primary is prevented from creating a split-brain condition.
A standby must meet a stated recovery target
Imagine a 500 GB database with 20 GB of changes per hour. If replication stops for three hours, the standby might be missing 60 GB of changes, assuming a steady rate and no backlog reduction. That volume does not directly tell you how many business transactions would be lost, but it helps identify the gap the recovery procedure needs to handle.
An asynchronous standby might meet a recovery-time target while missing the recovery-point target. A cold standby may be less expensive, but it needs time to provision capacity, restore data and start accepting requests. Reserve enough capacity for the intended recovery mode and test it under the expected workload.
The additional cloud also creates recurring transfer, storage, monitoring and engineering costs. These may be justified for a critical service, but they should be compared with a simpler multi-zone or multi-region design that meets the same business objective.
A real example of shared upstream infrastructure
Cloudflare's 12 June 2025 postmortem identified a failure in the storage infrastructure underlying Workers KV, including a third-party cloud dependency. Several products were affected, while its core DNS, proxy and other services were not directly impacted.
The incident demonstrates why the provider's name is not the failure boundary. Examine the actual service dependencies. A second cloud account only improves resilience if the important customer function can still run when the first path is unavailable.
For a broader view of the internet-facing part of that problem, see DNS, BGP and CDN incidents.