Active-active deployment across multiple regions delivers the highest availability you can achieve on a single cloud provider. Active-active across two or more providers is the only model in this ranking that also survives incidents affecting many regions of one provider or a global service at once. Each step up in resilience costs more and adds data-consistency work, so the right tier depends on each service’s tolerance for downtime and data loss.
This guide ranks seven architecture models from single zone to multi-cloud active-active, then tests each tier against aggregate data from 62 major cloud incidents tracked between July 2020 and October 2026.
Disclosure: Control Plane publishes this guide.
TL;DR
- The direct answer. Active-active multi-region on one provider gives the highest single-provider resilience. Active-active across two or more providers is the only model in this ranking that also covers multi-region and global-service failures at a single provider.
- Tiers, lowest to highest. Single zone, multi-zone in one region, backup and restore to another region, pilot light, warm standby, active-active multi-region (one provider), active-active multi-provider.
- What the outage data shows. Of 45 AWS, Azure, and Google Cloud incidents in the Control Plane Cloud Outage Tracker, 27 were confined to one region or smaller, where a second region covers you. The other 18 affected multiple regions or a global service, where a second provider is the safer bet.
- Edge and DNS are a shared dependency. Of 16 incidents at the tracker’s one edge network and DNS provider, 13 hit many locations at once, 11 of them global.
- The data layer sets your RPO. Compute failover can take seconds, but replication lag in your databases determines how much data you lose.
- Cost and complexity generally rise with each tier. Match the tier to each service.
- Where Control Plane fits. On Control Plane, a Global Virtual Cloud (GVC), Control Plane’s named set of locations, runs workloads active-active across regions and clouds from one definition, with health-aware DNS geo-routing.
What is the best cloud architecture model for the highest resilience and availability?
Active-active multi-region is the highest-resilience model available on a single cloud provider. In this model every location serves live production traffic at all times, and each location carries enough capacity headroom to absorb the load of any location that fails. Failover delay is limited to health-check detection and DNS caching, typically seconds, because traffic is already flowing to healthy locations. When a region goes down, global routing stops sending requests there.
Active-active multi-provider extends the same pattern across two or more clouds. It is the only model in this ranking that survives an incident affecting many regions of one provider at once or one provider’s global services, such as identity or the provider’s own management APIs, as long as the shared DNS and edge layer stays up.
Active-passive is a valid trade-off when the data layer cannot support multi-writer replication or when the cost of keeping a second location fully warm exceeds the value at risk. In active-passive, one location serves traffic while a second stays ready to take over. Failover requires detecting the failure, promoting the standby, and shifting traffic. The cost comparison between active-active and active-passive is often closer than teams expect once you account for idle standby spend.
How do the cloud resilience tiers compare?
| Architecture model | Survives | Does not survive | Typical RTO | Typical RPO | Relative cost |
|---|---|---|---|---|---|
| Single zone | Hardware failures handled by the provider within the zone | Zone failure, region failure, provider-wide failure | Minutes to hours | Depends on backups | $ |
| Multi-zone in one region | Single-zone failure | Region-wide failure, provider-wide failure | Seconds to minutes | Near zero within the region | $$ |
| Backup and restore to another region | Region failure (with rebuild time) | Any failure where hours of rebuild time are too long | Hours to days | Hours (last backup interval) | $$ |
| Pilot light | Region failure (with scale-up time) | Failures requiring instant failover | Minutes to hours | Minutes (replication lag) | $$$ |
| Warm standby | Region failure | Failures where minutes of failover time are too long | Minutes | Seconds to minutes | $$$$ |
| Active-active multi-region (one provider) | Zone failure, single-region failure | Multi-region or global failure at the provider | Seconds | Seconds (async replication lag) | $$$$ |
| Active-active across two or more providers | Zone, region, multi-region, and provider-wide failures | Failure of a shared DNS or edge provider; correlated failures across providers; corruption replicated everywhere | Seconds | Seconds (async replication lag) | $$$$$ |
Actual availability at every tier depends on the data layer’s replication design, shared dependencies like DNS and identity, and operational practices including testing and progressive rollouts.
Which architectures would have survived real cloud outages?
The Control Plane Cloud Outage Tracker catalogs 62 major incidents at AWS, Azure, Google Cloud, and Cloudflare between July 2020 and October 2026, each linked to a provider post-mortem or status page.
Of the 45 AWS, Azure, and Google Cloud incidents in the tracker (excluding one that affected a single customer), 27 were confined to one region or a smaller area. A second region at the same provider was outside the affected area in all 27 of those cases. The other 18 affected more than one region or a global service, meaning a second region at the same provider could be inside the affected area.
Median duration was about 14 hours for the 26 single-region incidents with a reported duration and about 6 hours for the 18 multi-region or global incidents. Single-region incidents in the tracker are often physical problems like power or cooling failures that take longer to repair (12 of 27), while multi-region and global incidents are often configuration or software changes that can be rolled back faster (13 of 18).
Of the 16 incidents at the tracker’s one edge network and DNS provider, 13 hit many locations at once, and 11 of those were global. DNS, CDN, and edge providers are a shared dependency across all your regions, so the routing layer needs its own resilience plan.
Failure scope vs. architecture
| Failure scope | Incidents in the tracker | Multi-zone (one region) | Active-active multi-region (one provider) | Active-active multi-provider |
|---|---|---|---|---|
| Single availability zone | A subset of the 27 | Survives | Survives | Survives |
| One region or smaller | 27 of 45 | Survives only zone-level incidents | Survives | Survives |
| Multiple regions or a global service at one provider | 18 of 45 | Does not survive | Survives only if enough active regions sit outside the affected area and no global service you depend on is down | Survives if the second provider is unaffected |
| Edge network or DNS layer | 13 of 16 multi-location (11 global) | Depends on the shared service | Depends on the shared service | Depends on the shared service |
| Your own bad deploy or configuration change | Not tracked | Does not survive alone | Does not survive alone | Does not survive alone |
| Data corruption or deletion | Not tracked | Does not survive alone | Does not survive alone | Does not survive alone |
Replication copies bad deploys and corrupted data to every location, regardless of how many regions or providers you run. Progressive rollouts limit the blast radius of a bad deploy by rolling changes through one cell or location at a time. Immutable backups stored in a separate account are the recovery path for data corruption. These practices are needed at every tier.
What does the highest tier require?
Active-active across regions or providers needs every item on this checklist working together.
- Stateless compute in every location, so any request can be served anywhere.
- Data replication chosen per data store. Synchronous replication within a region for strong consistency. Asynchronous replication across regions to avoid latency penalties. Multi-writer replication only where conflict resolution is well understood.
- Health-based global routing that stops sending traffic to a location when readiness probes fail, with a plan for the DNS and edge layer itself.
- Enough capacity headroom in each location to absorb a failed location’s traffic without degradation.
- Independence from a single provider’s management APIs for failover decisions. If the provider’s management APIs are down, your failover mechanism must still work.
- Cell-based architecture to limit the blast radius of a bad deploy or data issue to one cell before it spreads.
- Progressive rollouts that deploy changes to one location or cell first, validate, then continue.
- Immutable backups stored in a separate account and ideally a separate provider, tested regularly.
- Failover drills run on a regular cadence against production-like environments.
Is multi-cloud active-active worth it?
Multi-cloud active-active is worth the investment when the 18 multi-region or global incidents in the tracker would be unacceptable for your service. That typically means revenue-critical paths where minutes of downtime have outsized financial or reputational impact, regulated or systemic services where regulators require concentration-risk mitigation, and organizations whose risk posture explicitly prohibits single-provider dependency.
For internal tools, batch jobs, and services with a generous downtime budget, multi-cloud active-active is usually more complexity than it is worth.
You need two sets of identity and access management, two networking models, data replication that spans providers, and you pay egress costs for cross-provider traffic. You also need engineers who understand both platforms deeply enough to debug production issues at 3 a.m.
Multi-cloud adds complexity, and complexity itself can cause outages if it is managed by hand. Automated deployment and routing across providers make the model practical.
How do you choose the right tier per service?
Not every service in your portfolio needs the same tier. Align each service to its RTO and RPO budget, then pick the lowest-cost tier that meets that budget.
| Service type | Downtime tolerance | Recommended tier |
|---|---|---|
| Revenue-critical customer path (checkout, API gateway, auth) | Seconds | Active-active multi-region or multi-provider |
| Internal tools (admin dashboards, back-office apps) | Minutes to hours | Multi-zone, or warm standby if region failures matter |
| Batch and reporting (ETL, analytics pipelines) | Hours to days | Backup and restore or pilot light |
| Data platform (warehouses, lakes) | Hours, with low RPO | Pilot light or warm standby with continuous replication |
Running everything at the highest tier wastes money. Running everything at the lowest tier puts revenue at risk.
How Control Plane fits
Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI), VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds. Control Plane handles Day 2 operations for you, including autoscaling, built-in observability, and security.
A Global Virtual Cloud (GVC) is Control Plane’s named set of locations drawn from cloud regions, Kubernetes clusters you register, and your own hardware. A workload deployed to a GVC runs active-active in every location of that GVC from one definition. The locations can be on different providers, so one GVC can span, for example, AWS and Google Cloud regions, which gives the multi-provider tier without running a separate stack per cloud.
Each workload’s canonical endpoint uses health-aware DNS geo-routing to send clients to the nearest location where the workload passes its readiness probes. DNS stops sending traffic to a location that fails. Location routing options set a priority tier per location and latency offsets. Autoscaling sets each location’s replica count between minScale and maxScale, per location.
During the October 20, 2025 AWS us-east-1 outage, Control Plane customers with us-east-1 in their GVC had workloads “active and running in healthy locations within 10 seconds,” with no customer downtime, according to Control Plane’s internal incident telemetry.
The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant. Control Plane customers typically see 30 to 50 percent lower compute costs compared with running directly on AWS, GCP, or Azure.
Control Plane runs the compute and routing tiers active-active, but databases still need their own replication design and set the RPO. Each location still needs headroom to absorb a failed location’s traffic. Bad deploys still need progressive rollouts and backups. See how to run active-active across AWS and Azure without idle standby.
FAQ
These questions come up most often when teams evaluate resilience architectures.
What is the best cloud architecture model that delivers the highest level of resilience and availability?
Multi-region active-active is the top tier on one provider, and multi-provider active-active is the top tier overall. Pick per service: the higher tiers cost more and need more data consistency work, so reserve them for services whose RTO and RPO budgets demand them.
Is active-active better than active-passive?
For near-zero RTO, yes. Active-active limits failover delay to health checks and DNS caching because every location already serves live traffic. Active-passive costs less in steady state but requires a failover step that adds minutes (warm standby) to tens of minutes or more (pilot light) of downtime and introduces risk if the failover path has not been tested recently. For services that can tolerate a brief failover window, active-passive may offer a better cost-to-resilience ratio.
Is multi-zone enough for high availability?
No, not for region-wide failures. Multi-zone survives a single-zone failure, such as a power or cooling problem in one availability zone, but a region-wide incident takes down every zone in that region.
How often do cloud outages affect more than one region?
In the tracker’s dataset, 18 of 45 AWS, Azure, and Google Cloud incidents affected more than one region or a global service. That is 40 percent of tracked incidents.
Does multi-cloud improve availability?
Multi-cloud active-active improves availability against provider-scoped failures. For multi-region or global incidents at one provider, a second provider is the location most likely to sit outside the affected area. Multi-cloud also adds work in identity, networking, data replication, and operational expertise.
What availability can multi-region active-active reach?
No architecture guarantees a fixed number of nines; availability depends on the data layer, shared dependencies, and operational maturity. On Control Plane, the 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. The database tier and external dependencies have their own availability characteristics.
Why do power and cooling outages last longer than software outages?
Physical failures need hardware repair or replacement before anything restarts, while a bad configuration or software change can be rolled back. Across the 45 AWS, Azure, and Google Cloud incidents in the tracker, power or cooling incidents had a median of about 20 hours, against about 6.5 hours for software bugs and about 8 hours for configuration changes.
How does Control Plane run active-active across regions and clouds?
On Control Plane, one workload definition runs in every location of its GVC, which can mix AWS, GCP, Azure, and Oracle Cloud regions. Each location autoscales between the minScale and maxScale values set in Control Plane, and DNS stops routing to any location that fails its readiness probes.
Run active-active across regions and clouds from a single definition. Talk to the Control Plane team or sign up free.
Originally published on the Control Plane blog.
Top comments (0)