When AWS Went Dark: Lessons Learned from the 2025 Outage

On October 20, 2025, AWS experienced a large‐scale outage that disrupted dozens of online services and affected hundreds of millions of users globally. This impacted everything from online shops to online video games and most definitely, business operations across the globe. This event serves as a stark reminder of how much modern digital infrastructure depends on a small number of cloud providers, and how even internal operational issues can ripple far beyond the cloud vendor itself. This blog will dive into what happened to cause this AWS outage, and the lessons we can take away from the aftermath.

What Happened

The AWS disruption began in the USA East region of AWS, located in Northern Virginia. This happens to be one of the largest and oldest AWS data-centre regions. 

The disruption began in the US‑EAST‑1 Region (Northern Virginia) region of AWS, which is one of the largest and oldest AWS data-centre regions. AWS identified that the root-cause of the outage involved internal subsystems related to load-balanced health monitoring and DNS resolution. Specifically, an “underlying subsystem that monitors the health of its network load balancers” in the EC2 internal network.  

The outage began early in the morning (US Eastern time) and by mid-afternoon and evening, AWS announced that all services had returned to normal operations. However, some residual backlogs and elevated error rates still lingered. According to the LA Times, the issue manifested as elevated error rates and latency across multiple services hosted by AWS. This included core services such as EC2 (virtual servers), DynamoDB (managed by NoSQL database), API endpoints, and DNS resolution for these endpoints.  

The Negative Impacts

The fallout from the outage was wide‐ranging. Here are some of the major impacts:

Impact on Services and Users

• Many high-profile consumer apps and gaming platforms were affected including Snapchat, Fortnite, Wordle, Duolingo, Venmo, and numerous others reported login errors, inability to load content, delayed responses and complete outages.
• Enterprise and business services and critical infrastructure were also impacted. Banking apps in the UK (e.g., Lloyds Bank, Bank of Scotland) reported issues. Educational services (e.g., the learning platform Canvas) flagged disruption of assignment access and login. Many other business tools such as Zoom and AI services also experienced downtime as a result of the outage.
• The outage exposed a cascading risk: Because so many downstream services rely on AWS‐hosted infrastructure (even if the service is not “AWS” branded), a failure at the cloud provider level caused widespread disruption of the digital economy. Experts called it akin to an “internet earthquake”.

Economic and Reputational Cost

• While precise financial losses are not fully reported, it is reasonable to infer significant cost. The downtime for major apps, lost transactions, productivity loss in businesses, and customer frustration all can end up being incredibly costly for businesses. For example, one article noted that “the financial impact of this outage will easily reach into the hundreds of billions” of dollars when considering the broad ecosystem. 
• For AWS itself and its customers, trust takes a hit. When a cloud provider suffers such a broad incident, customer confidence in availability, reliability and resilience can be shaken. It would not be surprising to see customers turn away from AWS in favour of other cloud providers at this time.

Strategic/Infrastructure Implications

• This outage reinforced concerns about cloud concentration risk. With only a handful of large cloud providers holding enormous sway over global internet infrastructure, this can significantly increase the potential “single point of failure” effect.
• The incident also triggered regulatory and policy scrutiny. For example, in the UK, government officials engaged with AWS about its role in critical infrastructure, and the conversation about classifying such providers as critical third parties was reopened. 

Key Lessons & Takeaways

What should organizations and cloud users learn from this incident? Here are several important lessons:

Design for Cloud Failure

Firstly, businesses need to start designing for cloud failure. Just because your apps are hosted on a market-leading provider (like AWS) does not mean there is zero risk with it. Redundancy, fail-over, and disaster recovery plans must still be a part of your IT strategy and architecture. 

Another key lesson is to use multiple Availability Zones (AZs) and multiple cloud regions (if possible), or even having a multi-cloud strategy to help prevent outages. As well, being aware of which dependencies (APIs, databases, DNS endpoints) are region-specific and designed so that a region failure cannot affect your entire business.

Read our blog about Why Multi-Cloud Strategies are Essential for AI Success to learn more about the advantages of the multi-cloud strategy.

Monitor and Test Resilience

Another key takeaway from this event is monitoring and testing resilience. Incidents like this can result from internal cloud provider problems (e.g., a monitoring subsystem, DNS resolution, internal load balancer services) — and while you may not have direct control over them, you can still test your own resilience. Conduct incident drills. Simulate what happens if your cloud region becomes unavailable. Evaluate how your service fails, how quickly you detect it, how you fail over, how your users are impacted. All of these steps will help you better prepare for a future outage or incident like this one.

Track External Service Dependency Risk

Many organizations assume “we run our own services, so we’re okay” — but if parts of your stack (authentication, database, routing, content distribution) sit on the same cloud provider, you share the risk. A key lesson learned is the importance of maintaining a dependency map – not just your own services, but of the third-party services you use, and their cloud infrastructure dependencies.

Communicate Proactively with Customers 

Next, proactive communication with customers can help reassure them and maintain loyalty and trust. When your service is degraded because of an upstream provider outage (like this AWS incident), your users still perceive “your service is down”. This communication matters. Have a status page, clear messaging, updates to users. In this AWS case, many downstream services reported issues even though they didn’t originate the fault.

Reassess Business Continuity

Lastly, reassess your business continuity, SLAs and contract risk. Service interruptions at the cloud provider level can affect SLAs with your customers. In order to protect yourself and your clients, make sure your contracts reflect realistic risk, define responsibilities. Consider alternative arrangements: a backup cloud provider, a secondary region, a fail-over plan, or even hybrid infrastructure. Being prepared for risk will save you time and money in the event of a disaster.

Wrapping Up

The October 20, 2025 outage of AWS is a textbook case of how cloud infrastructure risk can cascade through the digital ecosystem. While the outage was reportedly caused by an internal AWS subsystem (rather than a malicious attack), the real‐world impact — on social media apps, gaming platforms, banking systems, educational tools, and everyday users — was massive.

For any organization relying on cloud infrastructure (especially large providers like AWS), the takeaway is clear: don’t assume simply using a major cloud provider makes you immune to outages. Architecture, monitoring, resilience, contingency planning — all remain critical.