Deux zones de disponibilité, à six heures d'intervalle
À 12h51 UTC le 2 mars 2026, la zone de disponibilité qu'AWS désigne par mec1-az2, dans sa région Moyen-Orient Émirats, a cessé de fonctionner normalement. À 18h46 UTC le même jour, mec1-az3 était également touchée. AWS a confirmé que les deux avaient été directement frappées par des drones dans le cadre du conflit plus large dans la zone. Un troisième site, mes1-az2 dans la région distincte de Bahreïn, avait été perturbé vers 06h56 UTC ce lundi, ce qu'AWS a attribué à une frappe de drone à proximité immédiate ayant causé des impacts physiques sur son infrastructure.
Les frappes ont provoqué des incendies. Les incendies ont déclenché les systèmes d'extinction des centres de données, et l'eau a endommagé les équipements. AWS a signalé que les clients constataient des taux d'échec élevés à l'entrée et à la sortie des données sur des services comme S3, qui a besoin d'au moins une zone saine par région pour fonctionner. L'entreprise estimait que la remise en état des sites et de leurs systèmes de refroidissement prendrait au moins un jour.
Gardez cette estimation en tête pour la suite. Elle a été donnée de bonne foi, par un exploitant mieux informé que n'importe quel client, et elle décrivait la réparation avec exactitude.
La phrase de l'avis qui comptait vraiment
À côté des mises à jour de statut, AWS a dit à ses clients quelque chose de plus lourd de conséquences. Elle leur a conseillé de sauvegarder leurs données et d'envisager de migrer leurs charges vers d'autres régions AWS, au motif que le conflit en cours dans la zone rendait l'environnement d'exploitation imprévisible. Les fournisseurs de cloud ne demandent pas à la légère à un client payant de quitter une région qu'ils vendent.
Cet avis est l'élément utile de tout l'épisode, car c'est la seule consigne qui traite le vrai mode de défaillance. Un dégât des eaux d'extinction est une réparation. Un environnement d'exploitation imprévisible n'est pas une réparation, c'est une propriété du lieu, et aucune ingénierie à l'intérieur du bâtiment n'y change rien. AWS disait en substance à ses clients que la bonne réponse à cette classe d'événement est la sortie et non la patience.
La partie inconfortable: la plupart des manuels de reprise ont une page pour attendre et aucune pour partir.
Au moins un jour, mesuré sur le calendrier
Le 30 avril, le propre état des services d'AWS indiquait que la région Moyen-Orient Émirats avait subi des dommages du fait du conflit au Moyen-Orient et ne pouvait alors pas soutenir de manière fiable les applications des clients. Remarquez ce qui a changé dans cette phrase. En mars, la région avait une panne et une estimation. Fin avril, elle avait un état et plus aucune estimation.
Le 28 juillet, Cloudflare a publié sa revue trimestrielle des événements de perturbation d'internet, tirée des données de son réseau Radar. On y lit que le trafic HTTP vers me-central-1 est resté faible, et la baisse durable y est décrite comme la signature en aval de dommages physiques à l'infrastructure du centre de données sous-jacent. C'est une mesure indépendante et non une déclaration de fournisseur, et elle pointe dans le même sens environ cinq mois après les frappes.
L'arithmétique à emporter à votre prochaine revue de continuité: l'estimation publiée était d'au moins un jour, et la réponse observable se mesure toujours en mois.
La résilience régionale vise la mauvaise défaillance
L'architecture multizone est une très bonne réponse à la défaillance pour laquelle elle a été conçue. Les zones sont séparées afin qu'un incendie, une inondation, un incident électrique ou une panne réseau dans l'une n'emporte pas les autres. Cette hypothèse de conception tient admirablement quand l'aléa est local à un bâtiment et indépendant d'un bâtiment à l'autre. Elle cesse de tenir quand l'aléa est régional et corrélé, car la séparation entre zones se mesure alors en kilomètres et ce qui provoque les dégâts, non.
Deux des trois zones des Émirats ont été frappées le même jour. Un site situé dans une autre région, dans un autre pays, a été touché la même semaine. L'indépendance des zones est une affirmation physique portant sur une liste précise d'aléas, et le conflit armé ne figure pas sur cette liste. Il vaut la peine de le dire nettement, parce que c'est la partie qui paraît évidente après coup et n'apparaît presque jamais dans une revue de conception avant.
Pour les entreprises européennes, l'obligation existe déjà: les entités financières soumises à DORA doivent à leur superviseur un plan documenté de sortie et de continuité pour les prestataires informatiques critiques, et ce plan doit résister au cas où une région du prestataire devient indisponible et pas seulement lente.
Quatre modifications à apporter cette semaine
Premièrement, écrivez votre véritable objectif de délai de reprise pour la perte d'une région entière et non d'une zone, et soyez honnête sur le fait de l'avoir déjà testé. Si la réponse honnête est que la perte de région est hors périmètre, c'est une décision, et elle doit être consignée avec un responsable nommé plutôt que laissée en creux. Deuxièmement, séparez vos scénarios de réparation de vos scénarios de sortie. Un scénario de réparation attend. Un scénario de sortie bouge, et il lui faut ses données, sa configuration d'identités et ses routes réseau déjà préparées ailleurs.
Troisièmement, décidez à l'avance quelle preuve déclencherait un déplacement. Le déclencheur utile ici n'était pas la panne du 2 mars, c'était l'avis invitant les clients à envisager une migration. Les fournisseurs le disent rarement, et quand ils le font, cela doit être traité comme le signal et non comme du bruit de fond. Quatrièmement, vérifiez où se trouvent physiquement vos sauvegardes. Une sauvegarde située dans la région que vous cherchez à quitter n'est pas une sauvegarde, et le moment où vous en avez besoin est celui où la région est le problème.
À lire ensuite: OpenAI vous a remboursé en ce qui a lâché | Un quatrième géant du cloud devient plausible
