AWS is experiencing a service disruption in me-south-1, me-central-1
Increased Error Rates - We are providing an update on the disruption affecting the Middle East (Bahrain) (me-south-1) Region. The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand. After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this Region. When the first Availability Zone was damaged in March, we began recommending that customers migrate their workloads to other Regions, and most did so before the Region became unavailable following the disruption of a second Availability Zone in April. Since then, we have supported the remaining customers in re-establishing their operations in alternate Regions, using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data. In parallel, we assessed all affected infrastructure and exhausted every option for restoring data and resources that had not been migrated before the Region became unavailable. We remain committed to supporting our customers in Bahrain in the long term and will share a further update in early 2027. We have notified the relevant authorities and continue to work with them toward that goal.
Real-time per-service status. Live embeds via updog.ai.
Active incidents · 2
We are providing an update on the disruption affecting the Middle East (Bahrain) (me-south-1) Region. The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand. After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this Region. When the first Availability Zone was damaged in March, we began recommending that customers migrate their workloads to other Regions, and most did so before the Region became unavailable following the disruption of a second Availability Zone in April. Since then, we have supported the remaining customers in re-establishing their operations in alternate Regions, using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data. In parallel, we assessed all affected infrastructure and exhausted every option for restoring data and resources that had not been migrated before the Region became unavailable. We remain committed to supporting our customers in Bahrain in the long term and will share a further update in early 2027. We have notified the relevant authorities and continue to work with them toward that goal.
We are providing an update on the disruption affecting the Middle East (Bahrain) (me-south-1) Region. The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand. After a thorough assessment, we have determined that we are unable to restore access to the resources and data hosted exclusively in this Region. When the first Availability Zone was damaged in March, we began recommending that customers migrate their workloads to other Regions, and most did so before the Region became unavailable following the disruption of a second Availability Zone in April. Since then, we have supported the remaining customers in re-establishing their operations in alternate Regions, using backups where available or implementing alternative solutions to mitigate the impact of inaccessible data. In parallel, we assessed all affected infrastructure and exhausted every option for restoring data and resources that had not been migrated before the Region became unavailable. We remain committed to supporting our customers in Bahrain in the long term and will share a further update in early 2027. We have notified the relevant authorities and continue to work with them toward that goal.
We are providing an update on the ongoing service disruption. The Middle East (Bahrain) Region (ME-SOUTH-1) has suffered damage due to the conflict in the Middle East and is currently unavailable. Customers should recover their resources in other Regions from remote backups. Relevant billing operations are currently suspended while we restore normal operations in this AWS Region. This process is expected to take several months.
We are providing an update on the ongoing service disruptions affecting the AWS Middle East (Bahrain) Region (ME-SOUTH-1). We continue to make progress on recovery efforts across multiple workstreams. With the immediate phase of this event now better understood, we are moving to a more targeted communication model. Going forward, updates will be delivered directly to affected customers through the AWS Personal Health Dashboard. Customers who require assistance with this event are encouraged to contact AWS Support through the AWS Management Console or the AWS Support Center. We continue to strongly recommend that customers with workloads running in the Middle East take action now to migrate those workloads to alternate AWS Regions. Customers should enact their disaster recovery plans, recover from remote backups stored in other Regions, and update their applications to direct traffic away from the affected Regions. For customers requiring guidance on alternate regions, we recommend considering AWS Regions in the United States, Europe, or Asia Pacific, as appropriate for your latency and data residency requirements.
Affected: AWS IAM, AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon CloudWatch, Amazon DynamoDB, Amazon EC2, Amazon EKS, Amazon ElastiCache, Amazon RDS, Amazon Route 53, Amazon S3, Amazon SNS, Amazon SQS, Amazon VPC · me-south-1 · View the live incident timeline → · Official AWS Health status ↗ · Plan for this: Multi-AZ vs Multi-Region →
Post-mortems
What actually broke, why, and what it means for your architecture - every major AWS incident, explained clearly.
A developer running maintenance accidentally deleted Elastic Load Balancing state data in us-east-1. Without that state, load balancers could not be scaled or modified correctly, so a growing share of them degraded over Christmas Eve, most visibly taking Netflix offline for millions of viewers.
7 min read
A brief network disruption made DynamoDB storage nodes re-request their partition assignments from a metadata service at the same moment that larger tables had made those requests slower and heavier. The metadata service could not keep up, storage nodes took themselves out of service, and DynamoDB errors in us-east-1 cascaded into EC2, SQS, and other services.
8 min read
A network change accidentally routed high-volume EBS traffic onto a low-capacity network in one us-east-1 Availability Zone. Volumes lost their mirrors and tried to re-mirror all at once, exhausting capacity and creating a re-mirroring storm that stuck EBS and EC2 for days.
9 min read
A routine capacity addition pushed the Kinesis front-end fleet past an operating-system thread limit in us-east-1. Because Kinesis quietly powers CloudWatch, Cognito, and much of AWS itself, the failure rippled into dozens of services for most of a business day.
8 min read
A latent race condition in DynamoDB’s DNS management automation left the regional endpoint with an empty DNS record. Because half of AWS depends on DynamoDB in us-east-1, the failure cascaded into EC2 launches, Lambda, and NLB health checks for ~15 hours.
9 min read
A degradation in the subsystem that manages Lambda’s execution capacity caused elevated invocation error rates in us-east-1 for about three hours. Because Lambda sits inside so many AWS features - including STS and parts of the console - the blast radius reached far beyond “serverless” workloads.
6 min read
Guides
Evergreen resilience playbooks written from real incident patterns.
AWS often confirms outages after your customers already feel them. Independent monitoring and alerting lets you detect provider incidents first and prove them later.
9 min read
Chaos engineering finds the failures your architecture diagram hides. Here is how to run fault-injection experiments and game days on AWS safely, using AWS FIS.
10 min read
Auto Scaling, health checks, and load balancing do more than handle traffic spikes: configured well, they absorb instance and AZ failures automatically. Here is how.
9 min read
Instant email alerts the moment an AWS incident is detected - with the affected services and regions, not a vague status tweet.
aws