AWS à Bahreïn: ce que la perturbation régionale dit de la résilience cloud

Les 23–24 mars 2026, AWS a déclaré sa région Bahreïn perturbée et a demandé aux clients de migrer, sans publier le détail des services ni d'ETA.

• Le 24 mars 2026, Amazon a indiqué que la région AWS Middle East (Bahrain), me-south-1, était perturbée dans le contexte du conflit et aidait les clients à migrer vers d'autres régions.
• Cette communication n'a publié ni service précis, ni heure de début, ni zone de disponibilité touchée, ni cause matérielle détaillée, ni délai de reprise pour ce nouvel épisode.

Deux épisodes distincts en mars

La chronologie est essentielle. Lors du premier épisode, le 1er mars, AWS avait signalé des dommages physiques liés à une frappe de drone à proximité d'une installation de Bahreïn. Les mises à jour de santé reprises par Associated Press distinguaient Bahreïn, où l'impact venait d'un événement proche, des deux installations des Émirats arabes unis directement frappées. À Bahreïn, les informations publiques concernaient notamment une perte d'alimentation dans la zone de disponibilité mes1-az2 de ME-SOUTH-1.

Le second épisode est celui de l'article. Le 23 mars au soir, puis dans une publication datée du 24 mars, Amazon a déclaré que la région de Bahreïn avait été « perturbée » à cause du conflit. Reuters a rapporté qu'un porte-parole attribuait la perturbation à une activité de drones dans la zone, mais qu'Amazon n'avait pas dit si l'installation avait été frappée, ni précisé l'étendue des dommages ou la durée attendue. Il ne faut donc pas transformer « activité dans la zone » en confirmation d'un impact direct ou de simples mesures préventives.

Ce que le statut public permet — et ne permet pas — de dire

Amazon a confirmé un impact au niveau de la région et a demandé aux clients ayant des charges dans les régions touchées de continuer à les déplacer. La société a dit accompagner les migrations et qu'un grand nombre d'applications fonctionnaient déjà depuis d'autres régions. Le statut public ne donnait toutefois pas, pour l'épisode des 23–24 mars, une liste vérifiable de services tels qu'EC2, S3, RDS ou Lambda, une heure de début exacte, un nombre de zones indisponibles ou une heure de rétablissement.

Ces lacunes doivent rester visibles. Les clients pouvaient recevoir des détails propres à leurs ressources dans le Personal Health Dashboard, mais ces avis privés ne justifient pas une liste publique uniforme. Les listes de services associées à l'incident du 1er mars ou aux Émirats arabes unis ne doivent pas être réattribuées au nouvel épisode de Bahreïn. Le bon résumé est donc « perturbation régionale en cours et migration conseillée », pas « tous les services AWS sont tombés ».

Une région n'est ni une zone ni le cloud mondial

AWS a ouvert la région de Bahreïn en 2019. Une région contient plusieurs zones de disponibilité; ce n'est pas elle-même une « zone de disponibilité ». Les zones sont conçues pour isoler des pannes locales, mais elles restent dans une même aire géographique. Une menace physique ou une décision opérationnelle touchant plusieurs dépendances régionales peut dépasser le modèle d'une panne d'une seule zone.

Rien dans les sources n'établit une panne mondiale d'AWS. Au contraire, Amazon a orienté les clients vers d'autres régions, ce qui suppose qu'elles restaient disponibles pour la reprise. L'impact réel dépendait de la présence des charges dans me-south-1, de leurs dépendances régionales, de la réplication des données et de la capacité des équipes à basculer.

Multi-AZ ne remplace pas une stratégie multirégion

Le pilier Fiabilité d'AWS recommande de répartir les charges entre plusieurs zones et, lorsque le risque l'exige, entre plusieurs régions. Une architecture Multi-AZ peut tolérer la perte d'une zone si les composants, données, quotas et chemins réseau sont réellement redondants. Elle ne garantit pas la continuité lorsqu'une région devient inutilisable ou quand un service de contrôle régional est dégradé.

La reprise interrégionale n'est pas automatique. Les VPC, le calcul, les secrets, les clés, les images, les données et les dépendances doivent exister dans la région de secours. L'organisation doit choisir des objectifs RTO et RPO, répliquer selon ces objectifs, prévoir la capacité et les quotas, automatiser le routage, tester le basculement puis le retour, et conserver des sauvegardes restaurables hors de la région primaire.

Le test opérationnel

Un plan crédible répond à des questions concrètes: quelles fonctions peuvent rester indisponibles; quelles données peuvent être perdues; qui déclare la catastrophe; comment l'identité, le DNS, les certificats et les files de messages se déplacent; quelle latence le site de secours supporte; et comment respecter la résidence des données. Une exigence de localisation peut limiter le choix d'une région de secours, mais elle ne remplace pas l'analyse de continuité.

Les équipes doivent rapprocher trois sources: le Service Health Dashboard public, les avis du Personal Health Dashboard et leur propre télémétrie. Elles doivent éviter un basculement partiel où l'application change de région mais reste dépendante d'une base, d'une clé KMS, d'un fournisseur d'identité ou d'un lien Direct Connect resté à Bahreïn.

Ce que cet incident établit

Il établit qu'une région AWS précise a subi une perturbation pendant un conflit et qu'Amazon a conseillé une migration. Il n'établit pas la défaillance du cloud mondial, l'indisponibilité de chaque service, une heure de reprise, ni l'échec automatique de toute architecture Multi-AZ. La leçon utile est plus étroite: la résilience promise par l'architecture n'existe que si les dépendances, les données et le processus de basculement ont été préparés et exercés hors de la région affectée.