AWS Bahrain Outage: Why Multi-AZ Is Still One Failure Domain

By 16 March, the most solid public record of AWS's Middle East problems was AWS's own status feed, not the louder retellings built on top of it.

What AWS had publicly confirmed by then was already enough. In early March, the company's Middle East regions suffered prolonged disruption affecting both me-south-1 in Bahrain and me-central-1 in the UAE. AWS told customers to enact disaster recovery plans, restore from remote backups, and move workloads to other Regions where needed. 1

That is the useful part of the story. A lot of outage coverage quickly turns into invented precision: exact service counts, exact restoration sequences, exact root causes before a public postmortem exists. As of this article's date, the durable lesson was simpler. A Region is still a shared resilience boundary, even when it contains several Availability Zones.

What AWS had confirmed publicly

AWS's own updates described an initial localized power issue in one Bahrain Availability Zone on 1 March, mes1-az2, that caused connectivity problems, API errors, and degraded service for resources in that zone. By 2 March, AWS was telling customers that recovery would take at least a day and recommending they launch replacement resources in unaffected zones or another Region. 1

The UAE situation involved a different class of failure. On 2 March, AWS said two Availability Zones in me-central-1 were significantly impaired and that both the UAE and Bahrain regions had suffered physical impacts tied to the ongoing conflict in the Middle East. AWS's public notice said two UAE facilities were directly struck and that a strike near one Bahrain facility had also caused infrastructure damage, power disruption, and in some cases fire suppression and water damage. 1

By 3 March, AWS said it would move to more targeted updates through the Personal Health Dashboard for affected customers. That meant the public record was enough to establish the shape of the failure, but not enough to support confident storytelling about every minute and every service. 1

Multi-AZ Is Not Disaster Recovery

AWS's own infrastructure page is clear about what a Region and an Availability Zone are. A Region is a physical location containing multiple isolated, physically separate AZs. Each AZ has independent power, cooling and physical security, and applications spread across AZs are better protected from ordinary data-centre-scale faults. 2

That is real resilience, but it is not the same thing as independence from region-wide physical or political events. If the problem extends beyond individual facilities, such as power, security, access, or conflict, multiple AZs can still be affected by the same event. March's AWS regional outage is a reminder that high availability inside one provider is not the same thing as disaster recovery outside that provider.

AWS's own Well-Architected Framework makes the same distinction. For workloads requiring stronger availability guarantees, this is where multi-Region architecture becomes relevant. Deploying across multiple Availability Zones improves resilience against many infrastructure failures within a Region. Protection from the loss of an entire Region requires a multi-Region disaster recovery strategy. 3

Three things that reduce correlated failure

Three architectural choices reduce that risk.

Different physical geography, meaning a different country on a different grid reached by different fibre, rather than a different AZ in the same metro.

Different legal jurisdiction, because an outage can stop being a hardware problem very quickly.

Different provider, because if your primary and your failover are billed on the same invoice, they share a control plane, a support organisation and an account suspension policy.

Most teams get the first one and stop there. The third is the one people resist because it adds operational work. It is also the one that protects you when the problem is bigger than one vendor's regional design assumptions.

Four countries, four grids

We're a distributed network rather than a single large campus. AVS ISP runs sites in Tirana, Skopje, Amsterdam and Dublin: four countries, four regulatory environments, four separate power and fibre environments.

In practice, that matters for one simple reason. A customer running a €5/mo VPS in Amsterdam and a second one in Tirana has real geographic and jurisdictional separation for the price of a takeaway lunch. You don't need a €50,000 enterprise agreement to buy independence. You need two systems that are unlikely to fail for the same reason.

For customers running their own routing, we operate AS210464 with RPKI validation and a full BGP community set, so you can control where your prefixes are announced from, including selective announcement per region and per peer type, and remote-triggered blackholing when you need it.

If you want to see the network before trusting it, our looking glass runs live ping, traceroute and BGP lookups from every one of our sites. No signup, no sales call.

We are not immune either

We're not going to claim a four-site European network is immune to what happened to AWS in March. Nobody's is. Concentration risk is a spectrum rather than a switch, and we share upstreams and interconnects with everyone else operating in Europe.

What we will say is that the cheapest insurance in hosting remains the oldest one: put your second workload or backup somewhere that cannot fail for the same reason as your first. In practice, it's still one of the simplest ways to improve resilience.

If you want to test that with us, spin up a VPS in a second country and see what it costs. We accept crypto, we don't ask for KYC, and you can be running in minutes.

Sources

1. AWS Service Status RSS Feed, AWS updates covering me-south-1 and me-central-1 on 1 to 3 March 2026
2. AWS Regions and Availability Zones, Amazon Web Services
3. AWS Well-Architected Framework – Disaster Recovery Strategy, Amazon Web Services