AWS confirms permanently lost data in all three Bahrain zones and one in the UAE

The independence assumption is the part that usually goes unwritten. Multi-AZ keeps a service running because the zones inside a region are treated as independent enough, electrically, physically and on the network, that no single event takes out more than one of them at once, according to the dev.to post ^[8]. Failover inside the region works while that holds. The design covers a single event taking out one zone. One external cause reaching several physical facilities across two regions sits outside it ^[9].

Count the zones named in the confirmation and the figure is four: three in Bahrain and one in the UAE ^[10]. The confirmation of permanent loss arrived roughly six months after the March damage ^[11]. I would not hold a recovery plan open that long on the chance the data comes back.

The post quotes AWS's own dashboard wording, and calls it unusually direct ^[12]. The damage in Bahrain "exceeded what our regional and multi-AZ services are designed to withstand," AWS wrote ^[2].

The post separates two questions that recovery reviews tend to merge. One is whether the plan's scope was complete, meaning every dependency needed to operate sat inside the boundary that was drawn. The other is magnitude: whether that boundary, however carefully drawn, was ever designed to survive the failure that arrived ^[17]. A recoverability boundary, in the post's terms, is the actual size and shape of failure that provider design plus customer recovery plan can survive together ^[16].

Cross-region copies are the standard answer, and they hold under one condition worth stating out loud: the second region shares no dependency the cause can reach. Here a zone in the second region was inside the affected set. The post argues that shared dependency, not distance, defines the failure domain ^[6], and lines the event up with a wildfire earlier this year in which sites separated on paper shared enough underlying infrastructure to fail together ^[13]. The post does not identify that wildfire case or list which AWS services lost resources ^[18].

The post asks for a measurement: the largest class of failure your multi-AZ design was actually built to survive, and whether anyone has confirmed where that ceiling sits instead of assuming it is high enough ^[14]. Its point is that every architecture built on top of AWS inherits AWS's ceiling, written down or not ^[15].