AWS reconnaît la perte définitive de données clients après les frappes iraniennes sur ses datacenters de Bahreïn
Le 15 septembre 2026, AWS a admis ne pas pouvoir restaurer l’accès aux données hébergées dans des zones de disponibilité frappées à Bahreïn et aux Émirats arabes unis. Multipliez les régions de réplication et relisez ce que vos engagements de durabilité garantissent réellement.
1er mars 2026. Des drones iraniens frappent les datacenters d’AWS à Bahreïn et aux Émirats arabes unis. 15 septembre 2026. Six mois plus tard, AWS admet qu’il ne pourra pas restaurer l’accès à certaines données clients. Septembre 2026. La durabilité du cloud public vient de rencontrer sa limite physique. Pourquoi c’est important : un hyperscaler a perdu des données de façon définitive, et l’aveu contredit l’intuition que le cloud rend les données indestructibles.
Ce que l’aveu contient
Le 15 septembre 2026, une mise à jour du tableau de bord AWS Health — repérée d’abord par Reuters — reconnaît que l’entreprise est « dans l’incapacité de restaurer l’accès aux ressources et aux données » hébergées dans certains datacenters endommagés par la guerre. La formulation est prudente, mais le sens est clair : des données clients sont irrémédiablement perdues.
Le détail est plus précis que le communiqué. Dans la région des Émirats arabes unis, la perte est localisée à une zone de disponibilité sur trois — la mec1-az2. Les deux autres zones sont en cours de restauration. À Bahreïn, c’est pire : AWS dit ne pas pouvoir restaurer l’accès aux ressources et aux données sur les trois zones de disponibilité de la région.
AWS l’écrit sans détour : « Les dégâts sur 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. » Cette phrase mérite d’être relue deux fois, parce qu’elle constitue un aveu rare de la part d’un hyperscaler.
La chronologie d’un désastre physique
Les premières frappes remontent au 1er mars 2026, dans les jours qui suivent l’ouverture du conflit entre les États-Unis, Israël et l’Iran. Les drones visent les datacenters de Bahreïn et des Émirats. AWS exhorte alors ses clients à migrer vers d’autres régions et à restaurer depuis des sauvegardes distantes.
Une seconde frappe, le 1er avril 2026, se concentre sur Bahreïn. Puis, le 24 juillet 2026, le Corps des gardiens de la révolution islamique revendique une frappe de missiles contre la dernière structure restante à Bahreïn, des dégâts confirmés indépendamment par imagerie satellite.
Face à cette séquence, AWS a suspendu la facturation dans les régions touchées et émis, selon Forbes, environ 150 millions de dollars de crédits clients. Ces gestes atténuent la facture, pas la perte : un crédit ne restaure pas des données qui n’existent plus.
Multi-AZ, mais pas multi-région
L’enseignement technique est direct. La durabilité que vend le cloud repose sur une hypothèse implicite : les pannes sont partielles et récupérables. Un disque meurt, on le remplace. Une zone tombe, on bascule sur une autre. Le modèle multi-AZ est conçu pour survivre à la défaillance d’une zone, pas à la destruction simultanée de plusieurs zones d’une même région par une action cinétique.
C’est précisément la frontière que l’aveu d’AWS éclaire. « Dépassé ce que nos services multi-AZ sont conçus pour supporter » signifie que la garantie de durabilité — le fameux 11 nines annoncé pour S3 — s’applique à des objets répliqués à l’intérieur d’une région, dans le cadre d’une défaillance conventionnelle. Elle ne couvre pas une région entière physiquement détruite par la guerre.
Pour un SRE, la traduction est limpide : multi-AZ n’est pas multi-région. La réplication inter-région et les sauvegardes hors région ne sont pas des options de confort, mais la seule protection réelle contre un événement qui emporte une région entière. Cette leçon n’est pas nouvelle — nous l’avions déjà pointée en analysant la résilience des clouds face aux risques géopolitiques. Elle devient ici un fait d’actualité.
La responsabilité partagée, relue à la guerre
L’incident met aussi en relief le modèle de responsabilité partagée. AWS garantit la résilience de l’infrastructure ; le client reste responsable de la résilience de ses données. Mais cette répartition suppose que les deux parties partagent la même définition du risque. Quand l’infrastructure subit une frappe de missile, la frontière entre « résilience du fournisseur » et « résilience du client » devient floue — et c’est le client qui, in fine, découvre que ses données n’existent plus.
La leçon opérationnelle est simple : lisez vos engagements de durabilité et ne les confondez pas avec une assurance tous risques. Si votre plan de reprise repose sur une réplication intra-région, vous portez un risque que même votre fournisseur ne couvre pas.
Ce qu’il faut faire
La première action est de cartographier la résidence de vos données. Pour chaque charge critique, demandez-vous : dans quelle région tourne-t-elle, et où vivent ses sauvegardes ?
# Lister les régions où vos buckets S3 et vos snapshots résident (exemple AWS CLI)
aws ec2 describe-snapshots --owner-ids self --query 'Snapshots[].{Region:Region,Id:SnapshotId}' --output table
aws s3api list-buckets --query 'Buckets[].Name' --output tableEnsuite, mettez en place une réplication inter-région pour les données que vous ne pouvez pas vous permettre de perdre. Pour S3, la réplication inter-région (CRR) duplique les objets vers une région distante ; pour les bases, une réplication asynchrone vers une autre région remplit le même rôle. L’objectif n’est pas la haute disponibilité, c’est la survie : une copie hors de la zone de danger.
Enfin, testez la restauration. Une sauvegarde qui n’a jamais été restaurée est une hypothèse, pas une sauvegarde. Le scénario à répéter n’est plus « un disque tombe », mais « la région disparaît » : combien de temps pour reconstruire, et avec quelle perte de données ?
Verdict
L’aveu d’AWS du 15 septembre 2026 est un jalon : le cloud public a perdu des données clients de façon définitive, et ce n’était pas un bug, mais une frappe physique. Si vos données critiques vivent dans une seule région, répliquez-les ailleurs dès maintenant — la multi-région est la seule frontière qui résiste à une destruction physique. Si vous êtes déjà multi-région, testez votre bascule et mesurez votre RPO réel : c’est lui, et non les promesses de durabilité, qui dit ce que vous perdez quand la région disparaît. La résilience du cloud a des limites ; celles-ci viennent d’être dessinées à la roquette.