99.999% availability allows about 5 minutes 15 seconds of downtime per year, or about 26 seconds per month. That budget includes every failed deploy, certificate expiry, DNS misconfiguration, and provider incident in the request path. One regional outage lasting an hour consumes more than 11 years of five-nines budget.
This guide explains which architecture tiers can reach that number, which cannot, and why. It covers the published SLAs behind each tier, the difference between an SLA and the availability your users measure, and the October 20, 2025 AWS us-east-1 outage as a worked example. If you run in a single region on a single cloud today, it also helps you decide whether you need to go further.
Downtime budgets by availability target
Each additional nine cuts the allowable downtime by a factor of ten. The math uses a 365-day year and an average 30.4-day month.
| Availability | Nines | Downtime per year | Downtime per month |
|---|---|---|---|
| 99.9% | Three | 8 hours 45 minutes 36 seconds | About 43 minutes 50 seconds |
| 99.95% | Three and a half | 4 hours 22 minutes 48 seconds | About 21 minutes 55 seconds |
| 99.99% | Four | 52 minutes 34 seconds | About 4 minutes 23 seconds |
| 99.999% | Five | 5 minutes 15 seconds | About 26 seconds |
The practical consequence: at five nines, you cannot afford a recovery process. A failover that takes five minutes to detect, decide, and execute spends the entire year’s budget in one event. Five-nines systems have to keep serving while a failed location is removed from traffic.
Serial dependencies compound the problem. If a request depends on two services with 99.99% availability each, the combined ceiling is about 99.98%. Add a 99.9% storage dependency and the ceiling drops to about 99.88%. Redundancy only raises the ceiling when the redundant paths fail independently.
Three-tier architecture comparison
Multi-AZ single-region designs reach three to four nines, same-provider multi-region designs reach four nines, and cross-provider multi-region designs are the tier that can reach five nines. The table below follows the structure of the AWS Disaster Recovery of Workloads on AWS whitepaper, which organizes DR options by recovery time, recovery point, and replication approach. RTO and RPO ranges extend the tiers from Cloud Disaster Recovery: RTO/RPO Targets and Best Practices.
| Architecture tier | Achievable uptime range | Typical RTO | Typical RPO | Data replication latency | Shared dependencies remaining | What breaks at each tier |
|---|---|---|---|---|---|---|
| (a) Multi-AZ, single region, single cloud | 99.9% to 99.99% (three to four nines). Component SLAs: EC2 region-level 99.99%, S3 Standard 99.9%, GCP Compute Engine multi-zone 99.99% | AZ loss: seconds to minutes through load balancer health checks. Region loss: hours, bounded by restoring from cross-region backups (batch-tier range of 2 to 4 hours if a pilot light exists) | AZ loss: near zero within the region. Region loss: time since the last cross-region backup, up to 24 hours for batch-tier data | Intra-region: much less than 100 milliseconds (Amazon Aurora, per the AWS DR whitepaper) | Regional DNS endpoints, the provider’s IAM/STS control plane, the region’s DynamoDB-backed control-plane services, regional load balancer and Auto Scaling control planes | Any region-wide service failure takes down every AZ at once. A single regional incident longer than 52 minutes breaks even the four-nines annual budget |
| (b) Same-provider multi-region | 99.99% (four nines). DynamoDB Global Tables publishes a conditional 99.999% SLA, but only for that database service | Warm standby: minutes. Aurora Global Database promotion: under one minute. Active-active stateless tiers: seconds to minutes. Standard-tier targets: 15 to 60 minutes | Cross-region async replication: near zero for active-active. Standard-tier targets: 5 to 15 minutes. Critical-tier targets: under 30 seconds | Cross-region: typically under one second (Aurora Global Database only). DynamoDB Global Tables replication lag is not quantified in the AWS DR whitepaper | A single provider’s IAM/STS control plane, a single provider’s DynamoDB-backed control plane in its anchor region, the provider’s DNS control plane (for example Route 53 record changes), account and billing systems, shared software releases across regions | Failover automation that calls control-plane APIs (Auto Scaling, weighted DNS changes, credential issuance) can stall during a provider-level incident. A defect shipped to all regions fails them together |
| (c) Cross-provider multi-region | 99.999% (five nines) as an architectural outcome, backed by independent failure domains | Stateless tiers: traffic shifts on health failure, near zero in active-active, critical-tier target under 5 minutes. Stateful tiers: set by database promotion logic | Critical-tier target: under 30 seconds. Actual RPO depends on the cross-cloud replication layer and consistency mode | No single published figure. Set by the replication layer you choose (CockroachDB, CDC pipelines, or application-level replication) across provider networks. Measure it in your environment | External DNS provider or registrar, CDN, identity federation (external IdP), internet transit, shared SaaS platforms, software supply-chain components | Cross-cloud stateful consistency, data egress cost, and any external dependency that both providers share. Provider-specific outages no longer take down the whole service |
Tier (a): Multi-AZ, single region, single cloud
This tier handles hardware and data center failures well and cannot absorb a regional service failure. AWS’s EC2 region-level SLA of 99.99% requires instances running across at least two AZs, and GCP’s multi-zone Compute Engine SLA is also 99.99%. Those are four-nines commitments at best. Once you add S3 Standard at 99.9% or other regional dependencies in series, the realistic ceiling sits between three and four nines.
The AWS DR whitepaper states that for workloads where disaster means losing one physical data center, backup and restore may be enough. If your definition of disaster includes losing a region, the whitepaper points you toward pilot light, warm standby, or multi-site active/active in another region.
Tier (b): Same-provider multi-region
Adding a second region from the same provider protects against regional infrastructure loss but keeps the provider’s global services as a shared point of failure. The AWS DR whitepaper itself warns that control planes “typically have higher availability design goals” than data planes only in reverse: data planes are more available, so failover should use only data plane operations. Auto Scaling, weighted routing changes, and Global Accelerator traffic dial adjustments are all control plane operations, per the whitepaper.
Aurora Global Database shows what this tier does well: cross-region replication with typical latency under one second, replication to up to five secondary regions, and promotion to read/write in under one minute during a full regional outage. Those numbers are Aurora-specific and do not transfer to other engines.
Tier (c): Cross-provider multi-region
Running workloads on two or more independent providers removes the provider’s identity, DNS, and control-plane services from the list of shared dependencies. This is the only tier where no single provider incident can exhaust the five-nines budget on its own. The remaining shared dependencies are external: DNS registrars, CDNs, identity federation, internet transit, SaaS platforms, and the software supply chain. Each needs its own resilience design.
The cost is stateful complexity. AWS Aurora and Azure SQL do not replicate natively across providers. Cross-cloud databases need an explicit replication layer, and its lag, consistency model, and promotion logic determine your real RPO.
SLA vs. measured availability
An SLA defines when a provider owes you service credits. Measured availability is the share of time your users could complete requests. The two diverge because SLAs cover one service at a time with conditions attached, while users experience every dependency in the request path combined.
Published per-service SLAs
| Service | Configuration | Published SLA | Source |
|---|---|---|---|
| Amazon DynamoDB | Standard (single-region tables) | 99.99% monthly uptime | AWS DynamoDB SLA, updated May 14, 2025 |
| Amazon DynamoDB | Global Tables | 99.999% monthly uptime, conditional | AWS DynamoDB SLA |
| Amazon EC2 | Region-level (2 or more AZs) | 99.99% | AWS Compute SLA, updated May 25, 2022 |
| Amazon EC2 | Single instance | 99.5% | AWS Compute SLA |
| Amazon S3 | S3 Standard and listed classes | 99.9% monthly uptime | AWS S3 SLA, updated November 28, 2023 |
| Google Compute Engine | Multi-zone instances | 99.99% | Google Cloud Compute Engine SLA |
| Google Compute Engine | Single instance, Memory Optimized | 99.95% | Google Cloud Compute Engine SLA |
| Google Compute Engine | Single instance, other families | 99.9% | Google Cloud Compute Engine SLA |
| Google Cloud Load Balancing | Standard | 99.99% | Google Cloud Compute Engine SLA |
Azure SLA figures for virtual machines, Cosmos DB, and Blob Storage were not confirmed in our research for this post. Check Microsoft’s published SLA pages directly before comparing Azure services against the figures above. We also could not confirm a GCP database SLA at the five-nines tier.
Two patterns stand out. First, none of the core compute or storage primitives (EC2, S3, Compute Engine) publish a five-nines commitment. Second, the one five-nines SLA in the table, DynamoDB Global Tables, applies only when every table in the region is part of Global Tables for the full billing cycle and the customer makes reasonable attempts to fail over during a single-region issue. It covers that database, not your application.
SLA credits do not cover the outage
SLA credits reimburse a percentage of the monthly charge for the affected service. They do not compensate for lost revenue, SLA penalties you owe your own customers, engineering hours, or reputational damage. A service that costs a few thousand dollars a month can sit in the path of revenue many orders of magnitude larger.
The gap is growing. Oxford Economics and Splunk’s The Hidden Costs of Downtime research put the annual cost of downtime for Global 2000 companies at $400 billion in 2024, equal to 9% of profits. The 2026 edition raised that figure to $600 billion, a 50% increase in two years. Both editions surveyed 2,000 Global 2000 executives.
If your availability target exceeds what your providers contractually commit to, the difference is risk you carry.
Extending the RTO/RPO tiers to availability targets
The cloud disaster recovery guide defines three workload tiers by RTO and RPO. Mapping those targets against downtime budgets shows which architecture each tier requires.
| DR workload tier | Target RTO | Target RPO | Availability target it supports | Architecture tier required |
|---|---|---|---|---|
| Critical (payments, auth, customer APIs) | Under 5 minutes | Under 30 seconds | 99.999%, if the RTO applies to routing around a failure with no user-visible outage | (c) Cross-provider multi-region, active-active |
| Standard (internal tools, reporting, non-transactional APIs) | 15 to 60 minutes | 5 to 15 minutes | 99.99% with at most one incident per year at the low end of the RTO range | (b) Same-provider multi-region, warm standby |
| Batch (data processing, background jobs) | 2 to 4 hours | Up to 24 hours | 99.9% or lower | (a) Multi-AZ single region with cross-region backups or pilot light |
One detail matters here. A 5-minute RTO is compatible with five nines only when failover is a traffic-routing event that users do not see. If every regional failure causes 5 minutes of visible downtime, a single incident per year breaches five nines.
Control Plane’s five-nines SLA
Control Plane offers a 99.999% SLA, backed by a minimum of two replicas in two locations. Those locations can sit on different cloud providers, which places the replicas in separate provider failure domains. The SLA reflects the architecture-level outcome in tier (c) instead of a single-service commitment inherited from one provider.
The October 20, 2025 AWS us-east-1 outage
The October 20, 2025 us-east-1 incident showed how a failure inside one provider’s internal dependency can cascade across many services in a region, which is why single-provider architectures cap out below five nines.
According to AWS’s public post-event summary, a latent defect in DynamoDB’s automated DNS management system left the regional DynamoDB endpoint in us-east-1 with an empty DNS record. Clients, including other AWS services, could not resolve the endpoint. Services that depend on DynamoDB internally failed in turn. EC2 instance launches, Lambda, and other services were impaired, and some impairments persisted after DynamoDB’s DNS record was restored. The disruption lasted multiple hours.
What the incident means for each architecture tier:
- Tier (a): Multi-AZ deployment did not help. The failure was regional, so every AZ in us-east-1 lost the same dependency at the same time.
- Tier (b): Workloads in other AWS regions were insulated from the regional DynamoDB failure only if nothing in their request path or failover automation depended on us-east-1 endpoints or on control-plane actions that were impaired. Any recovery step that needed to launch EC2 capacity in the affected region would have stalled.
- Tier (c): Workloads with healthy replicas on another provider could route traffic away from the affected locations. The AWS incident removed capacity from the pool without removing the service.
The math makes the point. At multiple hours, the incident represented decades of five-nines budget for any workload that depended entirely on us-east-1. This follows an earlier pattern: in December 2021, a us-east-1 degradation impaired STS and control-plane APIs that recovery automation relied on, as covered in the cloud disaster recovery guide.
Do you need to go multi-cloud?
Most workloads do not need five nines, and multi-cloud is headroom you add when a workload’s cost of downtime justifies it. Start by tiering your workloads, then match each tier to the cheapest architecture that meets its target.
A single region on a single cloud is a reasonable choice when:
- The workload is batch or internal, with RTO measured in hours.
- Your users can tolerate roughly 8 to 52 minutes of downtime per year.
- Regulatory or data-residency rules keep data in one region, and you accept the regional risk.
Consider adding a second region or a second provider when:
- A single hour of downtime costs more than a year of running redundant capacity.
- Your contractual SLAs to customers exceed your providers’ SLAs to you.
- Your failover runbook depends on the same provider’s identity, DNS, or control-plane APIs as your primary environment.
The useful property of a platform like Control Plane is that the decision is reversible. You can run in one location today and add a location on another provider later without rearchitecting your workloads.
How Control Plane supports five-nines architectures
Control Plane is a cloud virtualization platform that runs workloads across AWS, GCP, Azure, Oracle, and private infrastructure through one API.
The capabilities that matter for tier (c):
- Global Virtual Clouds (GVCs): A GVC groups locations across providers into one deployment scope. Add a location on a second provider and workloads deploy there automatically.
- Health-aware geo-routing: Readiness probes remove unhealthy replicas from the routing pool. Location-level health checks shift traffic to the next-nearest healthy location. The
routingTiersetting configures active-active or primary/failover topologies. - Universal Cloud Identity: Workloads assume native identities on AWS, GCP, and Azure at runtime to reach services such as S3, RDS, BigQuery, and Cosmos DB, with no long-lived credentials stored in images or configuration.
- Workload types: Control Plane runs serverless, standard, stateful, cron, and VM workloads, all as containers. It also offers managed Kubernetes and bring-your-own-Kubernetes (BYOK).
- Isolation: Each workload runs with Kata Containers on per-workload Firecracker microVMs.
- Cost: Dynamic scaling, scale-to-zero, and Capacity AI resource packing deliver 30-50% cost savings, which offsets part of the cost of running redundant capacity across providers.
- Compliance: Control Plane holds PCI DSS Level 1 and SOC 2 Type II, and supports HIPAA and GDPR requirements.
Control Plane complements Terraform and Pulumi. Dedicated providers exist for both, so teams can declare GVCs, workloads, and routing in the same pipelines they already use. Explore the product overview or watch the product demos to see cross-provider failover in practice.
Frequently asked questions
What does five-nines uptime mean in practice?
Five-nines uptime means a service is available 99.999% of the time. That allows about 5 minutes 15 seconds of downtime per year, or about 26 seconds per month. A single incident that takes five minutes to detect and fail over consumes almost the entire annual budget, so five-nines systems need enough redundancy to keep serving while a failed location is removed from traffic.
Can a single cloud deliver five-nines?
A single cloud rarely delivers five nines for a full application. Core primitive SLAs top out below that level: Amazon EC2 region-level is 99.99%, Amazon S3 Standard is 99.9%, and Google Compute Engine multi-zone instances are 99.99%. DynamoDB Global Tables publishes a conditional 99.999% SLA, but it covers only that database service. Same-provider multi-region designs still share the provider’s identity, DNS, and control-plane services, which is why they typically cap at four nines. Reaching five nines usually requires replicas running on at least two independent providers.
What is the difference between SLA and measured availability?
An SLA is a contractual commitment that defines when a provider owes service credits. Measured availability is the percentage of time your users could successfully use your application, observed from your own monitoring. SLAs cover individual services with conditions attached, while measured availability reflects every dependency in the request path combined. SLA credits reimburse a fraction of the monthly bill for the affected service and do not compensate for lost revenue or recovery costs.