Why Multicloud Architecture Is Not a Cloud Resilience Strategy
There is a particular kind of nonsense that circulates in enterprise technology conversations, the kind that sounds like wisdom because it wears the clothes of prudence. Multicloud architecture as a cloud resilience strategy is that nonsense. It has the shape of risk management and the substance of a comfort blanket, and the industry has spent the better part of a decade selling it to boards who do not know enough physics to push back.
The argument goes like this: if you depend on a single cloud provider, you are exposed to that provider’s failures. Therefore, spread your workloads across two or more providers and you eliminate that exposure. It sounds reasonable. It is not. It collapses the moment you apply any meaningful scrutiny to what cloud resilience actually requires, and it is worth working through exactly why, because the pattern of thinking it represents keeps appearing in other places under other names.
1. What a Real Cloud Resilience Strategy Protects Against
Before you can design a resilience strategy, you need to be precise about the failure modes you are designing around. “The cloud goes down” is not a failure mode. It is a category error dressed up as one.
Real cloud failure modes are specific and structural, and they operate at different layers. An Availability Zone loses power or network connectivity: this is handled by synchronous replication across AZs within the same region, which is the baseline of any serious cloud architecture. A region fails entirely: this is addressed by asynchronous disaster recovery to a second region of the same provider, accepting some recovery time and data lag in exchange for geographic independence. A control plane event disrupts management operations across a region: this is not solved by multicloud, because your control plane dependency has simply moved to whichever provider you are failing over to. An identity or DNS failure propagates across dependent services: this is actively made worse by multicloud, because spanning two providers multiplies the number of identity systems and resolution paths that can fail and interact in unexpected ways.
This layering matters because each failure mode has a different appropriate response, and the responses do not all point in the same direction. The progression from a single AZ, through multi-AZ, through multi-region within a single provider, through genuine physical independence for specific critical rails, represents a coherent hierarchy of resilience options with understood trade-offs at each step. Multicloud sits outside that hierarchy. It does not extend it. It introduces a different set of failure modes that are harder to reason about and harder to recover from, while providing at best marginal protection against the failure modes the hierarchy already addresses.
2. The Physics You Cannot Argue With
In South Africa, the relevant geography is AWS in Cape Town and Azure in Johannesburg. The round-trip latency between those two locations is approximately 30 milliseconds. That number is not a configuration setting. It is not a product limitation. It is the speed of light acting on the physical distance between two points, and no amount of vendor investment or engineering cleverness changes it.
For a retail banking core, the operational latency target for service-to-service calls is around 5 milliseconds. This is not an arbitrary preference. It is what the end-to-end transaction budget requires to keep the customer-facing experience responsive. When you consider that a single customer transaction may involve dozens of internal service calls, each carrying its own latency contribution, the arithmetic is unforgiving.
Synchronous database replication across a 30ms link is simply not viable for a high-volume transactional workload. In a banking environment, you cannot allow data to be eventually consistent across two regions. When a debit and a credit need to be atomic, your commit path has to round-trip through your replication target before the transaction can be confirmed. At 30ms per round trip, across thousands of concurrent transactions, you have not built a resilient system. You have built a slow one that will periodically queue itself into a timeout spiral under load.
This is the physics argument that tends to end the multicloud conversation among people who have actually run high-scale stateful workloads. The theoretical redundancy offered by a second provider sits on the wrong side of a latency boundary that makes it operationally useless for the workloads that matter most.
3. Net Risk vs Gross Risk
The multicloud argument is almost always made in gross risk terms. AWS could fail. Therefore AWS is a risk. Therefore reducing dependency on AWS reduces risk. Each step sounds plausible in isolation, and the conclusion follows if you never ask the obvious follow-up question: compared to what?
The net risk calculation looks different. Yes, a regional AWS failure is possible. It is also rare, increasingly well-contained by the provider’s own investment in regional isolation, and in a well-architected multi-AZ deployment, survivable at the AZ level for most failure classes. Against that, set the concrete risks you introduce by spanning two providers: the complexity of a spanning architecture, the coordination failure modes, the policy drift, the operational overhead of two toolchains, the latency penalty on your most critical data paths. These are not theoretical. They are costs you pay continuously, and they increase the probability of an outage on every day that is not the day AWS’s Cape Town region has a sustained failure.
The net risk of a well-architected single-provider deployment is lower than the net risk of a poorly-architected multicloud deployment for the overwhelming majority of workloads. The gross risk framing survives only because it counts one side of the ledger. When you count both sides honestly, the arithmetic tends to favour depth in a single provider over breadth across two.
This is not a novel observation. It is the engineering intuition behind every serious high-scale system that has chosen to invest in understanding one platform deeply rather than hedging across several superficially. Complexity is itself a failure mode, and multicloud adds more complexity than it removes risk. Every additional cloud provider is not additive complexity. It is multiplicative coordination overhead, applied across APIs, failure semantics, throttling models, observability toolchains, and incident response processes simultaneously.
4. The Security Architecture Problem
The multicloud resilience argument occasionally survives the latency objection by retreating to security. If the resilience case does not hold up, perhaps the security posture of spanning two providers offers some benefit. This is also largely illusory, and for reasons that are worth spelling out carefully.
Cloud-native security at the infrastructure level is deeply provider-specific. In AWS, the fundamental unit of security is the IAM role, and the native segmentation mechanism is the Security Group, which can reference other Security Groups and IAM roles directly. This means that a rule permitting your web tier to call your database tier is expressed in terms of the identities of those services, not their IP addresses, and it is enforced at the hypervisor level without any additional tooling. Azure has its own equivalent constructs. Neither provider’s constructs are legible to the other. An AWS Security Group cannot reference an Azure Service Principal. An Azure NSG cannot reference an AWS IAM role.
This means that any security architecture spanning both providers is, by definition, operating at a lower level of abstraction than either provider’s native model. You are forced back to IP addresses and CIDR ranges as your segmentation primitive, which is a significant regression. The alternative is to introduce a third-party overlay: a service mesh, a centralised policy orchestration tool, a zero-trust exchange sitting in the middle. Each of these options reintroduces a centralised control plane that becomes its own single point of failure, while simultaneously adding latency and operational complexity that your engineering team now has to maintain across two different providers’ API surfaces. Your identity model fragments across two providers with no native bridge between them. Your observability fragments across two toolchains with different data models, different query languages, and different alert routing. When something goes wrong, your incident response team is traversing Cloudflare, AWS, and Azure simultaneously while each provider’s support organisation points confidently at the boundary of their own infrastructure. The time lost to that ping-pong is time you cannot afford.
Policy drift is the quiet killer in these architectures. A firewall rule updated in AWS that fails to propagate to its Azure equivalent because an API changed and the orchestrator has not caught up creates a security gap that is invisible until it is exploited. The more complex the spanning architecture, the larger the surface area for this kind of invisible inconsistency. Multicloud does not strengthen your security model. It turns it into the lowest common denominator of what two providers can express simultaneously, enforced through a layer of third-party tooling that neither provider fully understands or supports.
5. Cloud Gluttony and the Failure You Are Actually Creating
Here is the structural problem that the multicloud resilience argument consistently avoids examining. When you introduce a second cloud provider, you do not remove a single point of failure. You add more baskets and tie them together with string, then describe the arrangement as diversification. Hybrid multicloud multi-region is a form of self-mutation — your architecture accumulating complexity it cannot reason about, one well-intentioned redundancy decision at a time. This is cloud gluttony: the organisational inability to make a disciplined architectural choice dressed up as strategic optionality.
It is Augustus Gloop falling into the chocolate river. Not a victim of the factory. A victim of wanting everything, all at once, without accepting that the physics of the pipe had an opinion about that. The enterprise that cannot commit to a regional architecture, that wants the discounts of us-east-1 and the compliance posture of eu-west-1 and the latency of af-south-1 and the managed services of Azure and the AI tooling of GCP, is not building resilience. It is building a monument to appetite, consuming every available option until the architecture can no longer support its own weight. Augustus did not drown in chocolate because the factory was poorly designed. He drowned because nobody told him that wanting everything is not a strategy, and he would not have listened anyway.
The shared failure domains do not disappear. They move. DNS, identity, traffic routing, and CDN infrastructure are the hidden choke points that span every cloud you are running on, and a failure in any of them propagates across your entire estate regardless of how many providers it touches. A Route 53 or Cloudflare outage does not care that you have workloads in two clouds. Your clients cannot reach either of them. An identity provider failure does not care about your provider count. Both clouds go dark simultaneously. The multicloud architecture has not removed these dependencies. It has made them harder to see and harder to fix.
The data layer is where the argument collapses most completely. Provider-native managed database services are not portable and they are not interoperable. AWS Aurora PostgreSQL is not going to run a synchronous read replica in Azure. The replication mechanisms, the storage engines, the failover protocols are all provider-specific, and there is no standards body harmonising them. Split a service across two providers and you lose access to the native replication tooling that makes high-availability databases tractable, replacing it with bespoke synchronisation logic that you now own, maintain, and debug. You have not gained a resilience option. You have discarded several and substituted something more fragile in their place.
What a real failure looks like in a spanning architecture is instructive. A latency spike in one cloud causes a cross-cloud dependency to time out. The retry logic, designed for a single-provider latency profile, storms the connection. The backpressure propagates in both directions. A failure that would have been contained within one provider’s blast radius has now crossed the wire into the other, and your incident response team is attempting to reason about a distributed system state that spans two completely different operational models under the worst possible conditions. You have not prevented failure propagation. You have given it a wider surface to travel across.
The operational consequences compound everything above. Your engineers now need deep expertise in two provider ecosystems, two sets of IAM models, two networking constructs, two observability toolchains, two incident response processes. Every runbook is twice as long. Every incident has twice as many possible explanations. The mean time to diagnose and recover from a failure increases substantially, which is the opposite of what a resilience strategy is supposed to achieve.
6. The us-east-1 Concentration Problem
There is a failure mode that sits between “AWS is fine” and “multicloud is the answer” that the industry has been remarkably reluctant to discuss plainly. A significant proportion of the outages that get reported as AWS failures are not regional infrastructure failures at all. They are the predictable consequence of a large number of organisations voluntarily concentrating their workloads into a single AWS region for reasons that have nothing to do with architecture and everything to do with commercial incentives.
us-east-1, AWS’s original Northern Virginia region, has accumulated an extraordinary density of global provider workloads. It was the first region, it has the longest service catalogue, and for years it offered the most competitive pricing. New AWS services frequently land in us-east-1 first, sometimes exclusively for extended periods, which creates a gravitational pull for engineering teams who want access to the latest capabilities. Procurement teams chasing volume discounts negotiate commitments that anchor them there. The result is a region carrying a disproportionate share of global cloud traffic, not because the architecture demands it, but because the commercial incentives pointed that way and nobody pushed back hard enough.
When us-east-1 has a control plane event, the blast radius is not proportional to its share of AWS’s infrastructure. It is proportional to its share of AWS’s customers, which is far larger. The DynamoDB API disruption is a clear illustration of this. DynamoDB is a regional service. The failure was contained to us-east-1. But because so many global platforms had anchored critical dependencies in that region, services around the world experienced cascading failures that read in the press as a global AWS outage. They were not. They were a us-east-1 concentration event whose blast radius extended globally because the customers in that region had not respected the regional isolation boundaries that AWS’s architecture provides.
UK retail banks going down during a us-east-1 event is not evidence that cloud is fragile. It is evidence of inappropriate risk management. A UK bank has no business running latency-sensitive, customer-facing workloads in a region on the other side of the Atlantic, and if it is doing so because that is where its vendor negotiated the best discount or where a particular managed service first became available, that is a governance failure that will eventually produce exactly the kind of headline it produced. The architecture did not fail. The decision-making that ignored the architecture failed.
AWS is not an innocent bystander in this dynamic. The commercial incentives that created the concentration were partly of their own making, and the brand damage from “AWS outage takes down UK banks” accrues to them regardless of whether the root cause was a regional failure or customer misuse of regional architecture. This gives AWS a genuine interest in pushing customers toward appropriate regional distribution, and they do: the well-architected framework, the resilience guidance, the multi-region and multi-AZ design principles are all explicit about this. The problem is that the guidance competes with the discount structure and the feature release calendar, and in most organisations the procurement team and the engineering team are not having the same conversation.
The lesson is not multicloud. The lesson is use the region that is geographically and operationally appropriate for your workload, build across the Availability Zones within it, and resist the commercial pressure to anchor in us-east-1 because the pricing spreadsheet said so. A bank in Cape Town running in af-south-1 across three AZs is more resilient to a us-east-1 event than a bank in London running in us-east-1 with a nominal disaster recovery footprint somewhere else. Regional discipline is the answer. Provider proliferation is not.
7. Cloud-Native Is Not Optional
There is a related failure mode that the multicloud conversation tends to obscure, and it is worth naming separately. The resilience gains from a modern cloud architecture only materialise if you actually build for the cloud rather than simply moving existing workloads onto it.
Lifting and shifting an on-premise workload into a cloud provider’s infrastructure gives you the cost model and operational overhead of cloud without the resilience benefits. A virtualised monolith running on EC2 instances in a single AZ is not a cloud-native architecture. It is a data centre workload with a different billing arrangement, and it will fail in exactly the ways that data centre workloads fail, with none of the recovery speed that a properly instrumented, immutable, infrastructure-as-code deployment provides.
The proof of this is visible in incident response. When the CrowdStrike update failure propagated globally in 2024, the organisations that recovered fastest were not the ones with the most providers. They were the ones with the most automated, observable, and re-paveable infrastructure. Organisations that had built on cloud-native primitives, with immutable infrastructure defined in code and deployed through automated pipelines, could identify the affected layer and restore clean state in hours. Organisations with manually managed, snowflake servers spent days. The recovery speed advantage had nothing to do with which cloud was involved and everything to do with how deeply the engineering discipline of cloud-native operations had been internalised.
This is the distinction that the multicloud narrative consistently fails to make: the question is not how many clouds you are on, it is how well you have built for the one you are on.
8. What a Sound Cloud Resilience Architecture Actually Looks Like
The architecture that actually delivers resilience for a high-scale, low-latency workload is not complicated to describe, though it is demanding to execute. It starts with multi-AZ deployment within a single region as the non-negotiable baseline: independent failure domains, synchronous replication, sub-millisecond interconnects. For workloads that require geographic redundancy beyond that, multi-region deployment within the same provider extends the model with asynchronous replication and defined recovery objectives, at the cost of some consistency and recovery time that the business has explicitly accepted. For workloads where even that exposure is unacceptable, the answer is not a second cloud. It is genuine physical independence on a purpose-built rail.
That last point deserves more than a passing mention. Decoupling a critical function onto its own independent rail is architecturally quite different from the multicloud argument, and the distinction matters. A card payment network, for example, has operational requirements that are different enough from a cloud-hosted banking application that it justifies its own infrastructure entirely. It is not a fallback target that you fail over to when the cloud has a problem. It is a structurally independent system that continues operating regardless of what the cloud does, because its failure domain is separate by design rather than by routing configuration. The independence is real because the failure domains do not intersect. Multicloud independence is largely theoretical because the failure domains, as we have seen, intersect in ways that are easy to miss and expensive to discover under pressure.
This is the correct framing for resilience decisions: not “should we use two clouds?” but “what are the distinct failure domains in our system, and have we structurally isolated the things that must not fail together?” The answer sometimes leads to a second cloud for specific workloads. More often it leads to better use of the multi-AZ capabilities you already have, to decoupled queuing that absorbs downstream failures gracefully, to circuit breakers and bulkheads that contain the blast radius of a single service’s failure, and to the kind of investment in observability and automated recovery that determines how fast you restore service when something does go wrong.
9. When Multicloud Is Actually Legitimate
A thorough treatment of this subject requires acknowledging that multicloud is not always wrong. There are genuine use cases, and being clear about what they are makes the central argument stronger rather than weaker, because it shows that the critique is not a blanket rejection of complexity but a precise objection to applying multicloud in contexts where it does not hold up.
Stateless workloads at the edge are the clearest case. CDN and DNS distribution across multiple providers is straightforwardly sensible: the workloads are stateless, the latency requirements are different, and genuinely global distribution across independent network paths reduces exposure to provider-specific routing issues. This is multicloud working as advertised, because the constraints that make it impractical for stateful core systems simply do not apply.
Regulatory data residency requirements occasionally force the issue. If a qualifying region does not exist with your preferred provider for a specific jurisdiction, and you have a legal obligation to keep data within that jurisdiction, you may have no choice but to use a second provider for that workload. This is a compliance-driven decision rather than a resilience decision, and it should be understood as such: you are accepting the costs of a spanning architecture because you have no alternative, not because the architecture is sound.
Development tooling and non-critical workloads sometimes have legitimate reasons to span providers, particularly where specific managed services offer capabilities that are genuinely differentiated and where the workload can tolerate the latency and consistency trade-offs that a spanning architecture imposes.
What these cases have in common is that they are specific, bounded, and involve workloads that are not making synchronous calls across the provider boundary. Multicloud is a portfolio strategy, not a runtime architecture. The moment you introduce synchronous cross-cloud dependencies into a latency-sensitive, stateful system, the physics take over and the resilience argument inverts. The mistake is not using multiple clouds ever. The mistake is treating multicloud as a resilience principle that applies by default to everything, when the physics only support it in a narrow set of circumstances.
10. Why the Fallacy Persists
If the technical case against multicloud resilience is this clear, why does the idea persist? The answer sits at the intersection of incentives and abstraction.
Vendors benefit from it. A world in which every enterprise runs workloads across multiple cloud providers is a world in which the management tooling, the professional services, and the training and certification industry all have a much larger addressable market. The multicloud narrative is good for the ecosystem around the clouds even when it is not good for the customers of those clouds.
Governance and procurement processes amplify it. Single-vendor dependency looks like a risk on a risk register. It attracts scrutiny from auditors and regulators who are applying frameworks designed for an era of owned data centres, where vendor dependency meant something physically concrete. Spreading spend across multiple vendors looks like it addresses that risk, regardless of whether it actually does. The risk register gets a green tick and nobody has to understand the physics.
Management abstraction enables it. The further a decision-maker is from the operational reality of running a distributed system under load, the more plausible the multicloud argument sounds. It has the form of diversification, which is a concept that transfers well from financial portfolio theory, and the people approving the strategy are often more familiar with portfolio theory than with the CAP theorem. Portfolio diversification works because the cost of holding additional assets is low and the correlation between their returns is less than one. Neither condition holds for cloud providers: the cost of spanning architectures is high, and many failure modes are environmental or workload-driven rather than provider-specific, making the correlation much higher than the diversification argument assumes.
The result is a generation of architectures that are more complex, more expensive, and paradoxically more fragile than they needed to be, built to satisfy a resilience narrative that does not survive contact with the physics of the systems it purports to protect.
11. The Honest Risks That Remain
None of this is to say that a single-cloud architecture is risk-free. The genuine risks are worth naming clearly, because conflating them with the multicloud resilience argument obscures both.
A regional cloud outage is possible. A sustained failure of an entire provider region would take down everything running in it. This has not happened to a major provider’s regional infrastructure in a way that a well-architected multi-AZ deployment could not survive, but the theoretical exposure exists. If your business cannot tolerate any exposure to that scenario, and if that concern is strong enough to justify the costs and complexity of a spanning architecture, then that is a legitimate engineering decision. It should be made with clear eyes about what the costs actually are, not on the basis of a narrative that elides the physics.
Pricing risk is real and under-discussed. A single-provider dependency means you are negotiating from a position of high switching cost. Over a long enough time horizon, this may prove more consequential than any technical failure mode, and it deserves to be treated as a commercial risk with its own mitigation strategy rather than being folded into a technical resilience argument where it does not belong.
Talent and succession concentration is real. An architecture that is deeply optimised for a single provider’s native capabilities requires engineers who understand that provider at depth. That talent is scarce and mobile. If the people who built and understand the system leave, the knowledge leaves with them. This is addressed by documentation discipline, by infrastructure-as-code practices that make the system legible to someone encountering it fresh, and by architectural choices that favour clarity over cleverness wherever possible. None of those approaches involve a second cloud provider.
These are honest risks. They are also quite different from the resilience argument that the multicloud narrative usually presents, and they require different responses. Treating them as justification for a spanning architecture is a category error that adds the costs of multicloud without addressing the risks that actually exist.
12. What the Conversation Is Really About
The multicloud resilience fallacy is ultimately a symptom of a broader pattern: the tendency to apply frameworks from one domain to another without checking whether the underlying assumptions transfer. Financial diversification works because asset return correlation is meaningfully less than one and the cost of holding multiple assets is low relative to the risk reduction achieved. Cloud provider diversification fails on both counts for the workloads where the argument is most commonly made.
The engineers who understand this tend to be the ones who have operated systems at scale under real failure conditions, who have been paged at 2am when a multicloud architecture failover did not go as planned, who know from experience that complexity is itself a failure mode and that the fastest path to recovery under pressure is a system you fully understand. The executives who propagate the multicloud resilience narrative tend to be the ones who have read about cloud resilience strategy rather than lived it.
Resilience is achieved through isolation and simplicity. Multicloud offers neither. If you cannot survive a failure in one cloud, adding a second will not save you. It will give you more ways to fail and less clarity about which one you are currently experiencing.
That gap between abstraction and operational reality is where a lot of expensive architectural mistakes are made. Multicloud resilience is one of the cleaner examples, because the physics are explicit enough that you can point to the number: 30 milliseconds. That is the latency. That is why it does not work for synchronous stateful workloads. The rest is just the explanation of what the number means, and why no amount of architectural cleverness changes it.