Is AWS down right now?

Check the AWS Health Dashboard, which reports current issues by service and region, and your own account's Personal Health Dashboard for issues affecting your resources. Third-party trackers often report faster but less precisely.

What caused the October 2025 AWS outage?

According to AWS's post-event summary, a latent race condition in DynamoDB's DNS management system left an empty DNS record for the regional endpoint in us-east-1. DynamoDB was unreachable from 11:48 PM PDT on 19 October to 2:40 AM on 20 October, and knock-on failures in EC2 instance launches, Network Load Balancer, Lambda, container services and IAM-based console sign-in lasted until about 2:20 PM PDT.

What happened in the May 2026 AWS outage?

A cooling failure in a Northern Virginia data hall, in availability zone use1-az4, pushed temperatures past safe limits and servers shut down to protect hardware. AWS measured about 20 hours to restore cooling, from 5:25 PM PDT on 7 May to 1:50 PM PDT on 8 May. Services including EC2, EBS, load balancing, NAT gateways, Redshift and SageMaker were affected, and companies such as Coinbase and FanDuel went offline for hours.

How do I protect my business from an AWS outage?

Spread across availability zones at minimum, keep backups in a second region, make your infrastructure reproducible as code so you can rebuild elsewhere, remove hidden dependencies on a single region such as DNS, identity and container registries, decide in advance which failover level you will pay for, and test the restore. A plan you have never run is a guess.

Is multi-region worth it for a small company?

Active-active multi-region rarely is: it roughly doubles infrastructure and adds complexity. What usually is worth it is backups in another region, infrastructure as code, and a rehearsed restore, which turns a regional outage from 'down until AWS recovers' into 'down for the time it takes to redeploy'.

AWS Outage 2025-2026: What Failed and How to Prepare

A data center region with three zone buildings dimmed under a dark cloud and a broken signpost, with a glowing arc carrying a backup package to a smaller region in the distance

The biggest recent AWS outage began late on 19 October 2025, when an empty DNS record took DynamoDB offline in us-east-1 and knocked over EC2, load balancers, Lambda and console sign-in for over 14 hours. In May 2026, a cooling failure in one Northern Virginia data hall shut down servers for about 20 hours and took Coinbase and FanDuel offline. And in March 2026, drone strikes took out AWS's UAE region, which we covered in our Gulf disaster recovery guide. None of this means AWS is unreliable. It means one region, or even one zone, is a single point of failure, and most small companies have built on exactly that. Full multi-region is expensive and rarely worth it at small scale. Below: what failed, why, the affordable middle ground, and what we run ourselves, including the gaps.

What failed

19–20 October 2025, us-east-1, DynamoDB DNS. From AWS's post-event summary: "a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record". DynamoDB's regional endpoint stopped resolving from 11:48 PM PDT on 19 October to 2:40 AM. The knock-on effects ran far longer: failed EC2 instance launches until 10:36 AM, Network Load Balancer connection errors until 2:09 PM, plus Lambda, ECS, EKS, Fargate, Amazon Connect, STS and IAM-based console sign-in. About 14.5 hours end to end. AWS disabled the DNS automation worldwide while it fixed the race condition.

7–8 May 2026, us-east-1, a thermal event in one zone. A cooling failure in availability zone use1-az4 pushed a data hall past safe temperatures, and servers shut down to protect hardware. AWS measured about 20 hours to restore cooling. EC2, EBS, load balancing, NAT gateways, Redshift, ElastiCache, MSK, OpenSearch and SageMaker were affected. Coinbase was offline for about seven hours, and FanDuel went down during an NBA playoff game (Tech Insider's timeline).

There were smaller events too, including a CloudFront DNS failure on 10 February 2026 that lasted about six hours.

What these outages teach

A zone failure is not rare. May 2026 was one availability zone. Companies whose servers and databases all sat in that zone were down for the duration. Spreading across zones would have kept them up.

A regional failure is not rare either. October 2025 was a regional control-plane failure. Being in three zones didn't help, because the shared regional services failed underneath all of them.

The dependencies you didn't choose fail with you. DNS, identity and sign-in, container registries, secrets and CI runners often live in one region, sometimes us-east-1 even when your app doesn't. Any of them can block a recovery.

Recovery time is set by what you rehearsed. A company with backups elsewhere and infrastructure as code can be back in hours. A company whose production was built by hand in a console waits for AWS.

What a small company should actually do

In order of cost:

Spread across availability zones. For databases and clusters, it's a setting and a modest premium. This covers zone failures like May 2026.
Keep backups in another region, and ideally a copy with another provider. Check that the backup isn't stored in the region it protects.
Describe your infrastructure as code (Terraform or similar), so a second region is a deployment, not a project.
Find the hidden single-region dependencies: DNS, identity, registries, secrets, CI.
Choose your failover level in writing. Cold restore (hours, cheapest), warm standby (minutes to an hour, roughly a second small environment), or active-active (seconds, roughly double the cost). Most small companies should pick cold restore and rehearse it.
Run the restore. Put it in the calendar, restore production data somewhere else, and time it. That number is your real recovery time.

What we run, honestly

We host the software we build on Google Cloud, not AWS, in the europe-west1 region by default. We don't think one cloud is immune to this. The same lessons apply to every provider, and to us.

Infrastructure as code. Staging and production are fully described in Terraform, so the platform can be redeployed in another region, or in a client's own Google Cloud project, without reconstructing anything.
Daily database backups, kept seven days. We don't run point-in-time recovery by default. When a project needs a finer recovery point, we configure it for that project.
Resilience sized per project. Multi-zone and a second region are set up per project when the business needs them, and agreed in the scope, so the recovery target and its cost are written down before anything goes live. The rest of how we run production is on our security page.

AI providers have their own version of this. Two of Claude's incidents in October 2026 were billing faults that refused paying customers for hours. What we changed after our own.

AWS Outage: What Failed in 2025 and 2026, and What a Small Company Should Do About the Next One

us-east-1 went down for over 14 hours in October 2025 because of an empty DNS record, and for about 20 in May 2026 because a data hall overheated. Most companies can't afford full multi-region. Here is what they can afford, and what we run ourselves.