AWS outage today? Live AWS status

1. 1

   Read the live status above.

   If the console, S3 or DynamoDB are failing for us too, or reports are spiking, it is an AWS-side event.

2. 2

   Check your own account health.

   The public dashboard shows region-wide events only. In the console, open AWS Health Dashboard, Your account health: it lists events that affect your specific resources.

3. 3

   Check the region.

   Most AWS outages are regional, and us-east-1 (Northern Virginia) is the most common. Note which region your failing resources live in.

4. 4

   Separate AWS from your own changes.

   A recent deployment, expired credentials, an IAM or security group change, or hitting a service quota all look like an outage from inside your app.

5. 5

   Try the CLI.

   If the console will not load, run aws sts get-caller-identity. If it answers, AWS is reachable and your credentials work.

If AWS itself is impaired, you cannot fix it, but you can limit the damage. In rough order:

• Confirm scope first. Which region, which services, which of your resources: your account health page is more precise than any public status page.

• Do not redeploy or scale blindly. During control-plane problems, launching instances and changing configuration often fail or queue. Changes made mid-event can leave resources half-configured.

• Fail over if you planned for it. Multi-region or multi-AZ setups earn their cost here. Shift traffic with DNS or your load balancer to a healthy region.

• Pause retries that make it worse. Aggressive retry loops amplify a regional event. Make sure clients use exponential backoff with jitter.

• Tell your users. Post on your status page that a provider incident is affecting you, with the region and services involved.

• Afterwards, read the AWS post-event summary. AWS publishes summaries for major events. They are the best input for your own resilience plan.

US East (Northern Virginia) is the oldest and largest AWS region. Many global services and many companies run their main workloads there, and some AWS control-plane functions have historically depended on it. When it has a bad day, a large part of the internet feels it.

The lesson every major event repeats: a single region is a single point of failure. Critical systems should be able to run, or at least degrade gracefully, from a second region.

Automation and configuration changes

The 2025 event started with a race condition in DynamoDB DNS automation; the 2017 S3 event with a mistyped maintenance command.

Network and capacity events

In December 2021 an automated scaling activity overloaded internal network devices in us-east-1.

Dependencies between services

AWS services are built on each other. When DynamoDB or the network layer stumbles, EC2 launches, Lambda and load balancers can follow.

Power and facilities

Data-centre power or cooling problems can take out an Availability Zone, which is why multi-AZ designs exist.

The biggest AWS incidents and what caused them. Durations are approximate and come from public reporting and official reviews.

• OCT 20, 2025

  us-east-1: DynamoDB, EC2 launches and load balancers impaired for most of a day

  A race condition in DynamoDB DNS automation broke its endpoint records, followed by Network Load Balancer health-check failures. Source: AWS summary

• DEC 7, 2021

  us-east-1: hours of disruption to the console, EC2, DynamoDB and many customer apps

  An automated capacity-scaling activity triggered unexpected behaviour that overloaded internal network devices. Source: Benzinga

• FEB 28, 2017

  S3 in us-east-1 down for about 4 hours, taking a large part of the web with it

  A mistyped input in a maintenance command removed far more servers than intended, including the S3 index subsystem. Source: BleepingComputer

Every minute our servers request AWS's main endpoints, resolve aws.amazon.com through Cloudflare, Google and amazon's own nameservers, and read health.aws.amazon.com. We combine that with one-tap user reports, filtered for duplicates and abuse: a spike needs at least 12 reports in 15 minutes from 8 or more different networks.

Built to avoid false alarms: a failed request is retried before it counts, a single bad check never says "down" on its own, and a check that fails for reasons on our side is shown as inconclusive rather than as an outage. Limits: we check from one location, so a regional problem may first show up in user reports. Reports store only the problem type, a country code and anonymous codes that change daily; never your IP address. Protego is independent and not affiliated with AWS. Last reviewed October 26, 2026.