Infrastructure
Using multiple cloud providers doesn't automatically make your systems more reliable
Many businesses assume that running on multiple cloud providers protects them from outages. In practice, it usually doesn't — unless the systems were specifically designed to handle it. Here's what real reliability across cloud providers actually requires.
The resilience assumption that doesn't hold
The most common rationale for multi-cloud adoption is resilience. The logic is intuitive: if you run workloads on AWS and Azure, an outage at either provider won't take your business offline. The problem is that this reasoning describes a theoretical architecture — not the architecture most enterprises actually build when they adopt multiple cloud providers. In practice, multi-cloud deployments are almost always multi-cloud by accident. One cloud provider gets adopted for initial infrastructure, a second gets adopted when a business unit prefers a different provider, a third appears when an acquired company brings its existing environment. The result is a portfolio of workloads across multiple clouds, but with no shared resilience architecture connecting them.
What resilience actually requires
Genuine resilience across cloud providers requires four things that most enterprises don't have: workloads designed to run on more than one cloud without configuration changes; automated failover that can redirect traffic between providers in under 60 seconds; data replication that keeps state consistent across environments; and runbooks that have been tested — not just written. Of these, the hardest is the first. Most applications in enterprise environments use cloud-provider-specific services for storage, queuing, secrets management, and monitoring. Migrating a workload from AWS to Azure means replacing S3 with Blob Storage, SQS with Service Bus, Secrets Manager with Key Vault — and then retesting every integration. That is not a failover procedure; that is a migration project.
The architectural decisions that actually create resilience
Building real resilience across cloud providers starts with three architectural decisions made before anything is deployed. First: application state must live in infrastructure that is genuinely multi-cloud — not in a managed database that only runs in one provider's region. This typically means a distributed database with nodes in each provider's environment, or a data layer with synchronous or near-synchronous replication across providers. Second: the network fabric must span providers transparently. Applications should not need to know which cloud they're running on. This requires a service mesh or overlay network that abstracts provider-specific networking. Third: the deployment pipeline must be able to target either provider without changes. If your CI/CD pipeline has hard dependencies on a single provider's APIs, your failover procedure is a pipeline rewrite under pressure.
The sequencing mistake most enterprises make
Most enterprises attempt to build multi-cloud resilience by starting with the compute layer — running identical container clusters in two providers — and then discovering that all the dependencies below the compute layer are single-cloud. The correct sequence is inverted: start with the data layer, then the network layer, then compute. Data is the hardest to replicate reliably and has the longest recovery time objective if not addressed first. Compute is relatively easy to run in two environments once the underlying dependencies are provider-agnostic.
Testing is the only proof
The only way to know whether a resilience architecture works is to test it under conditions that resemble an actual failure. This means deliberately removing one cloud provider from the architecture and measuring the outcome: how long did failover take, what traffic was lost, what state was inconsistent, what manual interventions were required. Most enterprises have never done this test. The ones that have done it have consistently discovered that their resilience architecture works for stateless compute and fails for stateful workloads — because the data layer assumptions were never verified. Build the test, run it in a non-production environment, and fix what breaks before you need to rely on the architecture under real pressure.
Want early access to our thinking?
Subscribe to receive Aethon Core insights as they publish — practical, plain-language content on enterprise technology from people who build it.