How to Keep Drone Strikes from Blowing Up Your Backups

AWS advertises 99.999999999% annual durability for its S3 Standard object storage. That is eleven nines. “Good enough” most IT teams might reasonably think.

It turns out: Eleven nines may not be enough for your data to survive targeted drone strikes. Throughout March and April 2026, multiple drone attacks damaged AWS infrastructure in the Middle East, leading to a full outage of the AWS Bahrain (me-south-1) region and partial outages in the AWS UAE (me-central-1) region.

AWS later confirmed that they cannot recover data in the Bahrain region:

Sep 15 3:22 AM PDT - 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.

Source: AWS Health Dashboard

This October, Ukraine also struck Yandex data centers in Russia. It is clear that data centers have become strategic targets in armed conflicts.

That leaves practical questions for anyone running a service: How does your data survive a series of drone strikes? And what role can EU clouds play when diversifying your backup locations?

What is really behind Availability Zone labels like eu-north-1a or ap-east-2b? As per the AWS definition, a single AZ may consist of more than one data center. So we cannot reliably pinpoint an AZ to a specific address or building.

Also, something people may not know: The alphabetic AZ identifiers (a, b, c, ...) are randomized across AWS accounts. This means that us-east-2a in your AWS account can be a totally different data center than us-east-2a in another AWS account. It also means that if you have two fully independent AWS accounts, one storing data in us-east-2a and the other in us-east-2b, you may actually be storing it in the exact same building.

A multi-cloud strategy may seem like an obvious way to diversify where your data lives. But different cloud providers can rent space in the same facility.

Finding out where your data actually lives is quite difficult. Most cloud providers are very secretive about their infrastructure details, and you will usually not find a published list of data center addresses.

This means it is also rather difficult to find out which cloud providers share space in the same physical data centers. But if you study the material provided by the data center colocation companies, you can find some hints.

For example, the Chicago CoreSite CH1 data center advertises “on-site cloud on-ramps to Amazon, Azure, Google and Oracle”. Another example is the Equinix PA8 facility in Paris, where financial statements explicitly identify Amazon and Microsoft as colocation tenants.

While this isn't definitive proof of shared infrastructure, it's among the strongest evidence publicly available.

Separate buildings are a useful start. But two separate buildings do not establish separate power supplies, fibre routes or access roads. A damaged bridge, tunnel or highway could delay staff, equipment or fuel reaching both sites.

As a starting point, Germany's BSI recommends about 200 km between redundant sites, with 100 km as the floor when a shorter distance is unavoidable and covered by a documented risk analysis.

If you're looking for a sensible backup location, independent sovereign European cloud providers such as STACKIT and Hetzner are worth considering.

STACKIT operates its own data centers in Germany and Austria, Hetzner in Germany and Finland. Unlike providers that rely on colocation space from major data center operators, both wholly own and operate their own infrastructure. This makes them attractive alternatives for a disaster recovery or multi-cloud strategy without depending on the usual hyperscaler infrastructure, which may have overlaps in the actual physical infrastructure.