Résumé de la panne du service Amazon DynamoDB survenue dans la région US East (Virginie du Nord, us-east-1)

• Les 19 et 20 octobre 2025, la région AWS N. Virginia (us-east-1) a subi une panne prolongée touchant Amazon DynamoDB ainsi que plusieurs services critiques
• L’incident a commencé lorsqu’un enregistrement DNS vide incorrect a été créé à cause d’une condition de concurrence potentielle (race condition) dans le système de gestion DNS automatisé de DynamoDB
• Cela a entraîné en cascade des échecs de création d’instances EC2, des erreurs de connexion sur Network Load Balancer (NLB), ainsi que des latences et échecs d’API sur de nombreux services comme Lambda, ECS et Redshift
• AWS a identifié la cause du problème comme un conflit de mises à jour simultanées anormales entre les DNS Enactor de DynamoDB, puis a procédé à une restauration manuelle pour revenir à un fonctionnement complet vers 14 h 20 le 20 octobre
• Cet incident met en lumière la complexité des interdépendances entre les systèmes d’automatisation internes d’AWS et annonce des améliorations structurelles à venir pour renforcer la résilience de DNS, EC2 et NLB

---

Vue d’ensemble de l’incident

• La panne a commencé le 19 octobre 2025 à 23 h 48 (PDT) et s’est terminée le 20 octobre à 14 h 20 (PDT)
  • Trois périodes d’impact majeures ont été observées :
    1. du 19 octobre à 23:48 au 20 octobre à 2:40 : forte hausse du taux d’erreurs de l’API DynamoDB
    2. du 20 octobre à 5:30 à 14:09 : augmentation des erreurs de connexion NLB
    3. du 20 octobre à 2:25 à 10:36 : échec de création de nouvelles instances EC2 et problèmes de connectivité réseau
• L’incident a commencé par une défaillance du système de gestion DNS de DynamoDB avant de se propager à de nombreux services comme EC2, NLB, Lambda et Redshift

Cause et impact de la panne DynamoDB

• Une défaillance latente dans le système de gestion DNS automatisé de DynamoDB s’est déclenchée, mettant à jour de façon erronée l’enregistrement DNS de dynamodb.us-east-1.amazonaws.com vers un état vide
  • Le système est divisé en deux composants :
    • DNS Planner : surveille l’état des load balancers et génère de nouveaux plans DNS
    • DNS Enactor : applique les modifications dans Route53
• Une condition de concurrence (race condition) est survenue entre les DNS Enactor déployés indépendamment dans trois zones de disponibilité (AZ)
  • Le premier Enactor, en retard, a appliqué un ancien plan
  • Le deuxième Enactor a appliqué le plan le plus récent puis supprimé l’ancien plan, retirant ainsi toutes les adresses IP et faisant basculer le système dans un état incohérent
  • L’auto-réparation ayant échoué, une intervention manuelle a été nécessaire
• Juste après le début de la panne à 23 h 48, tous les services et flux clients dépendant de DynamoDB ont subi des échecs de connexion
  • Les clients utilisant des global tables ont pu envoyer leurs requêtes vers des réplicas dans d’autres régions, mais avec un retard de réplication (replication lag)
• À 0 h 38, des ingénieurs AWS ont confirmé que l’état DNS était la cause du problème
  • À 1 h 15, une mesure de restauration temporaire a permis de rétablir partiellement la connectivité de certains services internes
  • À 2 h 25, les informations DNS ont été totalement restaurées, et à 2 h 40 toutes les connexions étaient revenues à la normale

Impact sur Amazon EC2 et processus de restauration

• Entre le 19 octobre à 23 h 48 et le 20 octobre à 13 h 50, on a constaté une hausse du taux d’erreurs des API EC2, des échecs de création d’instances et une augmentation de la latence
  • Les instances déjà en cours d’exécution n’ont pas été affectées
• La gestion des instances EC2 repose sur deux sous-systèmes : DropletWorkflow Manager (DWFM) et Network Manager
  • DWFM gère l’état des serveurs physiques (« droplet ») et effectue des vérifications périodiques
  • Network Manager propage la configuration réseau des instances
• En raison de la panne DynamoDB, les contrôles d’état de DWFM ont échoué, ce qui a entraîné l’expiration des baux (lease) des droplets
  • Après le rétablissement de DynamoDB à 2 h 25, DWFM a tenté de se reconnecter, mais le grand nombre de droplets a provoqué un effondrement par congestion (congestive collapse)
  • À 4 h 14, les ingénieurs ont redémarré de manière sélective les hôtes DWFM pour vider les files et poursuivre la restauration
  • À 5 h 28, tous les baux des droplets avaient été restaurés et la création de nouvelles instances a repris
• Ensuite, Network Manager a traité un arriéré de propagation de l’état réseau, causant des retards de connectivité réseau
  • À 10 h 36, le temps de propagation réseau était revenu à la normale
  • À 11 h 23, l’assouplissement du throttling a commencé, et à 13 h 50 EC2 était entièrement rétabli

Impact sur Network Load Balancer (NLB)

• Entre 5 h 30 et 14 h 09 le 20 octobre, certains clients ont subi une augmentation des erreurs de connexion NLB
  • NLB est une architecture mutualisée qui achemine le trafic vers des instances EC2 backend
• La panne était due à des échecs de health checks causés par des retards de propagation de l’état réseau
  • La configuration réseau des nouvelles instances EC2 ajoutées n’étant pas terminée, les health checks échouaient
  • Les résultats de health checks fluctuaient de façon instable, entraînant la suppression puis le retour de nœuds NLB dans le DNS
• À 6 h 52, le système de supervision a détecté le problème et les ingénieurs ont commencé à intervenir
  • Une augmentation de charge sur le sous-système de health checks a déclenché un basculement automatique DNS inter-AZ
  • À 9 h 36, la désactivation du basculement automatique a permis le retour de tous les nœuds sains
  • À 14 h 09, après le rétablissement d’EC2, le basculement automatique a été réactivé

Impact sur les autres services AWS

• AWS Lambda :
  • Erreurs et latences API entre le 19 octobre à 23 h 51 et le 20 octobre à 14 h 15
  • En raison de la panne DynamoDB, échec de création et de mise à jour de fonctions, ainsi que retards de traitement des événements SQS/Kinesis
  • À 7 h 04, les échecs des health checks NLB ont provoqué une réduction de certains systèmes internes et une limitation des appels asynchrones
  • À 14 h 15, tous les arriérés avaient été traités et le service était revenu à la normale
• ECS, EKS, Fargate :
  • Entre le 19 octobre à 23 h 45 et le 20 octobre à 14 h 20, échecs d’exécution de conteneurs et retards d’extension des clusters
• Amazon Connect :
  • Entre le 19 octobre à 23 h 56 et le 20 octobre à 13 h 20, erreurs de traitement des appels, chats et dossiers
  • Après le rétablissement de DynamoDB, la plupart des fonctions sont revenues à la normale, mais de nouvelles erreurs sont apparues après 7 h 04 à cause de l’impact sur NLB et Lambda
  • Rétablissement complet à 13 h 20
• AWS STS :
  • Entre le 19 octobre à 23 h 51 et le 20 octobre à 9 h 59, erreurs et latences sur les API d’authentification
  • Retour temporaire à la normale après le rétablissement de DynamoDB, puis nouvelles erreurs à cause des problèmes NLB
• Connexion IAM et Identity Center :
  • Entre le 19 octobre à 23 h 51 et le 20 octobre à 1 h 25, augmentation des échecs d’authentification
  • Retour à la normale après le rétablissement de DynamoDB
• Amazon Redshift :
  • Entre le 19 octobre à 23 h 47 et le 20 octobre à 2 h 21, échecs d’exécution de requêtes et de modification de clusters
  • Après le rétablissement de DynamoDB, certains clusters restaient dégradés à cause de la panne EC2
  • Rétablissement complet le 21 octobre à 4 h 05
  • En raison d’une dépendance à l’API IAM, des échecs temporaires de requêtes ont aussi eu lieu dans la région globale
• Autres services :
  • Managed Workflows for Apache Airflow, Outposts, AWS Support Center et d’autres ont également été affectés

Actions post-incident et plan d’amélioration

• Désactivation complète de l’automatisation DynamoDB DNS Planner et Enactor, avec correction de la condition de concurrence et ajout de garde-fous avant toute réactivation
• NLB : introduction d’un mécanisme de limitation de débit pour plafonner la capacité qu’un seul NLB peut retirer en cas d’échec de health checks
• EC2 :
  • Mise en place d’une nouvelle suite de tests incluant les workflows de restauration DWFM
  • Amélioration du smart throttling du système de propagation des données afin d’ajouter une limitation des requêtes selon la taille des files d’attente
• AWS examine également des mesures supplémentaires, à l’échelle des interdépendances entre services, pour réduire le temps de restauration et éviter des incidents similaires

Conclusion et excuses

• AWS a présenté ses excuses officielles pour l’impact de cet incident sur ses clients
• L’entreprise reconnaît avoir historiquement maintenu une forte disponibilité de ses services, tout en admettant que cette panne a eu un impact significatif sur l’activité de ses clients
• AWS affirme vouloir tirer les leçons de cet incident pour renforcer la résilience de ses systèmes d’automatisation et de ses procédures de réponse aux pannes

[shakespeares]

On dirait que c’est le contrecoup des licenciements de seniors... c’est vrai ?

[GN⁺]

Avis sur Hacker News

• Je suis le genre de personne qui répète toujours la même chose sur ce sujet. Si vous n’avez pas encore lu le texte de Richard Cook, je vous recommande d’arrêter ce post-mortem tout de suite et de lire d’abord How Complex Systems Fail. C’est l’un des meilleurs textes techniques sur les défaillances des systèmes complexes. Cook rejette l’idée même de « cause racine » (root cause), et je pense qu’il a raison dans ce cas précis

  • Le texte de Cook est intéressant, mais il donne en pratique l’impression d’une suite d’affirmations intuitives. Pour vraiment le comprendre en profondeur, il faudrait sans doute lire toute sa bibliographie. Dans le cours systèmes 6.033 du MIT, on fait aussi lire un article de 1962 sur un thème similaire, ainsi qu’un autre article classique. À mon avis, ce genre de problème atteint finalement un niveau de complexité de type « wicked problem »
  • Ce qui m’a marqué dans le texte de Cook, c’est l’idée que les tentatives de rendre un système « plus sûr » après un incident peuvent au contraire réduire sa sécurité. L’explication selon laquelle les mesures destinées à empêcher l’erreur humaine augmentent le couplage et la complexité du système, multiplient les points de défaillance potentiels et rendent la détection ainsi que le blocage plus difficiles m’a particulièrement parlé
  • Il existe aussi une autre grille de lecture, la théorie des « Normal Accidents ». Elle affirme que plus les composants sont fortement couplés, plus leurs interactions sont complexes, et plus les conséquences d’un échec sont graves, plus le système devient intrinsèquement dangereux. Voir la page Wikipédia sur Normal Accidents
  • Je n’ai pas lu les deux documents jusqu’au bout, mais je ne suis pas d’accord avec l’idée qu’on ne peut pas identifier une cause racine simplement parce qu’un système est complexe. Dans le sport aussi, un point résulte de nombreux facteurs, mais il y a quand même un « marqueur ». Avoir une vision large est utile, mais pointer la cause principale reste pratique
  • Je suis prestataire et j’assure des astreintes on-call. La plupart des entreprises ne prennent pas vraiment l’astreinte au sérieux. La documentation est insuffisante et on ne laisse pas le temps de lire le code complexe écrit par d’autres. J’aimerais vraiment connaître une culture comme celle d’AWS, où l’astreinte est considérée comme une partie de l’apprentissage et des responsabilités

• Internet est en train de devenir de plus en plus un mononet centralisé. Né à l’époque de la guerre froide comme un réseau distribué, Internet est maintenant structuré de telle sorte qu’une seule erreur de déploiement peut arrêter des banques, le commerce et les voyages à l’échelle mondiale. La métaphore du cloud a déjà largement atteint ses limites.
  Pour les startups ou la R&D, cela reste utile, mais les entreprises en phase de croissance ou les gouvernements devraient disposer de leurs propres serveurs, leur propre cloud et leurs propres services critiques. La technologie et les compétences humaines existent largement pour cela

• J’ai été impressionné par la visualisation précise de la chronologie dans le post-mortem d’AWS. Comme dans la conférence légendaire de la GDC « I Shot You First », représenter l’écoulement du temps avec des flèches inclinées et poser la question « où le délai s’est-il produit ? » est une approche utile.
  Mais ce qui m’a encore plus surpris, c’est que le service de gestion des baux de nœuds EC2 n’avait pas de procédure de reprise (runbook). Pour un service aussi central chez AWS, je pensais que presque toutes les situations exceptionnelles auraient été prévues

  • Il ne faut pas voir ce genre de situation comme quelque chose d’effrayant, mais comme un motif intrinsèque aux systèmes complexes. Les défaillances potentielles existent de façon fractale, et il est impossible d’avoir un runbook pour tous les cas possibles

• Le cœur de cet incident ressemble à une variante du problème de l’invalidation de cache (cache invalidation) dans un système DNS. Deux DNS Enactor ont appliqué des plans à des moments différents, ce qui a provoqué une condition de course (race condition), et un ancien plan a écrasé le plus récent

  • Ce n’est qu’une explication destinée au grand public ; en interne, après la résolution de l’incident, il y aura réellement une évaluation du risque de récurrence et la rédaction de mesures d’atténuation (runbook). Cela sera ensuite suivi d’un apprentissage et d’un partage au niveau de l’organisation
  • Pour moi, cette condition de course elle-même est la cause racine. Sans ce bug, il n’y aurait pas eu d’incident
  • Je me demande pourquoi DNS Planner et Enactor ont été séparés. S’il s’était agi d’un seul service, cet état de concurrence aurait été plus évident. Cela pourrait être le résultat d’un abus des microservices, qui augmente la complexité
  • J’ai déjà vécu un problème similaire, et la cause était un retard du GC de la JVM ainsi qu’un matériel défaillant. C’est aussi une possibilité ici
  • Cela dit, AWS n’a pas précisé quelles seraient les mesures préventives si ce type de retard se reproduisait

• L’Enactor aurait dû faire une comparaison de version de l’enregistrement actuel (CAS) avant d’appliquer la nouvelle valeur. Même si c’est moins efficace, c’est un garde-fou élémentaire. DynamoDB lui-même aurait pu s’en charger

• J’ai été surpris de lire que DynamoDB gère des centaines de milliers d’enregistrements DNS par région. Le fait que dynamodb.us-east-1.amazonaws.com puisse se résoudre en des centaines de milliers d’adresses IP semble dépasser les limites de Route53. J’imagine qu’ils utilisent probablement un TTL faible et ne mettent à jour qu’une partie des entrées

  • En pratique, c’est bien ainsi que fonctionne le DNS d’AWS. Route53 fonctionne par ensembles d’enregistrements de ressources (RRSet) et renvoie l’ensemble approprié via des vérifications d’état ou une logique de sélection basée sur la latence
  • Les CDN fonctionnent de manière similaire. Ils collectent les métriques du système pour calculer le PoP optimal par réseau. bunny.net SmartEdge en est un bon exemple
  • J’ai moi aussi fait un test avec S3, et j’ai obtenu en quelques secondes des centaines d’IP différentes. Il existe cette diversité même dans une seule région

• Les bugs existent toujours. La vérification formelle (formal verification) est difficile, et les bugs à faible probabilité peuvent n’apparaître que des années plus tard.
  Il faut donc concevoir les systèmes en partant du principe qu’ils finiront par échouer, et prévoir une architecture qui limite les dégâts. L’architecture par cellules, les déploiements progressifs et les zones isolées en sont des exemples.
  AWS essaie aussi d’aller vers une architecture par cellules, mais il subsiste encore des dépendances croisées héritées dans us-east-1 en particulier. À long terme, il faudrait concevoir les régions comme totalement indépendantes.
  Ce type de travail n’avance pas sans le soutien des dirigeants, mais du point de vue des actionnaires, c’est un investissement clé pour réduire le risque de continuité de l’entreprise

• J’ai trouvé surprenant que le rapport utilise le fuseau horaire PT plutôt que l’UTC

  • La blague « epoch fail? » est sortie, mais comme la plupart des clients sont probablement basés aux États-Unis, le PT est peut-être plus intuitif
  • C’était peut-être aussi une façon de souligner la difficulté de la gestion d’incident en pleine nuit

• Je suis surpris qu’il n’y ait pas de gestion de version par endpoint, ni de motifs comme la 2PC ou le single writer lease. Malgré cela, j’apprécie beaucoup le fait qu’AWS ait publié cela avec autant de transparence

  • En réalité, l’API de modification DNS effectue bien un CAS, mais plusieurs writers asynchrones se sont retrouvés en concurrence sans ordre logique, ce qui a causé le problème. Il aurait fallu sérialiser l’ordre à l’aide d’un zone serial ou d’un sentinel record

• À mon avis, la cause directe de cet incident était une condition de course latente dans le système de gestion DNS de DynamoDB. Un ancien plan a écrasé le plan le plus récent, vidant les enregistrements DNS de l’endpoint régional

  • Mais il faut rester prudent avec la notion de « cause racine ». Ici, il s’agissait d’un effondrement métastable (metastable collapse), et le problème central était l’absence de procédure de reprise (runbook).
    Référence : How Complex Systems Fail