Une région tombe, la chaîne logistique s’arrête

Une erreur DNS dans la région AWS us-east-1 a déclenché une série de perturbations de services le 20 octobre 2025. Des fonctions dépendant de cette région ont également été touchées. Pour les entreprises dont les chaînes logistiques s’appuient sur le cloud, il est donc essentiel de savoir quels processus et services partagent un point de défaillance commun. Un plan de reprise testé permet de mettre ces dépendances en évidence.

L’essentiel en bref

Une erreur DNS a déclenché une cascade de perturbations

Selon le rapport d’incident d’AWS, l’origine était une condition de concurrence dans la gestion DNS de DynamoDB. Elle a laissé un enregistrement DNS vide pour le point de terminaison régional. Le système automatisé n’a pas pu corriger l’erreur lui-même. Les nouvelles connexions au point de terminaison concerné ont donc échoué.

Après la résolution du problème DNS, les systèmes dépendants sont restés perturbés. Le lancement de nouvelles instances EC2 a notamment été affecté. Plus tard, des contrôles d’état erronés des Network Load Balancers ont provoqué d’autres problèmes de connexion. La perturbation DNS initiale a duré près de trois heures et la restauration des autres services s’est prolongée tout au long de la journée.

Les pannes régionales peuvent avoir des effets au-delà de leur région

Certaines fonctions dépendant de us-east-1 ont également été touchées, notamment des fonctions d’IAM et de DynamoDB Global Tables. Une application située dans une autre région ne peut donc être indépendante de ce scénario de panne précis que si les services et les procédures d’exploitation dont elle a besoin y sont également disponibles.

Une liste des serveurs de l’entreprise ne suffit pas pour mener cette analyse. Elle doit aussi couvrir les bases de données, les services d’identité, le DNS, les interfaces et les services des fournisseurs. Pour chaque processus critique, il faut pouvoir identifier les composants nécessaires à son fonctionnement et ceux nécessaires à sa reprise.

Les chaînes logistiques ont besoin d’objectifs de reprise clairs

Une panne peut par exemple interrompre la prise de commandes ou l’accès aux données de stock si les applications concernées dépendent d’un composant cloud touché. L’ampleur des effets dépend du processus concerné et des solutions de repli disponibles.

Les équipes informatiques et métier devraient définir, pour chaque processus critique, la durée d’interruption acceptable et la quantité de données dont la perte est tolérable. L’AWS Well-Architected Framework désigne ces objectifs par les termes Recovery Time Objective et Recovery Point Objective. Des tests réguliers de reprise et de basculement permettent de vérifier si l’architecture choisie les atteint.

Évaluer les approches multirégion et multicloud

Une deuxième région chez le fournisseur actuel peut être une étape pertinente. Les données et l’application doivent y être disponibles et le basculement ne doit pas dépendre d’un composant en panne. Un test devrait aussi vérifier que les autorisations, les interfaces et les outils d’exploitation fonctionnent dans la région cible.

Un deuxième fournisseur peut réduire les dépendances supplémentaires envers le premier. Il entraîne aussi des efforts d’intégration et d’exploitation. Le choix de la solution dépend des objectifs de reprise, des dépendances communes réelles et des ressources disponibles.

Pour les entreprises financières relevant de DORA, une dimension juridique s’ajoute : pour les contrats envisagés relatifs à des services TIC qui soutiennent des fonctions critiques ou importantes, elles doivent notamment évaluer les risques de concentration. L’article 29 mentionne à cet égard les prestataires difficiles à remplacer et la conclusion de plusieurs contrats de ce type avec un même prestataire ou avec des prestataires étroitement liés.

Questions fréquentes

Source de l’image : générée par IA (juillet 2026)

Traduit de l’original allemand par intelligence artificielle. La version allemande fait foi.