Elevated API issues and Launch Failures (Tokyo)
AWS reports elevated API error rates and launch failures in the AP-NORTHEAST-1 Region. The failures are concentrated in the Availability Zone apne1-az1, with low levels in other Availability Zones. AWS identified the root cause and reports early signs of recovery.
State
Active
Started
Ongoing for
2 h 9 min
Worst impact
Degraded
Timeline
6 updatesActive
2 h 9 min 100%
Updates
Times in UTCAs posted by AWS
We are seeing early signs of recovery for the elevated API error rates and launch failures in the AP-NORTHEAST-1 Region. EC2 and EBS CloudWatch health data is now reporting correctly. We will continue to monitor the progress of our recovery efforts and will provide you with another update by 10:00 AM PST or sooner as new information becomes available.
現在 AP-NORTHEAST-1 リージョンにおいて、API エラー率の上昇および起動失敗が発生しております。起動失敗は引き続き単一のアベイラビリティーゾーン (apne1-az1) に集中しているように見受けられますが、他のアベイラビリティーゾーンにおいても少数の起動失敗が発生しております。 影響を受けているアベイラビリティーゾーンでは、EC2 および EBS リソースの CloudWatch アラームが Insufficient Data 状態に移行しており、Insufficient Data でアラートを発生するよう設定されているアラームは、アラーム状態に移行する可能性があります。影響を受けているアベイラビリティーゾーンにおける DescribeInstanceStatus API は、Insufficient Data を返しております。稼働中のインスタンスに影響はございませんが、インスタンスの正常性は、お客様ご自身のヘルステレメトリーに基づいてご判断くださいますようお願いいたします。 さらに、ECS および Fargate のタスク起動失敗、ELB のプロビジョニング遅延、NAT Gateway の作成および関連付け解除のワークフローの失敗など、他サービスにも影響が発生しております。 根本原因は特定済みであり、現在問題の軽減に取り組んでおります。次回の更新は、日本時間午前 2 時 45 分までに、もしくは新たな情報が入り次第、お知らせいたします。 | We are experiencing elevated API error rates and launch failures in the AP-NORTHEAST-1 Region. While launch failures still appear to be concentrated in a single Availability Zone (apne1-az1), we are now seeing low levels of launch failures in other availability zones as well. Cloudwatch alarms for EC2 and EBS resources in the affected Availability Zone are
We are experiencing elevated API error rates and launch failures in the AP-NORTHEAST-1 Region. While launch failures still appear to be concentrated in a single Availability Zone (apne1-az1), we are now seeing low levels of launch failures in other availability zones as well. Cloudwatch alarms for EC2 and EBS resources in the affected Availability Zone are transitioning into Insufficient Data state and alarms configured to alert off of Insufficient Data may transition to Alert state. The DescribeInstanceStatus API in the affected Availability Zone is returning Insufficient Data. Running instances are not affected, and you should rely on your own health telemetry to determine the health of your instance. In addition, we are seeing impact to other services such as ECS and Fargate Task Launch failures, ELB provisioning delays and Nat Gateway failures for Create and Disassociate workflows. We have identified the root cause and are working to mitigate the issue. We will provide you with ano
We are experiencing elevated API error rates and launch failures in the AP-NORTHEAST-1 Region. While launch failures still appear to be concentrated in a single Availability Zone (apne1-az1), we are now seeing low levels of launch failures in other availability zones as well. Cloudwatch metrics for EC2 and EBS resources in the affected Availability Zone are transitioning into Insufficient Data state and alarms configured to alert off of Insufficient Data may transition to Alert state. The DescribeInstanceStatus API in the affected Availability Zone is returning Insufficient Data. Running instances are not affected, and you should rely on your own health telemetry to determine the health of your instance. In addition, we are seeing impact to other services such as ECS and Fargate Task Launch failures, ELB provisioning delays and Nat Gateway failures for Create and Disassociate workflows. We have identified the root cause and are working to mitigate the issue. We will provide you with an
AP-NORTHEAST-1 リージョンにおいて、API エラー率の上昇および起動失敗が発生しております。起動失敗は、単一のアベイラビリティーゾーン (apne1-az1) に集中して発生していると見受けられます。現在、根本原因の特定および問題の軽減に取り組んでいます。 | We are experiencing elevated API error rates and launch failures in the AP-NORTHEAST-1 Region. Launch failures appear to be concentrated in a single Availability Zone (apne1-az1). We are working to identify the root cause and mitigate the issue.
We are experiencing elevated API error rates and launch failures in the AP-NORTHEAST-1 Region. Launch failures appear to be concentrated in a single Availability Zone (apne1-az1). We are working to identify the root cause and mitigate the issue.
Affected components
34AWS in the last 90 days
Full historyIncidents in 90 days
4
Days with an incident
90
Median duration
2 h 24 min
This incident
About the median
Other AWS incidents
All incidentsAWS·Elevated Launch Failures (Oregon)
AWS EC2 instance launch failures affected all availability zones in the US-WEST-2 (Oregon) Region. Many services in that Region also had failures. AWS resolved the incident after about 2 hours and 24 minutes.
AWS·Region Availability (Bahrain)
AWS reports a major outage in the Middle East (Bahrain) me-south-1 Region. Many services do not work there, including Amazon Simple Storage Service, Amazon Redshift, AWS WAF, and AWS Internet Connectivity. AWS states that resources and data hosted only in this Region cannot be restored.
AWS·Region Availability (UAE)
AWS reports a major outage in the Middle East (UAE) me-central-1 Region. Many services do not work, including Amazon S3 Replication Time Control, Amazon Relational Database Service, AWS Sign-In, AWS Direct Connect, and AWS Secrets Manager. The mec1-az2 Availability Zone cannot be restored, and AWS continues recovery work in mec1-az1 and mec1-az3.
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.live/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.live/feed.xml?providers=aws/feed subscribe https://outages.live/feed.xml?providers=awsFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane