AWS fell over again, and once again it was US-EAST-1 (N. Virginia) that took the rest of the internet down with it. This was not a blip. Snapchat, trading apps, smart home devices, and a long tail of services that most people never realize sit on AWS all went dark or crawled to a halt at the same time. If your week got interrupted by a login screen that would not load, this is probably why.
What actually broke
US-EAST-1 is the region everyone defaults to. It is the oldest, the cheapest in many people’s heads, and the one a thousand tutorials told you to pick. So a huge slice of the internet runs there, including plenty of systems whose owners do not even know they have a US-EAST-1 dependency. When that region has a bad day, the blast radius is global.
The trouble started in the morning: error responses, timeouts, and the kind of latency that makes everything feel broken.
The root cause was DNS. Specifically, DNS resolution for the DynamoDB service endpoint failed, so applications could not resolve the address they needed to reach their database.
If you have never had to explain DNS at 3 a.m., it is the layer that turns a service name into a routable address. When that lookup fails, your application is holding a name it cannot turn into a connection. It does not matter that DynamoDB itself was sitting there ready to serve traffic. If callers cannot resolve the endpoint, they cannot reach it, and every service that depends on those callers starts failing too. That is how one resolution problem cascades into a global outage.
AWS engineers worked the issue, applied fixes, and mitigated the core DNS problem over the course of the day. Recovery was gradual, because once the underlying fault is fixed you still have to grind through hours of backlogged and retried requests before things feel normal again.
UPDATE - October 21, 2025: Incident Fully Resolved
AWS has confirmed that the underlying DNS issues, EC2 impairments, and network load balancer issues have been fully resolved. All AWS services in the US-EAST-1 region returned to normal operations yesterday afternoon (3:01 PM PDT).
For real-time updates on service availability, visit the official AWS Health Dashboard.
The takeaway: one region is a single point of failure
Here is the uncomfortable part. AWS did not do anything wildly negligent. Regions have bad days. This one will happen again, somewhere, to some service, and the only question that matters is whether your architecture survives it.
If your business needs to stay up around the clock, an e-commerce platform or a healthcare application for example, running in one region is a bet that that region never fails. It will.
The fix is a second region you can fail over to, commonly called a disaster recovery site. Which flavor you build comes down to two numbers: your RTO (how long you can be down) and your RPO (how much data you can afford to lose). Those numbers set your budget, not the other way around.
There are three common shapes. They trade cost against recovery time.
Cold site (lowest cost, highest RTO)
Your data lives in the backup region and almost nothing else does. Think S3 cross-region replication for objects and periodic database snapshots copied across regions, with no compute running.
When the primary region fails, you provision everything from scratch: launch the instances or containers, stand up the database, restore the data, wire up networking, and repoint DNS. That is a lot of manual steps under pressure.
Expect an RTO measured in hours, sometimes longer if the runbook has gone stale. A cold site only makes sense for workloads that can genuinely tolerate being offline for a while.
Warm site (moderate cost, lower RTO)
A scaled-down copy of your stack runs in the backup region all the time. The data is the important part: you keep it current with continuous replication, for example RDS cross-region read replicas or DynamoDB global tables, so the standby is never more than seconds behind.
When the primary fails, you scale the standby up to full capacity and shift traffic over with Route 53. Most of the work is already done, so you are flipping a switch rather than building from nothing.
RTO here is typically minutes to a couple of hours, with an RPO close to zero because the data was already flowing. For most businesses this is the sweet spot.
Hot site (highest cost, near-zero RTO)
Full capacity runs in both regions at once. Both are live, both take traffic, and the data is replicated continuously between them. Route 53 health checks pull traffic away from a failing region automatically, often before anyone files a ticket.
This is active-active, and it is not cheap, because you are paying to run your application twice and to keep replication tight enough that either side can take the full load. For banking, trading, or emergency services, that cost is the price of admission. For a lot of other workloads, a warm site gets you most of the resilience for a fraction of the spend.
If your application is genuinely critical, a warm or hot standby in a separate AWS region is the only honest answer. Hope is not a recovery plan.
Multi-region disaster recovery is real engineering, not a checkbox. It means continuous replication, careful network and IAM design across regions, and regular failover drills, because the DR plan you never test is the one that fails on the day you need it.
If you would rather your engineers build product than babysit cross-region replication, that is where we come in. Forged Concepts is a managed cloud service provider that designs, deploys, and runs high-availability AWS architectures, including the disaster recovery strategy behind them. We make sure the failover actually works before the next region has a bad day, not during it.
Do not wait for the next outage to discover whether your backup plan holds. Contact Forged Concepts today and we will pressure-test your architecture.
Frequently Asked Questions
What caused the AWS outage 2025?
DNS resolution failed for the DynamoDB service endpoint, so applications could not resolve their database address. That single failure cascaded into widespread downtime.
Why were so many apps affected?
So much of the internet runs in US-EAST-1, directly or through dependencies, that a regional failure there shows up everywhere at once.
Can outages like this be prevented?
You cannot stop AWS from having a bad day, but a multi-region disaster recovery strategy stops a single-region failure from taking your application down with it.
What is the best option for high uptime?
Warm and hot sites recover fastest. A hot (active-active) setup gives you near-zero RTO at the highest cost; a warm standby gets you most of the way there for less.