AWS admet la perte irréversible de données client dans ses datacenters du Moyen-Orient

1er mars 2026. Des drones frappent les datacenters AWS de la région Moyen-Orient (EAU) me-central-1 ; deux de ses trois zones de disponibilité sont touchées. 30 avril 2026. AWS recommande à ses clients de migrer toutes leurs charges hors de la région. 15 septembre 2026. L’avis de santé des services change de nature : AWS reconnaît qu’il ne pourra pas restaurer les données hébergées exclusivement dans la zone mec1-az2 des Émirats, ni celles du Bahreïn (me-south-1) dans son ensemble. Pourquoi c’est important : c’est la première fois qu’une action militaire provoque une perte de données irréversible chez un fournisseur cloud mondial, et elle met à nu une promesse que beaucoup d’organisations n’avaient jamais testée.

Ce que dit exactement l’avis du 15 septembre

La formulation est prudente mais sans ambiguïté. Pour les Émirats arabes unis, AWS écrit qu’« après une évaluation approfondie, nous avons déterminé que nous ne pouvons pas restaurer l’accès aux ressources et aux données hébergées exclusivement dans la zone de disponibilité mec1-az2 ». Pour le Bahreïn, l’évaluation couvre la région entière : « les dommages subis par notre infrastructure ont touché plusieurs zones de disponibilité et ont dépassé ce que nos services régionaux et multi-AZ sont conçus pour supporter ».

La nuance est capitale. Le multi-AZ, l’argument de vente central du cloud, est conçu pour survivre à la perte d’une zone — pas à des frappes coordonnées sur plusieurs sites simultanément. Reuters a été le premier à rapporter l’information le 15 septembre 2026, et l’événement n’a toujours pas de précédent : jusqu’ici, aucun grand fournisseur n’avait dû reconnaître que des données client étaient définitivement perdues à cause d’un conflit armé.

Une panne qui dépasse le modèle multi-AZ

Le récit technique se lit dans la chronologie du AWS Health Dashboard. Le 1er mars 2026 à 4 h 30 PST, des objets frappent le datacenter de mec1-az2, créant des étincelles puis un incendie ; les pompiers coupent l’alimentation et les générateurs. Le lendemain, une seconde zone (mec1-az3) est touchée, puis un site du Bahreïn. Au 2 mars, AWS décrit explicitement des « frappes de drones » et des dégâts structurels, des coupures d’électricité et des dégâts des eaux causés par la lutte contre l’incendie.

Ce scénario casse l’hypothèse de base de la durabilité. Amazon S3 Standard est décrit dans la documentation comme stockant les objets de façon redondante sur « un minimum de trois zones de disponibilité » avec une durabilité de 99,999999999 % par an. Ces deux propriétés sont régionales : elles protègent contre la panne d’une zone, pas contre la destruction physique simultanée de deux zones ou d’une région. Quand AWS annonce, le 2 mars, que la récupération complète des GET sur les objets antérieurs à l’incident « dépend de la restauration de l’infrastructure affectée », elle annonce déjà, en creux, que la donnée sans copie externe est en danger.

Le trou noir de la résidence des données

La dimension la plus douloureuse n’est pas technique, elle est juridique. Le InfoQ du 21 septembre 2026 rapporte la tension qu’un architecte cloud de T-Systems International soulevait dès mars : déplacer des charges pendant une crise peut restaurer le service, mais pousser des données sensibles hors des frontières nationales, là où la résidence des données est une obligation légale et non une bonne pratique.

Le problème devient insoluble quand la loi impose de garder la donnée dans le pays. Un backup chiffré envoyé à l’étranger ne règle rien si les clés de déchiffrement doivent, elles aussi, rester dans la juridiction pour être utilisables après une perte régionale. Les clients qui n’avaient de copie que dans mec1-az2 ou me-south-1 n’avaient, dans bien des cas, aucune issue conforme : la redondance exigée par la loi entrait en collision avec la redondance exigée par la résilience.

La responsabilité partagée, vraiment

La communauté a moins débattu des frappes que de ce que les clients croyaient avoir acheté. Un extrait d’une interview télévisée de 2025 avec une dirigeante AWS a refait surface sur Hacker News. Interrogée sur ce qui se passerait si quelqu’un identifiait et détruisait un datacenter AWS, sa réponse tenait en une phrase : « ouais, vous ne le remarqueriez pas. Je veux dire, on serait peut-être un peu contrariés, mais vous ne le remarqueriez pas ».

Le commentaire le plus cité du fil résume la rupture de confiance : « des affirmations comme ça sont courantes, elles ont du sens et elles devraient être vraies… c’est vraiment inquiétant quand ils disent que tout ira bien, puis qu’une semaine plus tard ça s’avère faux ». Un autre commentateur, jacquesm, énonce la leçon en une formule : « ils ne réalisent pas qu’AWS est une boîte à outils, pas une solution toute prête de redondance contre toutes les catastrophes auxquelles on est exposé ». Gregor Hohpe, co-auteur d’Enterprise Integration Patterns, ajoute que le risque est « géographique, pas lié à un fournisseur : ceux qui ont pris ME-CENTRAL peuvent tout aussi bien prendre Azure ou n’importe quel autre datacenter ».

Ce qu’il faut faire

L’événement n’est pas clos : au 4 octobre 2026, 144 services restent « perturbés » dans la région EAU, et AWS ne publiera un point détaillé sur le Bahreïn que début 2027. La remédiation, pour un client, tient en quelques actions.

• 1. Auditer le placement réel. Inventoriez les buckets S3, tables DynamoDB, volumes EBS et snapshots qui résident dans me-central-1 ou me-south-1. Ce qui n’a qu’une copie dans la région est, par définition, exposé.
• 2. Répliquer hors région. Activez la réplication S3 cross-région et les sauvegardes RDS/DynamoDB vers une autre région géopolitique. Une copie dans une zone voisine de la même région ne protège pas contre un événement régional.
• 3. Traiter la résidence comme une contrainte d’architecture. Si la loi impose de garder la donnée dans le pays, documentez cette contrainte, cherchez une solution de secours souveraine ou on-premise, et obtenez une décision écrite sur le risque accepté.
• 4. Tester le plan de reprise. Un plan de reprise d’activité qui n’a jamais été exécuté n’existe pas. Rejouez la restauration depuis la région de secours, chronométrez-la, et vérifiez que les clés de déchiffrement sont accessibles là où la restauration se fera.
• 5. Relire les engagements contractuels. Vérifiez ce que votre contrat dit réellement de la durabilité et des crédits de service. La durabilité 11 neuf de S3 est une propriété statistique de la région, pas une assurance contre la destruction physique.

Verdict

Si vous avez des données exclusivement dans me-central-1 ou me-south-1, traitez-les comme déjà perdues tant qu’elles n’ont pas de copie dans une autre région, et lancez la réplication immédiatement. Si vous opérez sous une contrainte de résidence des données, le signal est clair : la résilience géographique doit être pensée dès la conception, avec un plan de secours souverain, car aucune promesse de durabilité ne survit à des frappes coordonnées sur l’infrastructure physique. Si vous pensez être à l’abri parce que vous êtes multi-AZ, cet incident prouve le contraire : le multi-AZ protège de la panne d’une zone, pas de la perte d’une région. La copie hors région, et hors juridiction, est la seule assurance qui tienne.

Références

• AWS Health Dashboard — Operational issue: Multiple services (UAE), mise à jour du 15 septembre 2026
• Reuters — Amazon’s AWS unable to restore access to Bahrain, one UAE cloud data zone after war (15 septembre 2026)
• InfoQ — AWS Cannot Restore Data Held Only in Damaged Middle East Availability Zones (21 septembre 2026)
• Cyber Security News — AWS Says Some Cloud Data Cannot Be Recovered After Data Centers Suffer War Damage (17 septembre 2026)
• The Register / Computing — AWS admits permanent data loss after Middle East datacentre strikes
• AWS — Amazon S3 Data Durability