Quand le cloud s'arrête: Relecture de la panne majeure d'AWS du 20 octobre 2025

C'était un lundi dont beaucoup de responsables informatiques se souviendront encore longtemps. Le 20 octobre 2025, Amazon Web Services a connu une panne massive dans la région la plus importante du nord de la Virginie (US-EAST-1), qui a non seulement paralysé de nombreuses applications d'entreprise, mais a également produit des effets absurdes: même les propriétaires de matelas connectés en ont subi les conséquences. Maintenant, Amazon a publié un rapport détaillé post-mortem qui montre comment une minuscule condition de course dans une réaction en chaîne a pu arrêter un énorme système cloud.

L'effet domino : trois phases du chaos

L'échec a commencé dimanche soir à 23h48, heure du Pacifique (8h48 de notre heure lundi) et s'est poursuivi sous différentes formes jusqu'à l'après-midi. Amazon distingue trois phases principales, qui se chevauchent partiellement et se renforcent mutuellement.

Au cours de la première phase, qui a duré de 8h48 à 11h40, la base de données NoSQL DynamoDB d'Amazon a considérablement augmenté les taux d'erreur d'accès aux API. Cela aurait été assez dramatique à lui seul, car DynamoDB est un composant central d'innombrables services AWS. Mais ça devrait être pire.

La deuxième phase s'est développée entre 14h30 et 23h09 : le Network Load Balancer (NLB) a commencé à produire des erreurs de connexion accrues. Cela était dû à l'échec des contrôles de santé dans la flotte de NLB, ce qui a entraîné le retrait des serveurs fonctionnels du trafic tout en laissant les serveurs défectueux dans le système.

La troisième phase, et peut-être la plus perceptible pour de nombreux utilisateurs, a été le lancement de nouvelles instances EC2. De 11h25 à 19h36, cela n'a tout simplement pas fonctionné. Même lorsque les instances ont recommencé à fonctionner à partir de 19h37, elles se sont battues avec des problèmes de connexion jusqu'à 22h50.

La racine de tous les maux: une condition de course insidieuse

Que s'était-il passé? Amazon l’appelle un « défaut latent » dans le système automatique de gestion DNS de DynamoDB. Cela semble inoffensif au début, mais a eu des conséquences fatales. Pour comprendre ce qui ne va pas, il faut se plonger un peu dans l'architecture.

Des services tels que DynamoDB gèrent des centaines de milliers d'enregistrements DNS pour exploiter leur vaste flotte hétérogène d'équilibreurs de charge dans chaque région. Le système DNS permet une évolutivité transparente, une isolation des défauts, une faible latence et un accès local. L'automatisation est essentielle pour ajouter de la capacité, gérer les pannes matérielles et distribuer efficacement le trafic.

Le système de gestion DNS d'Amazon pour DynamoDB est divisé en deux composants indépendants pour des raisons de disponibilité. Le planificateur DNS surveille la santé et la capacité des équilibreurs de charge et établit périodiquement de nouveaux plans DNS pour chaque point de terminaison du service. Ces plans consistent en une collection d'équilibreurs de charge avec des pondérations appropriées. En revanche, DNS Enactor a des dépendances minimales et met en œuvre ces plans DNS en apportant les modifications nécessaires dans Amazon Route53. Pour la résilience, DNS Enactor fonctionne de manière redondante et totalement indépendante dans trois zones de disponibilité différentes.

Chacune de ces instances indépendantes de DNS Enactor recherche de nouveaux plans et tente de mettre à jour Route53 en remplaçant le plan actuel par un nouveau plan via une transaction Route53. Cela garantit que chaque point de terminaison est mis à jour avec un plan cohérent, même si plusieurs DNS Enactors tentent d'effectuer des mises à jour en même temps.

Et c'est là que réside le problème: la condition de course est née d'une interaction improbable entre deux DNS Enactors. Habituellement, un DNS Enactor prend le plan le plus récent et exécute les points de terminaison de service pour appliquer ce plan. Avant d'appliquer un nouveau plan, il vérifie une seule fois si son plan est plus récent que le plan précédemment appliqué. Pendant qu'il passe en revue la liste des points de terminaison, il peut y avoir des retards si un autre DNS Enactor est en train de mettre à jour le même point de terminaison. Dans de tels cas, DNS Enactor réessaie chaque point de terminaison jusqu'à ce que le plan soit appliqué avec succès à tous les points de terminaison.

Peu de temps avant l'échec, un DNS Enactor a connu des retards inhabituellement élevés et a dû essayer à plusieurs reprises ses mises à jour sur plusieurs points de terminaison DNS. Tout en travaillant lentement à travers les points de terminaison, plusieurs autres choses se sont produites en même temps: le planificateur DNS a continué à fonctionner et a produit de nombreuses nouvelles générations de plans. Un autre DNS Enactor a ensuite commencé à appliquer l'un de ces plans plus récents et a rapidement traversé tous les points de terminaison.

Le timing de ces événements a déclenché la condition de course latente. Lorsque le deuxième Enactor (qui a appliqué le dernier plan) a terminé ses mises à jour de point de terminaison, il a lancé le processus de nettoyage du plan, qui identifie et supprime les plans nettement plus anciens que celui qui vient d'être appliqué. C'est à ce moment-là que le premier Enactor (qui a été exceptionnellement retardé) a appliqué son plan beaucoup plus ancien au point de terminaison régional DynamoDB, remplaçant ainsi le plan plus récent. L'audit au début du processus d'application du plan était devenu obsolète en raison des retards inhabituellement élevés et n'a pas empêché l'ancien plan de remplacer le plus récent.

Le processus de nettoyage du deuxième Enactor a ensuite supprimé ce plan plus ancien, car il était plusieurs générations plus ancien que le plan qu'il venait d'appliquer. Lorsque ce plan a été supprimé, toutes les adresses IP du point de terminaison régional ont été immédiatement supprimées. De plus, en supprimant le plan actif, le système a été mis dans un état incohérent qui a empêché les mises à jour ultérieures du plan d'être appliquées par n'importe quel DNS Enactors. Cette situation a finalement nécessité une intervention manuelle de la part des opérateurs.

Le résultat? L’enregistrement DNS de «dynamodb.us-east-1.amazonaws.com» était soudainement vide. Tous les systèmes qui voulaient se connecter à DynamoDB en Virginie du Nord couraient immédiatement contre les erreurs DNS. Cela concernait à la fois le trafic client et le trafic des services internes AWS qui dépendent de DynamoDB.

Conséquences : lorsque l'infrastructure s'effondre

À 9h38, les techniciens ont identifié l'erreur dans la gestion DNS. Les premières contre-mesures temporaires ont été prises à 10h15 et ont permis à certains services internes de se reconnecter à DynamoDB. C'était important pour débloquer les outils internes critiques nécessaires à la poursuite de la récupération. Vers 11h25, toutes les informations DNS ont été récupérées.

Mais la crise était loin d'être terminée. Les instances EC2 ne voulaient toujours pas démarrer. La raison en était le DropletWorkflow Manager (DWFM), qui est responsable de la gestion de tous les serveurs physiques sous-jacents utilisés par EC2 pour héberger des instances EC2. En interne, Amazon appelle ces serveurs des « droplets ».

Chaque DWFM gère un certain nombre de droplets dans chaque zone de disponibilité et maintient un bail pour chaque droplet actuellement sous sa gestion. Ce bail permet au DWFM de suivre l'état du droplet et de s'assurer que toutes les actions de l'API EC2 ou de l'instance EC2 elle-même, telles que les opérations d'arrêt ou de redémarrage à partir du système d'exploitation de l'instance EC2, entraînent les changements d'état corrects dans les systèmes EC2 plus larges. Dans le cadre de cette gestion de bail, chaque hôte DWFM doit s'enregistrer et vérifier l'état de chaque droplet qu'il gère toutes les quelques minutes.

Mais ce processus dépend de DynamoDB. Lorsque DynamoDB n'était pas accessible, ces vérifications d'état ont commencé à échouer. Bien que cela ne concernait pas les instances EC2 en cours d'exécution, cela signifiait que le droplet devait établir un nouveau bail avec un DWFM avant que d'autres changements d'état d'instance puissent se produire pour les instances EC2 qu'il héberge. Entre 23h48 et 2h24, les baux entre DWFM et Droplets de la flotte EC2 ont commencé à décliner lentement.

Lorsque DynamoDB est redevenu disponible à 2 h 25, heure du Pacifique (11 h 25, heure locale), DWFM a commencé à restaurer les locations avec des droplets sur l'ensemble de la flotte EC2. Étant donné que chaque droplet sans bail actif n’est pas considéré comme un candidat pour de nouveaux lancements EC2, les API EC2 ont renvoyé des erreurs de capacité suffisantes pour les nouvelles demandes de démarrage EC2 entrantes.

Il y a eu un problème perfide ici: en raison du grand nombre de droplets, les tentatives d'établir de nouveaux contrats de location de droplets ont pris tellement de temps que le travail n'a pas pu être terminé avant qu'ils ne soient à nouveau exécutés dans les time-outs. Un travail supplémentaire a été mis en file d'attente pour essayer à nouveau d'établir le contrat de location de droplets. À ce stade, DWFM était entré dans un état d'effondrement congestif et ne pouvait plus progresser dans la récupération des contrats de location de droplets.

Comme il n'y avait pas de procédure de récupération opérationnelle établie pour cette situation, les ingénieurs ont agi avec prudence pour résoudre le problème avec DWFM sans causer d'autres problèmes. Après plusieurs tentatives d'atténuation, les ingénieurs ont réduit les travaux entrants à 4h14, heure du Pacifique, et ont commencé à redémarrer sélectivement les hôtes DWFM. Le redémarrage des hôtes DWFM a éliminé les files d'attente DWFM, réduit les temps de traitement et permis l'établissement de contrats de location de droplets. À 5 h 28, DWFM avait établi des baux avec tous les droplets dans la région de Virginie du Nord et de nouveaux lancements ont recommencé à réussir, bien que de nombreuses demandes aient encore vu des erreurs «request limit exceeded» en raison de l’étranglement des demandes introduit.

Le gestionnaire de réseau: quand la mise en réseau est à la traîne

Mais même avec cela, les problèmes n'étaient pas encore terminés. Lorsqu'une nouvelle instance EC2 est lancée, un système appelé Network Manager propage la configuration du réseau qui permet à l'instance de communiquer avec d'autres instances au sein du même cloud privé virtuel (VPC), d'autres périphériques réseau VPC et d'Internet.

À 5h28, heure du Pacifique (14h28 de notre heure), peu de temps après la restauration de DWFM, le gestionnaire de réseau a commencé à propager les configurations de réseau mises à jour aux instances nouvellement lancées et aux instances qui s'étaient arrêtées pendant l'événement. Étant donné que ces événements de propagation du réseau avaient été retardés par le problème de DWFM, un important arriéré de propagation de l'état du réseau a dû être traité par le gestionnaire de réseau dans la région de Virginie du Nord.

En conséquence, à 6h21, le gestionnaire de réseau a commencé à ressentir une augmentation de la latence des temps de propagation du réseau tout en travaillant sur le traitement de l'arriéré des changements d'état du réseau. Alors que les nouvelles instances EC2 pouvaient être lancées avec succès, elles n'avaient pas la connectivité réseau nécessaire en raison des retards dans la propagation de l'état du réseau. Les ingénieurs ont travaillé pour réduire la charge sur le gestionnaire de réseau afin de gérer les temps de propagation de la configuration du réseau et ont pris des mesures pour accélérer la récupération. À 10 h 36, les temps de propagation de la configuration du réseau étaient revenus à des valeurs normales et les nouveaux lancements d'instance EC2 fonctionnaient à nouveau normalement.

Network Load Balancer: le système de santé tombe malade

Les retards dans la propagation de l'état du réseau pour les instances EC2 nouvellement lancées ont également affecté le service Network Load Balancer (NLB) et les services AWS utilisant NLB. Entre 5h30 et 2h09, heure du Pacifique, le 20 octobre, certains clients ont connu une augmentation des erreurs de connexion sur leurs LNB dans la région de Virginie du Nord.

NLB est construit sur une architecture multi-locataire hautement évolutive qui fournit des points de terminaison d'équilibrage de charge et achemine le trafic vers des cibles back-end qui sont généralement des instances EC2. L'architecture utilise également un sous-système de vérification de la santé distinct qui effectue régulièrement des vérifications de la santé contre tous les nœuds de l'architecture NLB et supprime tous les nœuds du service considérés comme malsains.

Au cours de l'événement, le sous-système de vérification de la santé de NLB a commencé à éprouver une augmentation des erreurs de vérification de la santé. Cela est dû au fait que le sous-système de vérification de la santé a mis en service de nouvelles instances EC2, alors que l'état du réseau n'était pas encore complètement propagé pour ces instances. Cela signifiait que dans certains cas, les contrôles de santé échouaient, même si le nœud NLB sous-jacent et les objectifs backend étaient sains. Cela a conduit au fait que les contrôles de santé alternaient entre échec et santé. En conséquence, les nœuds NLB et les cibles backend ont été supprimés du DNS uniquement pour être remis en service lors du prochain bilan de santé réussi.

Les résultats de Health Check en alternance ont augmenté la charge sur le sous-système Health Check et provoqué sa dégradation, entraînant des retards dans les contrôles de santé et déclenchant un basculement automatique de l'ADN AZ. Pour les équilibreurs de charge multi-AZ, cela a entraîné la suppression de la capacité du service. Dans ce cas, une application a connu une augmentation des erreurs de connexion lorsque la capacité saine restante était insuffisante pour supporter la charge de l'application.

À 9 h 36, les ingénieurs ont désactivé le basculement automatique du bilan de santé pour NLB, ce qui a permis de rétablir tous les nœuds NLB sains et les objectifs backend disponibles. Cela a résolu les erreurs de connexion accrues aux équilibreurs de charge affectés. Peu de temps après la récupération de l'EC2, ils ont réactivé le basculement automatique de vérification de la santé de l'ADN à 2h09, heure du Pacifique.

Les effets: une queue de rat de problèmes

La panne de DynamoDB et les problèmes qui en ont résulté ont eu un impact considérable sur de nombreux autres services AWS. Les fonctions Lambda ont fourni des erreurs d'API et des latences entre 23h51 le 19 octobre et 2h15 du Pacifique le 20 octobre. Tout d'abord, les problèmes de point de terminaison DynamoDB empêchaient la création et la mise à jour des fonctionnalités, causaient des retards de traitement pour les sources d'événements SQS/Kinesis et des erreurs d'appel.

Amazon Elastic Container Service (ECS), Elastic Kubernetes Service (EKS) et Fargate ont connu des erreurs de démarrage des conteneurs et des retards de mise à l'échelle des clusters entre 23h45 le 19 octobre et 2h20 du Pacifique le 20 octobre.

Les clients Amazon Connect ont connu une augmentation des erreurs de traitement des appels, des conversations et des cas entre 23h56 le 19 octobre et 1h20 du Pacifique le 20 octobre. Les appelants entrants ont entendu des signes d'occupation, des messages d'erreur ou des connexions échouées. Les appels sortants initiés par les agents et initiés par l'API ont échoué.

AWS Security Token Service (STS) a connu des erreurs d'API et une latence entre 23 h 51 et 9 h 59, heure du Pacifique, le 19 octobre. Les clients qui tentaient de se connecter à AWS Management Console avec un utilisateur IAM ont connu une augmentation des erreurs d'authentification dues à des problèmes sous-jacents de DynamoDB entre 23h51 le 19 octobre et 1h25 du Pacifique le 20 octobre.

Les clients Amazon Redshift ont rencontré des erreurs d'API lors de la création et de la modification de clusters Redshift ou lors de l'exécution de requêtes sur des clusters existants entre 23 h 47 le 19 octobre et 2 h 21 du Pacifique le 20 octobre. Fait intéressant, les clients Redshift dans toutes les régions AWS entre 23h47 le 19 octobre et 1h20 le 20 octobre n'ont pas été en mesure d'utiliser les identifiants d'utilisateur IAM pour exécuter des requêtes, car un défaut Redshift utilisait une API IAM dans la région Virginie du Nord pour résoudre des groupes d'utilisateurs.

Les leçons: ce qu'Amazon change maintenant

Amazon a déjà pris plusieurs mesures et prévoit d'autres modifications pour éviter qu'elles ne se reproduisent. DynamoDB DNS Planner et DNS Enactor ont été désactivés dans le monde entier. Avant de réactiver cette automatisation, Amazon corrigera le scénario de conditions de course et ajoutera des mesures de protection supplémentaires pour empêcher l'application de plans DNS incorrects.

Pour l'équilibreur de charge réseau, un mécanisme de contrôle de la vitesse est ajouté, ce qui limite la capacité qu'un seul NLB peut supprimer si des erreurs de vérification de la santé provoquent un basculement AZ. Cela permet d'éviter que trop de capacité ne soit retirée du trafic à la fois.

Pour EC2, Amazon construit une suite de tests supplémentaires pour compléter les tests de mise à l'échelle existants. Celle-ci passera en revue le workflow de récupération DWFM pour identifier les régressions futures. En outre, le mécanisme de limitation dans les systèmes de propagation des données EC2 est amélioré pour limiter le travail entrant en fonction de la taille de la file d'attente et protéger le service pendant les périodes de forte charge.

Quand la redondance ne suffit pas

Cette défaillance illustre de manière impressionnante la complexité des infrastructures en nuage modernes et la manière dont une vulnérabilité apparemment mineure – une condition de concurrence qui ne se produira probablement jamais dans des circonstances normales – peut entraîner une cascade de défaillances. Malgré toutes les redondances, malgré des DNS Enactors tridimensionnels dans différentes zones de disponibilité, malgré une automatisation sophistiquée, un timing malheureux a pu faire s'effondrer l'ensemble du système.

Dans son rapport final, Amazon souligne qu'il s'excuse pour l'impact sur les clients. Nous savons à quel point les services sont critiques pour les clients, leurs applications, les utilisateurs finaux et leurs entreprises. Nous ferons tout ce qui est en notre pouvoir pour tirer les leçons de cet événement et l'utiliser pour améliorer encore la disponibilité.

Pour nous, en tant qu'utilisateurs, la prise de conscience reste: Le cloud peut être robuste, mais il n'est pas infaillible. Les stratégies multirégionales, les plans de reprise après sinistre et les mécanismes de repli ne sont pas une paranoïa, mais une nécessité. Et parfois, c'est le matelas connecté qui nous rappelle à quel point nous sommes devenus dépendants de cette infrastructure invisible.