Multi-Cloud as Insurance Costs More Than the Outage It Insures Against

An insurance policy has a premium you can read and a payout you can claim. Multi-cloud sold as resilience has neither. The premium is charged every day in engineering hours and cognitive load, it never appears as a line item, and the payout requires that a failover nobody has exercised works correctly during the one hour of the year when everyone is already awake and panicking.

That is not insurance. That is a second system you maintain in the hope of never using it, which is a description of the least reliable kind of software there is.

The premium is paid in the parts nobody counts

The visible cost of a second provider is duplicated infrastructure, and it is the smallest part. The real charge is levied against everything that has to be built twice or built to the intersection of both.

Identity is the first. Two providers means two identity models, and either you federate them into one, which is a project, or you run them separately, which produces the access review problem where a leaver is removed from one side and not the other. Networking is the second. Two sets of virtual networks, two firewall models, two logging formats, and a route between them which is itself a boundary with latency and transfer charges attached.

Then the managed services question, which is where the argument usually collapses. The reason to be on a cloud provider at all is largely the managed services: the queue you did not have to run, the database you did not have to patch, the identity broker, the key store. Portability across two providers means either using none of them and running everything yourself on generic compute, or maintaining two implementations of every integration. The first surrenders the value of the cloud. The second doubles the surface area of the thing that most often breaks.

It is worth being honest that this rarely gets decided on the merits. The decision to add a provider is usually made once, in a board paper, and inherited by everyone afterwards. Whether you actually need multi-cloud at all is the question that should be reopened annually, and almost never is.

The failure you are insuring against is usually not the one that happens

Full regional outages at major providers are rare and short. The outages that take your service down are much more often yours: a bad deploy, an expired certificate, a schema migration, a runaway query, a misconfigured security group, a dependency you did not know was single-homed. A second cloud provider protects against none of these, because your code and your configuration are the failure, and they will be replicated faithfully to both sides.

Worse, active-active across providers adds failure modes you would not otherwise have. Two writable copies of the same data mean either accepting eventual consistency in a system not designed for it, or funnelling writes to one side, in which case the other side is not really live. Failover logic is itself a component that can fail, and it is exercised least of anything you own.

Failure you fear	Does a second provider help?	What actually helps
Full provider region outage	Yes, if failover is rehearsed and state is reconcilable	Multi-region within one provider, at a fraction of the complexity
Single availability zone loss	No, this is already handled	Zone-redundant deployment, which you may already be paying for
Bad deploy or config change	No, it replicates to both	Progressive rollout, fast rollback, real staging
Data loss or corruption	No, replication propagates corruption	Backups tested by restore, not by existence
Account suspension or commercial dispute	Partly	Contractual terms, and an exit plan on paper
Price increase at renewal	Partly, as negotiating leverage	Portable data formats and infrastructure as code

The last two rows are the honest reasons to consider a second provider, and neither is a resilience argument. They are commercial arguments, and they can often be satisfied by being able to leave rather than by already having left, which costs considerably less.

Portability is a property of your data, not your infrastructure

The version of lock-in that hurts is not the compute layer. Compute is comparatively easy to relocate, because containers and infrastructure as code have made the description of a running service reasonably portable. What actually holds a workload in place is the data: its size, its rate of change, and the number of things that read it. This is the same mechanism that governs data gravity and where workloads belong in any hybrid design, and it applies with equal force to the question of whether you could move providers if you had to.

Which suggests a cheaper strategy than running two clouds. Keep the data in formats you could export, keep the schema documented, keep the pipelines describable, and periodically prove you can restore into a different environment. That is an exit plan. It costs a rehearsal a year rather than a permanent second estate.

There is also a cost that only appears once two providers exchange data continuously. The way egress charges accrue across a boundary applies exactly to cloud-to-cloud replication, and replication is continuous by definition.

When a second provider is genuinely the right answer

It exists, and it is narrower than the pitch.

1. A regulator or a customer contract requires it in writing. Then it is a compliance obligation, not an architecture decision, and it should be scoped to the specific system named in the requirement.
2. A specific capability exists on one provider only and the workload that needs it is otherwise self-contained. This is not multi-cloud, it is one workload placed on its merits, and it should stay that way.
3. An acquisition has already given you two. The right response is usually to consolidate over time and to be deliberate about which one, not to declare the accident a strategy.
4. Concentration risk is material at board level because your business is itself infrastructure for others. Rare, and where it applies, the cost is justified and should be funded properly rather than absorbed.

Outside those, the resilience argument is usually best answered inside a single provider using multiple regions, which shares the identity model, the tooling, the logging, and the on-call runbook. It is not free, but it is one system instead of two.

What to do next

Write down the specific failure you are buying protection against, and the last time it happened to your provider. Then write down the last three incidents that actually took your service down. If those two lists do not overlap, your resilience budget is pointed in the wrong direction.

Then cost the premium properly. Not the duplicated infrastructure, but the engineering hours spent on double implementations, the incidents caused by the failover machinery, and the managed services you declined to use in the name of portability. Compare that annual figure to the plausible outage it prevents, and make the call as a commercial decision rather than an architectural reflex.

If the answer turns out to be that you need one provider done properly plus a credible route out, that is a design problem with a defined shape, and it is the work our hybrid cloud integration practice takes on: one identity model, one network design, and data you could actually move if you ever needed to.