What Recent Cloud Outages Teach About Reliability
Srini Srinivasan is founder and CTO at Aerospike, a real-time NoSQL database for mission-critical use cases and workloads.
In October 2025, AWS experienced a major outage that lasted about 15 hours, disrupting thousands of applications and digital services worldwide. The event continues to serve as an example of how enterprises evaluate cloud reliability and of the significant divergence between an organization’s expectations and the outcomes of an outage.
In just the past 10 years, cloud providers have developed an exceptional number of capabilities. Regions, availability zones, cross-region replication, automated backups, traffic routing and health checks allow enterprises to achieve an unprecedented level of high availability. We’re discussing 99.99% or higher availability. The tools are in place, but ultimately it’s about how we use them.
Why Reliability Begins With Design
When an outage occurs, it’s easy to blame the provider. The real issue is whether an application has been built to survive it. A region can fail for various reasons, including network congestion, DNS issues, load balancer problems or a cascading software error. These are rare, but they happen. The enterprises that maintain service during those events are the ones that have already planned for them.
One principle I’ve followed throughout my career is to design for failure. That means asking at the beginning of an architecture what happens if a region disappears. From there, you test, simulate and measure how long it takes to recover, so you learn what it takes to bring the system back.
This isn’t a new idea. When I worked on large-scale systems previously, we operated global services with no tolerance for system downtime. We assumed that at least one failure would occur somewhere every day. In some cases, the failure was due to a loss of connectivity to one of the data centers or a regional outage. To achieve this, we configured the traffic so that when a region suffered an outage, requests would automatically be redirected to another region and users would never see an error page. That level of resilience doesn’t happen by accident. It’s engineered through preparation, repetition and design discipline.
Modern cloud infrastructure gives you complete control over designing your application for resiliency. You may deploy in multiple regions, creating either an active-active or active-standby setup. Synchronous replication provides the same level of strong consistency across all locations with increased write latency, while asynchronous replication provides lower write latency with the potential that some data may take longer to sync (lag) after a failover, providing eventual consistency.
If they’re done deliberately and thoroughly evaluated, both methods may yield satisfactory results for a specific deployment. The most important thing you can do is determine from the beginning what your application can tolerate in terms of recovery behavior, and design accordingly.
There’s also a business dimension to reliability. Setting up a system for near-constant uptime (e.g., 99.999% uptime) incurs a cost. Running an application across several regions, with duplicate data and compute, is expensive. It takes more time to design, and the cost runs continuously, even if failures are rare. Each enterprise has to decide what level of availability justifies that investment.
Rethinking Multicloud
When there’s a major outage that makes the news, people often think of multicloud as the solution. The idea is that if workloads are distributed across multiple providers, there will be no single point of failure. Aside from maintaining uptime, the value of multicloud is flexibility and independence from a single provider. Most cloud platforms currently have sufficient redundancy to meet stringent availability goals.
Building the same system across multiple clouds adds complexity and cost that only pays off when there are broader strategic reasons, such as negotiation leverage, data sovereignty or vendor diversification. The smarter approach is to use software and data layers that already operate across clouds. Databases, orchestration platforms and container systems that operate natively across multiple environments give you flexibility without the burden of managing several infrastructure stacks. That’s a practical multicloud approach that preserves reliability while keeping the architecture manageable.
Visibility Beyond The Provider
Monitoring also plays a significant role in resilience. Cloud providers offer excellent observability tools, but enterprises still need independent visibility. They should be able to monitor services from outside the cloud. They may not always be able to assess how users are experiencing service during an outage solely from internal dashboards. External monitoring, synthetic testing and application-level health checks help validate that failover worked as intended. Observability is about understanding behavior from both inside and outside the system.
Making Outages Uneventful
Every cloud provider will experience some form of failure eventually. The nature of a distributed system at a massive scale means outages will occur. The goal is to make such events occur seamlessly so that users are unaware when a region goes down. That’s real reliability.
The AWS outage in 2025 served as a reminder that reliability is a shared responsibility. The provider maintains the underlying infrastructure, while it’s up to each enterprise to design for failure and implement recovery procedures. All services must be tested as though there will be an outage simulating complete failure. All teams must be aware of the average time required to recover from an outage and the allowable data loss for their particular system. Those metrics are far more important than uptime percentages in a marketing sheet.
Enterprises that treat resiliency as a design principle can incorporate system failures into their regular operations and ensure they have a plan to recover from them. This is how all the most dependable systems in the world have been created.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
