On 20 October 2025, the Amazon outage exposed how dangerous our global cloud dependency has become for every business, from fintechs to small retailers. When Amazon Web Services (AWS) went down, so did Snapchat streaks, Fortnite servers, banking apps and internal enterprise tools—proving that for many organisations “they down, we down” is literally true. This article unpacks what happened, what the Amazon outage revealed about cloud dependency risk, and what you can do to stay online next time.
Amazon‘s October 20 service disruption exposed the hidden fragility of our digital world: here is what your business can do about it. Snapchat users woke up on October 20, 2025, to find their streaks disappeared. Fortnite players couldn’t log in. Banking apps refused to load. Most people didn’t realise they were witnessing the same crisis. A single point of failure in cloud infrastructure had broken much of the modern internet.
What happened in the Amazon outage?
At approximately 07:55 UTC on 20 October, AWS’s US‑EAST‑1 region in Northern Virginia suffered DNS system failures, impacting one of the world’s most critical data‑centre hubs. Problems in DynamoDB API DNS resolution cascaded into wider issues across AWS’s internal services and global customers.
The list of affected platforms was staggering: Atlassian, Slack, Duolingo, Fortnite, Snapchat, Reddit and Venmo all went offline. Consumer apps like Roblox and Ring doorbells stopped working. Financial services including Coinbase and Robinhood failed. Enterprise tools crashed. Gaming platforms shut down. Even Amazon’s own Prime Video and Alexa devices experienced issues.
Downdetector recorded millions of outage complaints and many business applications were offline for hours. For leaders watching from the sidelines, this Amazon outage was a live demonstration of how concentrated cloud dependency can turn a single technical fault into a systemic incident.
ThousandEyes data showed requests timing out or returning errors, which pointed to backend infrastructure problems rather than wider internet routing issues. In other words, the fault lived inside Amazon’s cloud architecture—not “the internet” as a whole.
What the Amazon outage cloud dependency risk looks like
AWS engineers moved quickly despite the chaos. First they diagnosed and manually corrected DNS and database issues. Then they worked through cascading failures in application logic and state‑management systems.
Service began to recover at around 09:22 UTC, with the core issue largely resolved by 09:35 UTC. By midday, most services were restored, although some customers needed more than 15 hours to fully stabilise while backlogs cleared.
The speed and discipline of the response highlighted Amazon’s engineering strength and incident‑management processes. But it also underscored a hard truth: even when Amazon recovers quickly, organisations with deep Amazon outage cloud dependency can remain offline because their architectures assume AWS will always be there.
Billions lost: the business cost of cloud dependency
Analysts estimate that the October outage collectively cost companies billions in lost productivity and delayed revenue. Retailers saw sudden waves of cart abandonment. Healthcare providers missed telemedicine appointments. Software teams watched CI/CD pipelines stall.
For small businesses, the impact was even sharper. A boutique e‑commerce site processing a few hundred orders a day could lose thousands in a short outage window. These businesses depend on daily uptime for cash‑flow continuity, making cloud dependency not just a technical question but a financial one.
What the Amazon outage revealed about cloud dependency
Bogdan Chaban, an information‑security professional with more than eight years of experience in compliance, risk management and data protection, captured the lesson clearly in his analysis “The AWS Outage and the Reality of Cloud Dependency”.
The failure of a single AWS region (US‑EAST‑1) caused problems all over the world. When giants like Atlassian, Slack and Fortnite suddenly stop working because their main service provider “felt a little sick”, our shared vulnerability becomes obvious. The October Amazon outage transformed cloud dependency from an abstract risk into something every user could feel.
This leads to a critical question: what if Amazon disappeared tomorrow? When one provider underpins such a large portion of global digital infrastructure, their problems rapidly become everyone’s problems. That’s the heart of Amazon outage cloud dependency.
Why reducing cloud dependency is so difficult
Governments and regulators are trying to tackle this concentration risk. In Europe, the Digital Operational Resilience Act (DORA) forces financial institutions to strengthen their digital resilience and scrutinise their critical third‑party providers, including cloud platforms.
But completely escaping cloud dependency is hard in practice:
Cost: Truly resilient multi‑cloud architectures—running active workloads across two or more providers—require significant engineering investment and ongoing operational budget. Most SMEs simply can’t justify this.
Complexity: Even large enterprises struggle with the added architectural, monitoring and incident‑response complexity of multi‑cloud. Migrating, testing and operating in parallel environments is a major undertaking, not a checkbox.
As a result, many organisations knowingly accept Amazon outage cloud dependency as a trade‑off for speed, elasticity and cost‑efficiency.
The “Amazon immunity” effect
A curious thing happened during the outage: most of the public anger was directed at Amazon, not at the businesses whose services stopped working. Even when companies broke their own service‑level agreements (SLAs), users largely saw AWS as the culprit.
This “Amazon immunity” shows how deeply embedded AWS has become. If your service is down only because of an Amazon outage, customers often assume your own product is well‑run and simply a victim of a larger failure. Ironically, that perception makes it easier for organisations to maintain or even increase their cloud dependency on Amazon.
AWS as critical infrastructure
We are moving toward a world where AWS is treated less like another vendor and more like fundamental infrastructure—similar to electricity or the internet itself. If the entire internet vanished, you wouldn’t blame your bank for not loading; you’d accept that something foundational had failed. AWS is creeping into that same category in the minds of many executives and customers.
Riskora client Dmytro Pigul, a compliance and risk‑management expert with more than 15 years of experience, summarised this mindset in one line: “They down, we down.” Those four words describe the practical reality of Amazon outage cloud dependency for most organisations today.
Outages mean lost revenue, operational disruption and reputational risk. Meanwhile, true multi‑provider redundancy remains rare, expensive and technically demanding.
What businesses should do about amazon outage cloud dependency
The October incident offers clear lessons. While you may not be able to eliminate cloud dependency, you can manage and reduce the risk.
1. Regularly back up data
Use automated, geo‑redundant backups.
Store copies in multiple regions or providers, and keep them logically separate from production.
Test restoration regularly so you know recovery works under pressure.
2. Develop disaster‑recovery and business‑continuity plans
Assume another Amazon outage will happen.
Document who does what, how systems are restored, and how decisions are escalated.
Don’t rely solely on the cloud provider’s SLA; treat their failure as a realistic scenario.
3. Consider multi‑cloud or hybrid‑cloud architectures
Where budgets allow, spread critical workloads across regions or providers to reduce single‑point dependency.
Use a hybrid approach—combining on‑premises or private cloud with public cloud—to keep core capabilities under your direct control.
Start with the most business‑critical services rather than trying to move everything at once.
4. Establish clear crisis‑communication protocols
Prepare pre‑approved templates for customer, partner and employee updates.
Host at least one status or communication channel on infrastructure that does not share the same cloud provider as your main stack.
Practise how and when you will communicate during an outage.
5. Test and refine your incident response
Run regular failover drills and game‑days that simulate an Amazon outage.
Review what worked, what didn’t, and update runbooks accordingly.
Track recovery‑time objectives (RTOs) and recovery‑point objectives (RPOs) against real‑world outcomes.
Build real resilience with Riskora
The October Amazon outage was a warning shot for every organisation that relies heavily on the cloud. You don’t need to abandon AWS, but you do need to understand and actively manage your Amazon outage cloud dependency.
Riskora specialises in cloud resilience and business‑continuity solutions. We help organisations:
Design multi‑region, multi‑cloud and hybrid architectures.
Build realistic disaster‑recovery and crisis‑communication plans.
Map hidden dependencies so you know exactly where “they down, we down” risk exists in your environment.
Schedule a consultation with Riskora to start reducing your dependency risk today—because when the cloud breaks, will you be prepared?