For the part that concerns us most directly, that is the collapse of the AWS Region in the UAE, here, technically, is what happened. This is meant to be a sort of chronicle and technical detail. If it is of no interest, it can be skipped without any problem, moving on to the final part of the article, where I try to draw some interesting conclusions from this story.
On 1 March 2026, at more or less 12:30 UTC (16:30 Gulf time - GST, 4:30 Pacific Time - PST), during the first wave of missiles and drones launched by Iran, the first AZ (mec1-az2 to be precise, Region me-central-1, in the UAE) is struck by “objects” that cause “sparks and fires”:
one of our Availability Zones (mec1-az2) was impacted by objects that struck the data center
The fire crew ordered the complete cut-off of power to the data center and the shutdown of the generators before moving in to extinguish the fire, in some cases also with the help of water, which inevitably caused further damage to the physical IT infrastructure. Perhaps it is in bad taste in a context of war, but as an old IT guy who has assembled PCs and servers I felt physical pain thinking of the damage to the servers, from the brutal power cut first and the dousing with water afterwards.
In the meantime, and probably before it was clear to everyone what had happened, “standard” countermeasures were applied, which I imagine are designed precisely for incidents involving a single Availability Zone, such as changing the traffic-balancing weights to send it to the data centers in the healthy zones.
Even from AWS’s messages alone, however, it is clear that the 3-AZ model makes it possible to survive the loss of one zone, but it is not painless. Several services do not work correctly, API calls fail and AWS’s own suggestion is to keep trying or to change Region. After all, what else could they suggest?
What I noticed, in effect (in the descriptions, I was not directly involved in this event), was a repeat of an AZ outage in the eu-central-1 Region in Frankfurt in 2019: APIs failing, EC2 instances unable to start because of the overload of requests (both from automated jobs and from poor sysadmins/devops/engineers/those desperately trying to restore brutally interrupted services), slowed-down networking.
An interesting point is that 5 hours passed between the first messages about problems and the confirmation of the first drone impact. Honestly, I understand the need to activate the emergency management teams (the fact that the notices were in PST makes me suppose these things are handled in California, and so at 4 in the morning the people not on duty were probably still asleep), the inevitable confusion, the need for communication that is as clear and managed as possible, coming from someone who does that for a living (indeed the message was picked up by newspapers all over the world), but 5 hours still seems too long to me for an event of this kind.
Another interesting point, the detail about the configuration change released specifically to mitigate the IP assignment errors (evidently a significant part of the problems encountered) and the fact that “DescribeRouteTable and DescribeNetworkInterfaces API calls without specifying zone, Interface or Instance IDs” would fail until the zone was restored and therefore had to be modified. This leads me to two reflections:
- an important architectural lesson: even a small detail, such as specifying one parameter more rather than one fewer in an API call, can mean fewer problems and less confusion at the most critical moments, that is, when confusion is at its peak and the pressing need is to untangle the web of problems preventing you from restoring the service. A little less laziness, a little less superficiality, a little more study, can mean a much smaller web of problems.
- apparently in about 4 hours a problem with API calls was identified, a solution developed (even if just a fix) and released in an AWS REGION. In an emergency things can be done faster and with fewer constraints, but a reaction (debug, develop, release!) this fast will never cease to amaze me. Who knows what levels of automation have been reached. Just as a reminder (to myself first of all) that it may be complicated, but something this exceptional can be done.
At 02:01 UTC on 2 March (18:01 PST on 1 March), the messages on the Health Dashboard turn optimistic. I can picture the scene, we have probably all lived through similar situations, with the team tired but satisfied after more than 12 hours: EC2 can be restored, we’ve fixed the APIs, we’re providing support to speed up some migration activities, communication has been good, there was a big problem but we’ve made it, it’s plain sailing from here, even if nobody yet knows when the AZ will be restored.
Unfortunately, as Kurt Vonnegut wrote, “so it goes”, that is not how it is. The war did not end with the resolution of the incident.
At 05:56 UTC (09:56 in the Gulf - GST, 21:56 Pacific Time PST) for the me-south-1 Region, Bahrain, and practically simultaneously (3 minutes later according to the Health Dashboard) again for the me-central-1 Region, UAE, connectivity problems and “increased API error rates” are reported, which is another way of saying big problems.
In Bahrain (Region me-south-1, Availability Zone mes1-az2) what happens is essentially a replica of what we saw before, minus the release of the fix to sort out the networking. After a few hours, on 2 March 2026, the situation seems not to be so serious:
In me-central-1, on the other hand, it is a catastrophe. To paraphrase the scene from Titanic, an AWS Region can carry on with one Availability Zone unusable, not two.
Two AZs impacted means that S3 and DynamoDB, the two most essential AWS services, fundamental also to the internal workings of the AWS Region itself, no longer have the redundancy they need to work correctly. It is not me saying they are essential, it is AWS saying so (in a later message).
The Management Console too can no longer work correctly. The Region is not completely dead, the EC2 instances in the only remaining AZ are still running, but the situation is clearly compromised and the only thing to do is abandon ship, as AWS itself says more than once:
Translating from tech-speak: activate your disaster recovery plans and restore somewhere else. Save your data somewhere else. Writing to and reading from S3 and DynamoDB is not reliable in this Region. Even more concisely: run, it is no longer safe here. And this time, not just at the IT level, for that matter.
An important point: AWS Backup backups (and to be honest those of most of the backup systems I have seen in the cloud) are stored on S3, hence, if they are not in different Regions, they have the same problems when it comes to restoring.
From here on, AWS’s efforts to try to contain the situation focus on restoring the Management Console and the functionality of the various backup services.
One small interesting thing that emerges is that the Management Console does not seem to be, to put it crudely, a single site, but a constellation of more or less independent sections, so much so that at a certain point they report having managed to restore only part of it.
On 3 March 2026, at 00:19 UTC (04:19 GST, 16:19 PST on 2 March), we finally have an official statement. It is confirmed: 2 data centers in the UAE were hit by drones, while in Bahrain the impact was in the immediate vicinity.
It is confirmed that the focus is on restoring S3 and DynamoDB, including with ad hoc changes allowing the services to run with a single AZ and with the remaining infrastructure, because this would allow the cascading restoration of other services. However, the restoration can only be limited: part of the physical infrastructure has been damaged, and it is the hardware itself that has to be repaired or replaced.
The final warning, inevitable: the war is not over, it goes on. Operating under these conditions cannot happen with the predictability that IT services require in most cases. We suggest, if possible, that you move to other Regions. If you want suggestions, the US, Europe, Asia Pacific.
During the day on 3 March 2026, after a few updates on the progress of the mitigation operations, AWS decided to suspend global communications, limiting them to those with workloads in the affected Region.
A short space for interesting developments that occurred after the article was written
On 30 April 2026, after almost two months, this announcement is published:
We should not expect a resolution before “several months”. Some workloads apparently continue to work normally (which ones? EC2 in the AZ that was not hit? I found no further information) but the guidance remains the same as on 3 March: migrate all resources still accessible to other Regions. Making the exceptional nature of the situation plain (if there were still any need), it is stated that “Relevant billing operations are currently suspended while we restore normal operations in this AWS Region.”, which I interpreted as “operations relating to migration to other Regions are not charged”.
Worth noting, probably following the attack of 1 April, this notice was also published for the Bahrain Region.
Alright, an entire Region down, and another one hit several times. But in practical terms, let’s take a few examples, what were the consequences for end users? Unfortunately there are not very many accounts that unequivocally describe outages related to the bombing, and it seems that almost nobody explicitly linked their problems to the bombings. Still, something can be found.
Several banking services turned out to be down, particularly internet and mobile banking services:
- Abu Dhabi Commercial Bank (ADCB) - their announcement reports that due to a region-wide IT problem (“a region-wide IT disruption”) mobile banking and contact centre services are unavailable. Interesting that internet banking and ATMs, on the other hand, continued to work correctly. We can reasonably deduce, though obviously not with absolute certainty, that they were using Amazon Connect for the contact centre and a limited set of services just for the mobile app (Cognito? SNS platform?) while internet banking was probably in a data center of their own or in any case had a level of redundancy suited even to the loss of an entire Region (Zawya - UAE lender ADCB hit by technical glitch affecting users and The National - ADCB restores digital banking services after 48-hour disruption)
- First Abu Dhabi Bank, the largest bank by assets, stated that it was having technical problems with internet and mobile banking. Al Fardan Exchange (a money transfer service) stated that its services had suffered a temporary interruption. (Khaleej Times - UAE banks, financial firms face temporary service disruptions)
- CNBC reports problems with some consumer services, such as Careem, a delivery and taxi company, and Alaan and Hubpay, two payment services (CNBC - Iran war: UAE drone strikes hit AWS data centers)
- The only incident report (at least, that I found) is from Snowflake, which states that customers hosted in AWS - Middle East (UAE) may be unable to access or use more than one core Snowflake service. The last message, on 15 May, effectively relays AWS’s official guidance to stop using the Region, and consequently removes it from the available Regions (Snowflake Status - AWS - Middle East (UAE): INC0152681)
A couple of brief considerations on all this: even though we have no news about the myriad of minor and much smaller services that probably suffered catastrophic or near-catastrophic impacts, the major or more important services (that is, large companies or multinationals) seem to have recovered in a relatively short time. It gives me a degree of confidence that the practices of operational resilience, disaster recovery, off-Region backup and the like are by now finally widespread enough to allow a relatively quick reaction (if 48 hours can be considered quick, and for a bank they certainly can) even to situations of this kind.
How shall I put it, you don’t notice it, but over the last 10-15 years reality has broken through even to the most obtuse management and infrastructures really are now more robust, or at any rate recover more easily. Maybe it’s a bias of mine: over time I have seen a great many slapdash situations, with companies that after 2 weeks had still not managed to restart from their own disaster recovery, and probably these situations in the Middle East don’t make the news in Europe, but in any case I am left with a note of hope in this mess.
Congratulations on making it this far. Now comes the heaviest part: reflections and final conclusions.
This article was translated from the Italian original with the help of AI (Claude) and reviewed by the author.