Resilience in the Cloud: Lessons from the AWS Outage on October 20, 2025
The incident that occurred on October 20, 2025, involving Amazon Web Services in the US-EAST-1 (Virginia) region served as a reminder of just how complex it is to maintain operational continuity in global infrastructures that handle millions of requests per second.
Although a localized event, it was capable of triggering a global chain reaction, bringing a key issue back into the spotlight: architectural resilience.
Even in the most advanced environments, design remains the decisive factor in ensuring service availability and stability.
Timeline and Cause of the Accident
The first anomalies were detected late on October 19 (Pacific Time), with the issue accelerating during the early hours of October 20.
AWS identified the root cause of the problem as the DNS services associated with DynamoDB in the US-EAST-1 region.
The issue was not limited to the database but also affected the services that depend directly or indirectly on that resolution mechanism.
Within a few minutes, timeouts and failed health checks caused core components of the AWS ecosystem to become unstable, extending the impact far beyond the region where the issue originated.
Service was gradually restored over the next few hours, but some customers experienced slowdowns and backlogs even after service had officially returned to normal.
In summary, here’s what happened
The outage was caused by an error in DynamoDB’s automated DNS system, which generated incorrect records for the regional endpoint.
This made the service temporarily unavailable, and since DynamoDB underpins numerous other AWS services, a domino effect occurred that affected EC2, Lambda, and Network Load Balancer, resulting in connection errors and delays in new instance launches.
The issue was resolved within about 15 hours, following manual interventions on the DNS systems and controlled reboots of internal components.

Architecture and Resilience: Design Makes the Difference
The incident on October 20 showed that, even in the cloud, service continuity depends on architectural choices.
Not all AWS customers were affected in the same way: the difference lies in how their infrastructures are designed.
Properly deployed systems, multi-AZ configurations, and well-configured failover mechanisms ensure that full operational capability is maintained even in the event of localized issues.
Designing to Prevent
Rather than discussing multicloud or complex redundancy strategies, it’s useful to reflect on how workloads are designed.
The goal isn’t to eliminate every risk, but to minimize its effects by building environments capable of adapting and recovering quickly.
The October blackout sent a clear message: good design is the best form of protection.
Unlike many major platforms—such as Canva, Snapchat, Coinbase, and Roblox —which experienced outages during the event, VMEngine customers, despite operating in the affected region, experienced no impact or service disruption.
This result confirms that resilience is not a characteristic of the provider, but of the architecture: when the design is robust, even unforeseen events can be absorbed without operational consequences.