AWS outage takes down more than 150 cloud services

On May 7th and 8th, 2026, Amazon Web Services (AWS) experienced an outage affecting Amazon Elastic Compute Cloud (EC2) in the dreaded US East 1 region. The original region of AWS located in Northern Virginia, us-east-1 or just “US East” as it is known, has been the subject of some of the internet’s most high profile and destructive outages and remains Amazon’s least reliable region.

The public AWS Health Dashboard described an event titled “Increased Error Rate and Latency” for Amazon EC2 in N. Virginia, with the issue centered on impaired EC2 instances and degraded EBS volumes in a single Availability Zone, use1-az4.

An Availability Zone (AZ) is a single physical datacenter location, and a region is made up of numerous AZs. Best practices dictate that customers use more than one AZ to defend against issues in a single location. The nature of this outage at a single datacenter meant the impact was not as widespread as past outages, such as the October 2025 AWS incident that took down half the internet.

StatusGator captured 2,370 status changes across 748 services between 12:00 AM and 7:00 AM on May 8, 2026. Some of those were unrelated incidents, scheduled maintenance, or status-page noise. After filtering for status changes that named AWS, us-east-1, use1-az4, EC2, EBS, AWS Health, or language such as “upstream provider,” “cloud provider,” “third-party provider,” or “infrastructure provider,” the downstream reach of the incident became much clearer: More than 150 different cloud services were affected.

What AWS reported

As StatusGator reported, the official AWS status page stated that they were investigating instance impairments in a single Availability Zone, use1-az4, in US-East-1. Later updates described a “thermal event”, elevated temperatures, impaired EC2 instances, degraded EBS volumes, elevated error rates, and traffic being shifted away from the affected Availability Zone. The issue was zonal, not region-wide, but many services had workloads, dependencies, or vendor chains tied to that zone.

A single-AZ incident can still produce widespread symptoms when SaaS providers, payment systems, AI services, messaging providers, data platforms, and customer-facing applications depend on infrastructure or vendors concentrated in the affected area.

How we classified the incidents

As a status page aggregator, StatusGator uses both official status pages and user reports to detect outages. We analyze all the status page data we collected during the incident along with what users reported and divided the affected providers into two confidence levels:

1. Confirmed AWS reference: The provider status text specifically referenced AWS, AWS Health, US-East-1, use1-az4, EC2, EBS, N. Virginia, or an AWS Availability Zone.
2. Likely AWS-related dependency reference: The provider did not name AWS directly, but referenced an upstream provider, cloud provider, infrastructure provider, third-party provider, vendor dependency, or platform provider during the same incident window.

With over 7,000 services monitored, StatusGator detected incidents from all around the world and not all of them are related to AWS. We excluded concurrent incidents that clearly pointed somewhere else, including the Canvas/Instructure security incident, IONOS and Fasthosts WordPress accessibility issues, Vocus and Optus local outages, TurboSMTP’s Amsterdam data-center fire, Dirty Frag vulnerability notices, Microsoft webhook issues, and carrier-specific SMS incidents that did not tie back to AWS.

Services with confirmed AWS references

Services that referenced upstream providers

These services did not always name AWS directly in the captured status text. We include them because their wording matched the incident pattern during the same time window. Treat these as lower-confidence than the confirmed AWS references above.

Early Warning Signals caught many outages first

Official status pages often lag or lie outright. Some providers don’t even publish a status page, a shocking thought in 2026. But during the same incident window, StatusGator’s Early Warning Signals also detected user-reported outages for services that had not necessarily acknowledged an incident on their own status page.

In the captured Early Warning Signals queue, high-volume examples included: FanDuel, Suno, Clubhouse, Epic Games, Moodle, Wattpad, Ancestry, Trello, Infor, Riot Games, Udemy, Signal, Garmin Connect , Upstart, Capital One, Webull, QGend, OverDrive, and D2L.

Some of these incidents would go on to be officially confirmed by providers. But Early Warning Signals use StatusGator’s enormous user base to alert before the providers do.

While these early outage alerts do not prove AWS causality on their own, they show what users were experiencing while official status pages were still quiet or delayed.

What this incident shows about cloud outage visibility

While not as widesperad as some AWS outages, the May 7th-8th AWS US-East-1 incident was not simply an EC2 problem visible only to infrastructure teams. It showed up across payments, AI services, messaging, developer tools, analytics platforms, education tools, ecommerce infrastructure, reservations, data pipelines, and consumer apps.

The status-page language varied widely. Some providers named AWS directly. Some named us-east-1, use1-az4, EC2, or EBS. Others used softer dependency language such as “upstream provider,” “third-party provider,” or “cloud provider.” Still others had user-visible problems without acknowledging an incident at the time StatusGator detected reports.

For IT teams keeping track of their dependencies, StatusGator’s unique advantage is that it watches both official status pages and user reports continuously and keeps them imported. If your team depends on the cloud, give StatusGator a try.