Amazon Web Services outage history

Users in the AWS Oregon region began experiencing authentication failures as AWS reported increased API error rates for STS and Sign-In when using SAML. The issue started at 9:12 PM UTC and there was no workaround at that time. AWS stated that their engineering team was automatically engaged at 9:19 PM UTC to investigate the root cause, with updates indicating more information would follow. The disruption affected authentication flows and credential exchange, impacting Sign-In, STS calls, and related IAM identity services in the Oregon region and services that rely on SAML-based sign-in.

The Middle East (ME-CENTRAL-1) region experienced damage tied to the regional conflict, leaving customer applications in that area unable to be reliably supported. AWS advised customers to migrate workloads to other Regions and restore from remote backups where possible. While some workloads in ME-CENTRAL-1 continued to function, the region’s reliability was significantly degraded for an extended period, affecting a broad set of services and resources in that region. Impact began around 1:50 PM UTC and persisted into early September as recovery efforts progressed.

Around 2:12 PM PDT on 2026-09-03, AWS began reporting increased API error rates for STS and Sign-In with SAML in the US-West-2 area, with engineers automatically engaged at 2:19 PM PDT to investigate. There was no workaround available at the time, and AWS committed to another update by 11:30 PM UTC. Over the next hours, partial recovery signs appeared for the impacted STS/SAML APIs in US-West-2, with updates at 11:30 PM UTC and 11:45 PM UTC noting stabilization and error rates returning toward pre-event levels while continuing monitoring.

By 2026-09-10, most services had recovered across affected regions and status updates indicated widespread restoration, with ME-CENTRAL-1 remaining the region facing disruption. Other regions and services gradually returned to normal operation as updates continued and monitoring persisted.

Amazon Web Services (AWS) experienced a regional disruption in the ME-Central-1 region (Middle East, UAE) beginning at 1:46 PM UTC. The damage affected the region's ability to reliably support customer applications, with many services in UAE and Bahrain listed as degraded. While some workloads continued to function, AWS urged customers to migrate accessible resources to other Regions and restore inaccessible resources from backups; some billing operations were affected during the incident. The disruption persisted for most of the day and caused widespread impact across compute, storage, database, and management services across the region.

An AWS regional disruption in the Middle East, ME-CENTRAL-1 (UAE), led to widespread degradation for many services in that region. AWS stated the region had sustained damage and could not reliably support customer applications. While some workloads continued to function, a large portion of services faced interruptions and degraded performance. Customers were advised to migrate accessible resources to other Regions and to restore unavailable resources from remote backups, as some billing operations were affected. A broad set of UAE-region services, including API Gateway and CloudWatch, were listed as degraded during the incident.

An AWS regional incident began around 2:06 AM UTC with increased error rates affecting real-time metrics in AP-NORTHEAST-1. A follow-up at 2:41 AM UTC described damage in the Middle East UAE region ME-CENTRAL-1 that prevented reliable support for customer applications, and AWS urged migrating workloads to other Regions and restoring from remote backups where possible. Some Tokyo-area services (including Amazon Connect) also faced degraded performance during the event but gradually recovered. The issue was regional in scope, impacting authentication and monitoring workflows for users in affected regions.

The incident began around August 18, 2026 after AWS launched a new Availability Zone in EU-WEST-2 (euw2-az4), which led to increased error rates when launching new EC2 instances or creating resources in that region. Existing running resources were reported as unaffected, and AWS recommended using alternate AZs (euw2-az1, euw2-az2, and euw2-az3) to mitigate impact while operations stabilized. The disruption persisted for several days as the new AZ and surrounding services reconciled.

Amazon Web Services Direct Connect users in the EU-CENTRAL-1 region (Frankfurt) faced sustained packet loss and degraded connectivity. The root cause was a facility infrastructure issue at the Equinix FR5 location in Frankfurt, DEU, which left customers with single-site connections particularly affected while those with redundant paths were less impacted. Impact began around 3:46 AM UTC and persisted with ongoing updates for several days.

AWS and its co-location partner undertook a phased remediation across multiple workstreams to restore connectivity, including addressing the facility issue, hardware replacements, electrical isolation, and traffic rebalancing. For immediate recovery, AWS recommended failing over to VPN where available. Over the following days, engineers made incremental progress; full recovery was not guaranteed in the near term at times, with updates continuing until most affected connections were back online by 1:01 PM UTC.

Geographically, the incident was localized to the Frankfurt FR5 site; other Direct Connect locations remained largely unaffected. The incident represented a major disruption for customers relying on that single path, with a long remediation timeline and phased restoration. By the latest update, most connections had recovered and service was returning to normal in the region.

An incident in the EU-CENTRAL-1 region hit AWS Direct Connect paths through the Equinix FR5 facility in Frankfurt, causing elevated packet loss and degraded connectivity for users relying on private network connections. The impact was most pronounced for Frankfurt FR5 paths, with workloads that lacked multi-site redundancy more heavily affected. Separately, the ME-CENTRAL-1 UAE region experienced region-wide reliability challenges due to regional infrastructure damage, reducing available capacity for affected workloads. Impact was geographically clustered around Frankfurt and the UAE, with other regions largely unaffected.

Users in the US-WEST-2 (Oregon) region began experiencing connectivity problems that disrupted a broad set of AWS services, including API Gateway, Direct Connect, EC2, Elastic Load Balancing, VPC, and more. The issue was first acknowledged at 11:45 AM UTC, with ongoing reports of degraded connectivity and increased error rates across affected services.

As mitigation progressed, signs of recovery were noted, and engineers identified a root cause related to routing. Initial recovery signals appeared by 12:00 PM UTC, and by 12:30 PM UTC engineers had completed mitigation efforts tied to a networking device responsible for routing from the region to Seattle Metro. Routes continued to restore and error rates declined as services gradually returned to normal. The incident expanded beyond US-West-2 to impact other regions, including ME-CENTRAL-1 and EU-CENTRAL-1, with periods of elevated packet loss and degraded performance in some locations such as AP-SOUTH-1 during late July and early August.

Starting 4:45 AM UTC, customers relying on AWS Direct Connect in the EU-CENTRAL-1 (Frankfurt) region began experiencing elevated packet loss and degraded connectivity. The disruption affected routing to the Seattle metro across multiple Direct Connect paths at the Frankfurt FR5 co-location facility, with ME-CENTRAL-1 reporting similar issues. There were no customer actions required at the time, and VPN failover was suggested where available to mitigate impact.

AWS and the co-location partner investigated and identified the root cause as a facility infrastructure issue at Equinix FR5 in Frankfurt, DEU. Engineering teams conducted electrical isolation and began a phased remediation, including hardware replacements and backfill as they validated recovery. By 6:01 PM UTC, most connections in the affected paths showed signs of recovery, though a small number of customers remained impacted.

Frankfurt Direct Connect was reported as up by 4:06 AM UTC, with continued progress across related routes and locations as engineers worked to restore full service. Updates indicated that recovery would proceed in stages over the following days as systems were validated and traffic steered to healthy paths, with customers gradually regaining normal connectivity and performance.