Elevated Launch Failures (Oregon)
AWS EC2 instance launches fail in the US-WEST-2 (Oregon) Region. This affects all Availability Zones and services that depend on EC2 or EBS, including Amazon RDS, AWS Fargate, AWS Glue, and AWS Elastic Beanstalk. AWS identified the cause as an issue with an EBS subsystem. The incident is resolved and lasted about 2 hours and 24 minutes.
State
Resolved
Started
Lasted
2 h 24 min
Worst impact
Degraded
Timeline
5 updatesActive
2 h 24 min 100%
Updates
Times in UTCAs posted by AWS
We can confirm EC2 instance launch failures affecting all AZs (usw2-az1, usw2-az2, usw2-az3, usw2-az4) in the US-WEST-2 Region. We have identified the issue to be caused by a subsystem that supports EBS Volumes required during instance launch. Services that instantiate new instances, such as cross-region data copy for DataSync, within the US-WEST-2 Region as either the source or destination are also affected. We recommend that customers do not mutate running instances at this time that would result in the replacement or creation of a new EC2 instance in the Region. Running EC2 instances and already created EBS volumes continue to operate as normal. We are seeing early signs of recovery, and continue to take steps to restore launches within the Region. We will update this post by 5:30 PM PST or earlier if we have new information to share.
We are experiencing elevated launch failures in the US-WEST-2 Region caused by an issue with the EBS service. Services that depend on EBS or EC2 will experience failure rates of their own. We are working to mitigate the issues. We will provide you with another update by 4:00 PM PST or sooner if new information becomes available.
We are experiencing elevated launch failures in the US-WEST-2 Region.
We are experiencing elevated launch failures in the US-WEST-2 Region
Affected components
32AWS in the last 90 days
Full historyIncidents in 90 days
3
Days with an incident
90
Median duration
2 h 24 min
This incident
About the median
Other AWS incidents
All incidentsAWS·Region Availability (Bahrain)
AWS services do not work in the Middle East (Bahrain) me-south-1 Region. The affected components include Amazon Simple Storage Service, Amazon API Gateway, AWS WAF, and AWS Internet Connectivity. AWS reports that the damage exceeded the design limits of its regional and multi-AZ services. AWS states that it cannot restore access to resources and data hosted only in this Region.
AWS·Region Availability (UAE)
AWS reports a disruption in the Middle East (UAE) (me-central-1) Region. Many services do not work in the mec1-az1, mec1-az2, and mec1-az3 Availability Zones. AWS states that it cannot restore resources and data in the mec1-az2 Availability Zone. AWS continues recovery work.
Follow AWS
Your coding agent knows when AWS is down, and tells you when a failure is theirs, not yours. You can also get AWS incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "aws" and tell me if AWS has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.cc/feed.xml?providers=aws/feed subscribe https://outages.cc/feed.xml?providers=awsFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane