Multi-cloud makes you less resilient, not more (and you can prove it with math)

🇧🇷 Leia em português →

After every big cloud outage, it comes back. And it almost always arrives the same way: a C-level who had lunch with a vendor, heard that the magic solution exists, and walks into the meeting with the line ready. "We need to go multi-cloud, so if AWS goes down we stay up on Google." The whole room nods. Sounds obvious. Two vendors, twice the safety, right?

Wrong. And yes, that is my opinion. Only mine comes with the math on the table.

And if you think I am just being difficult, hold on to one name: Snap. The company behind Snapchat, the app where everything is built to disappear. It signed with the two biggest clouds on the planet. Billions of dollars in contracts, the word "REDUNDANT" printed right there in the IPO filing, lawyers reviewing it, the market applauding, and the board reading that and thinking "there we go, now we are doing it right". All by the book, right? Well: in October 2025 it went down along with the rest of the internet, exactly like a three-person startup running in a single region. The reason is written by Snap itself, in the risk section of the reports it files with the market, and I will come back to it later.

The intuition that fools you about multi-cloud: parallel redundancy

Before the math, let's agree on what the numbers mean, because availability is easy to quote and annoying to translate.

When someone says 99.9% availability, they are saying the system can be down for about 8 hours and 46 minutes per year. That is a perfectly realistic number for a well-built application running in a single cloud.

Now the magic trick everyone does in their head during the meeting. If a system is down 0.1% of the time, and I have TWO independent systems, the chance of both being down at the same instant is tiny. It is the logic of two flashlights in a drawer: the chance of both burning out at the exact same second is far smaller than the chance of one burning out. Only one has to light up for you to see.

In reliability theory this has a name, parallel redundancy, and the math goes like this:

Parallel (the intuition):  1 - (0.001 x 0.001) = 99.9999%

Six nines. About 30 seconds of downtime per year. It is beautiful, and the math is dead right, go ahead and check it. The math does not lie. It just answers a very specific question: what is the availability of two systems that are sufficient, independent and genuinely parallel? Hold on to those three words, because that is exactly where multi-cloud projects tend to fall apart.

The detail that has to enter the math: what sits in series

Here is the thing. For "only one has to work" to leave the slide and become real, something has to decide which cloud serves each request, something has to keep the data coherent on both sides, and something has to say who the user is on both sides. Those somethings are not dedicated employees: they are new layers, that YOU build, operate and keep alive.

Go back to the flashlights for a second. They are genuinely independent: you switch one on, the other stays in the drawer, and neither depends on the other to work. Now imagine that, to make the two flashlights work as a pair, you had to wire both into the same switch, with a circuit that decides which one lights up. Guess what happens when the switch burns out? You are standing in the dark holding two perfectly good flashlights.

The switch is the dependency the slide does not show. And it rarely shows up alone.

Those layers sit in series with the service, series as in the circuit, one piece after another in the request path. And a component in series does the opposite of parallel: it multiplies availability downwards.

Imagine a design where global routing, synchronous consistency between the two clouds, and a shared identity all have to work for the request to complete. If each piece delivers 99.9%, the math looks like this:

Series (in this design):  0.999  (global traffic routing)
                        x 0.999  (synchronous cross-cloud consistency)
                        x 0.999  (shared identity)
                        = 99.7%   <- worse than a single cloud

See the irony? You spent a fortune to put two clouds in parallel and landed on 99.7% because of what ended up in series. Every piece you added to "gain resilience" became a brand new single point of failure. If one piece of the critical path delivers 99.9%, that becomes the ceiling of the entire system, no matter how good the two clouds underneath are.

Now, being fair to the math, because I would rather hand you the ammunition before you use it against me. The 99.9% on each piece is an illustrative number, picked so the idea is visible; your design may have better pieces, worse pieces, or pieces outside the request path. And here is the caveat that matters most: if replication is asynchronous, it drops out of this math. Cloud A confirms the write and ships the copy to B right after, so when replication breaks the service stays up and the damage lands entirely on the data. The problem moves somewhere else and becomes RPO, which we will get to later.

So the math does not prove that every multi-cloud is less available. It proves something more modest and more uncomfortable: the second cloud does not erase the glue that makes the two work as a single service, and that glue has availability of its own.

There is also a way to pull a piece out of the series, and it has a name: static stability, which AWS itself documents in the Builders' Library. The idea is that the system keeps serving even when the control plane (the piece that decides things) dies. In practice: both sides are already active and taking traffic, with capacity pre-provisioned on both sides, and the health check simply pulls a sick endpoint out of the pool instead of having to "wake up" the side that was sleeping. If failover orchestration goes down, traffic keeps flowing through whatever is still standing.

Which means a good architect can absolutely pull pieces out of the series, and should try. It is just that real static stability is expensive, because it requires idle pre-provisioned capacity on both sides, all the time. You take the piece out of the availability math and it reappears in the cost math, doubled now, because it is two idle clouds instead of one.

There is no free lunch. There is a menu, and somebody always picks up the tab.

The exact number varies with your project. The direction is what matters: every dependency you add to the critical path multiplies availability downwards. Routing is the most stubborn of them, because something always has to pick the destination of a request, but even routing can be distributed, cached and made statically stable. One question settles it: if that layer stops deciding right now, does the traffic that is already working keep flowing? Add the operational complexity of keeping all of it alive and you understand why the six nines never show up.

Independence is fiction

There is an even deeper detail. The parallel math only holds if the two failures are independent. And they almost never are.

Picture two giant container ships sailing side by side, connected by a bridge. That is the image being sold to you: if one sinks, the other keeps going with your cargo. Beautiful. Except both ships have the same captain, and he is the one picking the route. If the captain misreads the map, both run into the same sandbar, together. And the bridge, which exists only to keep the cargo identical on both ships, is the most expensive and most fragile part of the story: it sways in every storm, charges a toll in both directions, and on the day it collapses you are not left with two identical ships. You are left with two different ships, each carrying its own cargo, and nobody on board knows which one is the real thing.

The two clouds share dependencies you do not even remember exist: the same DNS, the same certificate authority behind your TLS, the same identity provider and, above all, the same deploy pipeline. Guess what happens when the team pushes a bad config? It ships to both clouds at the same time.

And look at the size of that hole: the Uptime Institute estimates, based on 25 years of data, that human error plays some role in somewhere between two-thirds and four-fifths of all outages. Notice the words they chose, because they are honest: "some role". Human error rarely shows up as the lone root cause, it is the thread running through the incident. And the most stubborn piece is always the same: people not following the procedure, or the procedure being bad from birth. Guess how much switching vendors helps with that? Not at all.

And here is where the joke lives: if there is one thing DevOps culture has delivered masterfully over the years, it is the ability to propagate nonsense in seconds, with a green pipeline, two reviewer approvals and a rocket emoji in the channel. We automated everything, including the mistake. Except now, with two clouds, it lands in both places at the same time and you pay double for the privilege. Deploy is the most reliable thing in your stack, and that is exactly why it carries the bad config to both destinations without failing once.

Correlated failure breaks the independence assumption, and without independence the parallel math simply does not exist.

The hidden price: the lowest common denominator

To truly run active-active on AWS and Google at the same time, everything has to be portable across both. So you give up the managed services that are the most resilient part of the cloud (DynamoDB, S3, SQS, battle-tested at absurd scale) and fall back to whatever runs anywhere: Kubernetes plus a pile of open source that YOU install, operate and keep alive.

And here goes an uncomfortable question, with zero disrespect: does your team operate that stack with more reliability than AWS operates DynamoDB? The team keeping those managed services up at global scale is huge, dedicated, and has been doing only that for over a decade. Betting that your team, split across a thousand priorities, delivers more uptime by hand than they deliver managed is quite a bet. No judgment on anyone's competence; it is simply the matchup of whoever just stepped into the arena against people who made this their life's work.

You traded managed resilience for resilience that became your phone ringing at 3 a.m. As Werner Vogels hammers, "everything fails, all the time". So the question that matters becomes another one: who is on call when it fails? Active-active multi-cloud puts you on that rotation, twice. And notice that it is not enough to have someone who knows AWS on one side and someone who knows Google Cloud on the other. Somebody has to master the glue between them, that piece that exists only inside your company, that has no support button, no ready-made tutorial, and nobody on Stack Overflow who has been through it. On-call costs money, and this on-call costs more. It is a fat line item that rarely shows up in the business case.

And the cost? You pay for data to leave, on both sides

There is one item the project spreadsheet usually ignores: egress. Clouds charge little (or nothing) for data coming in, and charge for data going out. In a real active-active setup you are constantly syncing data between AWS and Google to keep both ends identical, so you pay data transfer out on both sides, all the time, just to keep the copies coherent. It is a faucet left running, every month, forever.

I can already hear the objection: "but egress became free in 2024". Careful with that one. What AWS, Google and Microsoft zeroed out that year, pushed by the EU Data Act, is egress for people who are leaving the cloud, and even then with rules: account in good standing, take everything with you, notify support and close the subscriptions within the deadline. That is a divorce subsidy, not an open marriage subsidy. Continuous replication between two clouds, which is precisely what active-active demands, still runs through the register every month.

And add the rest: you duplicate managed services, duplicate the observability stack, duplicate the security and compliance surface, and you need a team with depth in both clouds. The cost does not double, it more than doubles, because the glue integrating the two is a cost center of its own.

Werner Vogels sums it up in The Frugal Architect: cost is an architecture requirement, and whoever only discovers the number on the invoice discovered it too late. Multi-cloud almost always flunks that test, you pay a fat, continuous bill for insurance against an event that almost never happens.

And let me confess something. Every time that slide shows up in a meeting, there is an architect in some corner of the room who wants to lie down in fetal position under the table (me included). While everybody celebrates the bold decision, they are running the math in their head and watching how much money is about to be burned buying protection against a rare event, money that would solve, I don't know, the multi-Region setup the company has been postponing for two years. If you are that person, breathe: this post is your argument in writing, with the math in hand. And if you are the one approving the project, take another look at the numbers above before you sign.

And before anyone closes the tab in anger: relax, I am not saying multi-cloud never works. There are times when it is the right answer, and I have an entire section about that further down. It is just that those times have a name, a context, and are almost never "resilience". Hold on, we will get there.

What multi-cloud protects you from, and how rarely that happens

Think about the real outages you have seen. They were regional, zonal, or a specific service (us-east-1 in October 2025 was exactly that). It is almost never "all of AWS died globally". Whoever went down that day was pinned to a single region, and what would have saved most of them was multi-Region in the same cloud, not a second cloud. Multi-AZ and multi-Region within the SAME cloud cover the overwhelming majority of cases, at a fraction of the complexity. And it is not just me saying it: AWS's own multi-Region guidance recommends confirming that your objectives do not fit inside a single Region before you go for several.

So let's do the homework before drawing two clouds on the whiteboard: does Multi-AZ solve it? Does multi-Region solve it? Or are we overengineering to buy a feeling of safety? What each of those steps costs, and why that math is a business decision before it is a technical one, I went into in the post on the price of high availability. If the requirement fits inside one cloud, adding a second vendor is not automatic maturity. Sometimes it is just complexity wearing a suit.

This has a pattern name: Bulkhead and cell-based architecture, isolating the blast radius inside your own vendor, in compartments that do not sink together. Multi-cloud protects you from the extremely rare event (the whole provider vanishing from the map) and, in exchange, exposes you to a pile of everyday failures you introduced yourself.

And before I sell you multi-Region as a silver bullet, the fine print: in that same outage, plenty of multi-Region architectures went down too, because they depended on a global control plane (IAM, STS) or had a hidden dependency in us-east-1 that nobody had mapped. This is not theory: AWS's own post-event summary records that STS choked, and that customers using identity federation pointing at signin.aws.amazon.com got console errors in other Regions too. No medicine comes without a leaflet. The difference is that the multi-Region leaflet fits in a paragraph and the active-active multi-cloud one is a two-year project.

The Snap case: multi-cloud on paper, downtime in practice

I promised to come back to Snap, so here we go.

It did exactly what every board dreams of: signed with both. Google Cloud as primary, and the 2017 IPO S-1 showed a one billion dollar commitment to AWS, with the phrase every executive loves to read, "for redundant infrastructure support of our business operations". Textbook multi-cloud, the two biggest clouds on the planet on the same invoice.

Then, on October 20, 2025, AWS us-east-1 choked. And Snapchat went down along with the rest of the internet.

And the rest of the story is written by Snap itself. Year after year, in the risk section of the reports it files with the market, there it is: a warning that its systems are not fully redundant. Look at the timing: that warning was already sitting there long before the fall, in the same stack of paper where the billion dollar contract said "redundant". Nobody wrote it afterwards to explain themselves. The redundancy existed in the contract and in the investor slide. In the application's critical path, it did not.

That is the punch of the argument, and it holds for any company, not just Snap: two clouds on the invoice do not give you two clouds in the architecture. If the critical path depends on a region that went down, the contract with the other vendor sitting in a drawer does not bring your service back up. And if not even a company that size, with billions allocated and elite teams, turned two contracts into real redundancy, the uncomfortable question is worth asking: why would your project turn it?

But what if I already have failover ready on the other cloud?

Here the attentive reader raises a hand: "fine, but if cloud A goes down and I have DR ready to flip to B, multi-cloud saved me, right?". It can save you, yes. And notice this scenario is active-passive (one cloud hot, the other on standby), not the active-active that the math above tears apart. They are different things, and this is the legitimate version of the story.

Except three gotchas knock "I have failover" down in practice.

The first: having failover is not the same as failover working. The DR path is the least tested stretch of your system, and you only trigger it at the worst possible moment, under pressure. DR that was never exercised is Schrödinger's backup, you find out whether it works exactly when you need it. It is the classic untested-DR movie: when you go to flip the switch, capacity is not provisioned on the other side, secrets are out of sync, IAM is different. The plan existed, the failover never came.

The second: failover takes time and you lose data along the way. Synchronous replication between two clouds (the kind where a write is only confirmed after it landed on both sides) is too expensive and too slow, so in practice everybody uses asynchronous: cloud A confirms the write to the user and ships the copy to B right after, with a delay of a few seconds.

Look at the hole that opens. If A goes down in exactly that window, everything it confirmed and had not yet copied to B is gone. The order the customer saw on the screen, the payment that showed up as approved, simply does not exist on the other side. That is what RPO (Recovery Point Objective) means, how much data you accept losing, measured in time. And there is RTO (Recovery Time Objective), the time until the service is back, which cross-cloud runs from minutes to hours: bringing up the passive side, propagating DNS, warming caches. It is not pressing a button.

The third: for the outage that actually happens, multi-Region in the same cloud delivers the same DR without the cross-cloud pain. us-east-1 went down, not AWS globally. A Warm Standby or a Pilot Light in another Region of the same cloud brings you back with native managed services, the same IAM and the same tooling (AWS documents all four strategies, with the RTO and the cost of each, in the Disaster Recovery whitepaper). Going cross-cloud, you throw all of that away to protect against a much rarer event.

Bottom line: cross-cloud failover can exist and even work, but it is expensive, fragile when untested, and almost always loses to same-cloud multi-Region for the kind of outage that actually knocks on your door.

So multi-cloud is never worth it?

It is. Just almost never for technical resilience, and this is where most people get the argument wrong. Multi-cloud is justified by business reasons:

• Data sovereignty and regulation: the law says the data must live in a given cloud or country.

• Leverage against vendor lock-in: commercial bargaining power (uptime does not even enter that equation).

• SaaS that must run wherever the customer demands.

• DR required by compliance, sometimes existing only on paper to pass the audit, not because the architecture actually fails over.

And notice that when it is worth it, it is almost always active-passive (one cloud hot, one cold just for disaster recovery), rather than the active-active that wrecks your availability. It is a business and risk decision, recorded in an ADR, with no promise of an extra nine attached.

Since we made it this far, let me plant my position, and it is an opinion, not a theorem. Every architecture decision has two sides, and the question that settles this one is not technical: what is your real pain, and how much does it cost if it happens? If the answer comes from the regulator, the contract or data sovereignty, multi-cloud is in, usually active-passive, and the ROI justifies the complexity. Outside of that, for me, active-active hurts to watch: you buy two ships, a bridge, a double on-call rotation and an overloaded captain to protect yourself from an event that probably is not coming, while the multi-Region setup that would solve your real case keeps waiting for budget. Resilience is not what you buy. It is what you decide, and then sustain.

That is the heart of the post on the price of high availability: resilience starts with a strategic decision, and the stack comes after, as a consequence. Multi-cloud is the most expensive way there is to flip that order.

What you take from this post

• The parallel math (99.9999%) only holds for systems that are sufficient, independent and genuinely parallel. Global routing, synchronous consistency and shared identity sit in series and drag the number below what a single cloud delivers.

• Asynchronous replication drops out of the uptime math and reappears in RPO: the service stays up and swallows the last writes.

• Correlated failure (config, deploys, DNS, CA) breaks the independence assumption the math requires.

• Active-active forces the lowest common denominator: you trade mature managed services for a stack that becomes your on-call.

• The cost more than doubles: egress on both sides to keep data in sync, duplicated infra, and a team with depth in two clouds.

• Multi-AZ and multi-Region in the same cloud (Bulkhead, cells) solve the real case at a fraction of the complexity.

• Multi-cloud is worth it for business reasons (regulation, lock-in), not resilience. And then it is active-passive, documented in an ADR.

Honest question for you: have you ever been pushed into a multi-cloud project "for resilience" and found out you gained two on-call rotations instead of one? Tell me how it went. And if you disagree, even better, drop your availability math in the comments, I want to see where mine leaks. Smash that like, share this with whoever is about to approve that project, and let's talk. Thanks a lot! BUILD. SCALE. REPEAT. =D

Want to go deeper

The sources worth your next half hour (the rest are linked along the way, right where they matter):

• Static stability using Availability Zones, from the Amazon Builders' Library. The source of the concept that takes the control plane out of the request path, with the control plane vs data plane split explained by the people who built EC2.

• Disaster recovery options in the cloud, from the AWS DR whitepaper. Pilot Light, Warm Standby and the note that finally explains the difference between them. This is the alternative that solves your real case without going cross-cloud.

• Post-event summary of the October 2025 outage, by AWS itself. The race condition in DynamoDB's DNS and the cascade that followed: the primary source for the case that opens this post.

• The Frugal Architect, by Werner Vogels. Law I is "Make Cost a Non-functional Requirement", and it is the test multi-cloud fails.

• High availability has a price: resilience is a decision, not a stack, here on the blog. The pillar for this post: the cost of the nines, RTO/RPO and ADRs.