Amazon avait adopté un profil bas, donnant peu d’informations
drone, après les attaques iraniennes sur ses data centers. Six mois après les frappes qui ont endommagé plusieurs infrastructures AWS dans le Golfe, Amazon reconnaît qu’une partie des données et ressources hébergées à Bahreïn est définitivement inaccessible. Une zone de disponibilité des Émirats arabes unis est dans la même situation. L’incident remet en cause les hypothèses de résilience du cloud régional et expose les limites du modèle multi-AZ face à un risque géopolitique de grande ampleur.
AWS a confirmé le 15 septembre qu’il ne pouvait pas rétablir l’accès aux ressources et aux données hébergées exclusivement dans sa région de Bahreïn, Middle East (Bahrain), ou me-south-1. La dégradation ne concerne pas une seule salle informatique : les dommages se sont étendus à plusieurs Availability Zones, au point de dépasser ce que les services régionaux et multi-AZ d’AWS sont conçus pour absorber. Amazon prévoit désormais une nouvelle communication sur Bahreïn au début de 2027.
Aux Émirats arabes unis, la situation est plus fragmentée mais tout aussi préoccupante. AWS considère comme irrécupérables les ressources et les données hébergées exclusivement dans la zone mec1-az2, l’une des trois Availability Zones de la région me-central-1. Le groupe tente encore de restaurer les ressources réparties dans les deux autres zones affectées et annonce une mise à jour dans les prochains mois.
Le terme de « panne » devient donc insuffisant. Il s’agit d’un incident de continuité d’activité combinant destruction physique, indisponibilité prolongée, perte potentielle de données et impossibilité de reconstruire rapidement une capacité opérationnelle complète.
Trois sites touchés, plusieurs mécanismes de dommage
Les premiers incidents remontent au début du mois de mars 2026, après les frappes américaines et israéliennes contre l’Iran. Les représailles iraniennes ont visé plusieurs États du Golfe accueillant des bases américaines.
AWS avait alors indiqué que deux de ses installations aux Émirats avaient été directement frappées. À Bahreïn, un drone aurait explosé à proximité d’un site, causant des dommages physiques aux infrastructures. Amazon a évoqué des dégâts structurels, des interruptions de l’alimentation électrique et, dans certains cas, des opérations d’extinction d’incendie ayant provoqué des dommages supplémentaires liés à l’eau.
Cette combinaison est particulièrement critique dans un data center. Une salle informatique peut survivre à la perte d’une alimentation grâce à ses chaînes électriques redondantes, mais la redondance ne protège plus lorsque le bâtiment, les locaux techniques, les groupes de refroidissement, les tableaux électriques, les chemins de câbles ou les systèmes de sécurité sont simultanément atteints. La remise en service ne consiste alors pas à redémarrer des serveurs : elle suppose de vérifier la structure, l’étanchéité, la distribution électrique, la détection incendie, le refroidissement, les réseaux et l’intégrité des équipements.
En avril, une seconde zone de disponibilité de Bahreïn a été touchée, ce qui a rendu la région pratiquement indisponible. AWS recommande depuis lors aux clients de déplacer leurs charges vers d’autres régions et de restaurer leurs données à partir de sauvegardes externes lorsque celles-ci existent.
La limite du modèle multi-AZ
AWS présente normalement ses Availability Zones comme des partitions isolées de son infrastructure, situées dans des emplacements géographiques distincts. La région des Émirats compte trois zones, tout comme celle de Bahreïn. Cette architecture est conçue pour limiter l’impact d’une panne locale et permettre une reprise entre zones.
Mais une région cloud n’est pas un territoire abstrait. Elle dépend d’un environnement physique : réseau électrique, télécommunications, routes d’accès, chaînes logistiques, personnels, sécurité et autorités locales. Dans un conflit, plusieurs bâtiments censés être indépendants peuvent être exposés au même événement géographique ou militaire.
C’est précisément la faiblesse révélée par l’incident. La redondance multi-AZ protège contre l’incendie d’un site, la panne d’un transformateur ou l’arrêt d’une installation. Elle ne garantit pas la survie face à une campagne de frappes visant simultanément plusieurs implantations d’une même région. AWS reconnaît que les dégâts à Bahreïn ont dépassé les hypothèses de résilience de ses services régionaux et multi-AZ.
Le cloud n’a donc pas supprimé le risque d’infrastructure : il l’a déplacé vers des ensembles de bâtiments, de réseaux et de systèmes électriques concentrés dans des zones géographiques parfois très réduites.
Le coût caché de la souveraineté régionale
Le choix d’une région cloud locale répond généralement à trois objectifs : réduire la latence, satisfaire des exigences de résidence des données et faciliter la conformité réglementaire. Pour une banque, un opérateur télécom ou une administration du Golfe, héberger les données à Bahreïn ou aux Émirats peut être préférable à une réplication en Europe ou en Asie.
Mais cette proximité crée une dépendance. AWS précise dans sa documentation que les ressources ne sont pas répliquées automatiquement entre régions. Une entreprise qui utilise exclusivement me-south-1 peut bénéficier d’une haute disponibilité entre les zones de Bahreïn sans disposer d’une véritable stratégie de reprise après sinistre régionale. La copie interrégionale doit être configurée explicitement.
AWS Backup permet de stocker des sauvegardes dans plusieurs Availability Zones et de les copier vers d’autres régions, mais cette protection suppose une architecture correctement conçue, financée et testée. Elle suppose également que les exigences de résidence des données autorisent une sortie du territoire. Dans certains secteurs, cette contrainte juridique peut rendre la réplication internationale difficile, voire impossible sans validation réglementaire.
L’incident met ainsi en tension deux exigences souvent présentées comme compatibles : la souveraineté locale et la résilience mondiale. Plus les données sont confinées à une région nationale ou sous-régionale, plus le risque de perte systémique augmente en cas d’événement extrême.
Une facture stratégique pour les clients
AWS affirme que la plupart des clients ont pu reprendre leurs opérations dans d’autres régions en restaurant des sauvegardes ou en copiant les données encore accessibles. Cette formulation est rassurante, mais elle révèle aussi une distinction essentielle : la reprise est possible pour les entreprises qui avaient conçu une architecture multi-région avant la crise, pas nécessairement pour celles qui se limitaient à la redondance locale.
La différence est opérationnelle et financière. Une architecture multi-région implique des coûts supplémentaires de stockage, de réplication, de bande passante, de licences, de supervision et de tests. Elle peut aussi augmenter la latence et compliquer la gestion des identités, du chiffrement et de la conformité. Pourtant, l’événement démontre que ces coûts relèvent moins d’une optimisation facultative que d’une assurance industrielle.
Pour les opérateurs et les investisseurs, l’implantation d’une région cloud dans un pays stable ne suffit pas. Il faut évaluer la profondeur stratégique du site, sa distance avec les autres zones, la robustesse des réseaux électriques et télécoms, les scénarios de menace, la capacité de remplacement des équipements et la possibilité juridique de répliquer les données ailleurs.
La promesse du cloud repose sur l’abstraction de l’infrastructure. Les frappes contre AWS au Bahreïn et aux Émirats rappellent brutalement que cette abstraction s’arrête à la porte du data center. Lorsqu’une région entière devient inaccessible, la question n’est plus de savoir si le fournisseur dispose de serveurs de secours, mais si le client a organisé sa propre sortie de crise…
