La panne du service AWS d’Amazon n’est pas une panne commune. Par son ampleur et sa durée, elle a immobilisé des dizaines de services et fait perdre l’accès à de très nombreuses applications — de productivité ou de divertissement. On sait aujourd’hui, avec précision, ce qui s’est passé.
Dans un long billet, Amazon AWS a détaillé les causes de la panne et la réaction en chaîne qui a conduit à en faire un souci généralisé. Dans un billet de blog, Ookla, qui édite DownDetector, a compilé les réactions de sa communauté et a aussi raconté cet incident majeur vu de l’extérieur. Deux documents qui nous permettent de mieux comprendre comment un géant du web peut être à l’origine du chaos.
La panne, racontée par Amazon
C’est à 23h48 le 19 octobre 2025 que l’incident a débuté et s’est étendu sur plus de 14 heures. Trois systèmes principaux ont été touchés : DynamoDB (la base de données), les Network Load Balancers (répartiteurs de charge réseau), et EC2 (les serveurs virtuels). Cette défaillance a eu des répercussions en cascade sur des dizaines d’autres services AWS et a eu un impact sur de nombreux clients qui utilisent cette infrastructure pour héberger leurs applications.
Mais le problème initial, d’après Amazon, provenait d’un défaut latent dans le système de gestion DNS de DynamoDB. Pour fonctionner, DynamoDB utilise des centaines de milliers d’enregistrements DNS qui orientent le trafic vers les bons serveurs. Ce système est composé de deux parties : un « planificateur » qui détermine quels serveurs utiliser, et des « exécuteurs » qui appliquent ces plans.
Un bug de synchronisation rarissime s’est produit : pendant qu’un exécuteur très lent appliquait un ancien plan, un autre exécuteur plus rapide a appliqué un plan récent puis a supprimé les anciens plans considérés comme obsolètes. Malheureusement, le plan « obsolète » venait juste d’être appliqué, ce qui a eu pour effet d’effacer complètement l’adresse DNS de DynamoDB, rendant le service totalement inaccessible.
La panne de DynamoDB a déclenché une réaction en chaîne catastrophique. De nombreux services AWS dépendent de DynamoDB pour fonctionner, et c’est à ce moment-là qu’ils se sont retrouvés bloqués. Plus particulièrement, le système EC2 qui gère le lancement de nouveaux serveurs virtuels a été paralysé : les systèmes de gestion des serveurs physiques utilisent DynamoDB pour maintenir leur état de santé.
Sans accès à cette base de données, ces systèmes ont progressivement perdu leur capacité à démarrer de nouveaux serveurs. Les Network Load Balancers ont également connu des problèmes de vérification, provoquant des erreurs de connexion. D’autres services comme l’authentification AWS, Redshift, Lambda et le support client ont également été affectés.
Ce que nous apprend Down Detector
C’est à ce moment-là que, de l’autre côté du web, DownDetector commence à s’agiter. Le service, que nous suivons sur Numerama pour certains de nos articles, a vu rouge : il a comptabilisé plus de 17 millions de signalements d’utilisateurs dans plus de 60 pays, soit une augmentation de 970 % par rapport à la normale. Dans le billet de blog, on lit que plus de 3 500 entreprises ont été affectées simultanément, allant des réseaux sociaux comme Snapchat (3 millions de rapports) et Roblox (716 000 rapports) aux services bancaires britanniques, en passant par les services gouvernementaux et les objets connectés comme Ring ou Alexa. Les États-Unis ont enregistré 6,3 millions de signalements, le Royaume-Uni 1,5 million.
Pour Ookla, l’éditeur de DownDetector, c’est précisément le nœud du problème : la panne a une étendue mondiale malgré une origine localisée en Virginie. L’article souligne que « US-EAST-1 » est la région AWS la plus ancienne et la plus utilisée au monde. Même les applications dites globales s’appuient souvent sur cette région pour gérer l’authentification, les métadonnées ou certains états critiques. Lorsqu’une dépendance régionale tombe en panne, les impacts se propagent mondialement car de nombreuses architectures « passent par la Virginie »
L’architecture moderne des applications aggrave ce phénomène : elles sont construites en assemblant des services (bases de données, files d’attente, fonctions sans serveur). Si le DNS ne peut plus résoudre un point d’accès critique comme l’API DynamoDB, les erreurs se propagent en cascade à travers tous les systèmes qui en dépendent, provoquant des pannes visibles dans des applications que les utilisateurs n’associent même pas à AWS.
Pour Ookla, c’est cette réaction en chaîne qui relève de l’imprudence architecturale : le système d’authentification d’AWS a aussi été touché. Puisqu’il dépend également de DynamoDB, de nombreuses équipes techniques n’ont pas pu se connecter à la console AWS pour appliquer des correctifs, déplacer le trafic ou redémarrer des services. Cette situation a créé un cercle vicieux : le système qui permet de réparer les pannes était lui-même en panne.
Éviter la panne est impossible, mais on peut mieux se préparer
Sur les réseaux sociaux, de nombreuses voix, teintées de yakafokon, se sont élevées pour proposer des solutions miracles — il faut dire qu’une telle panne peut engendrer des milliards de dollars de perte pour les entreprises touchées. Ookla se veut plus nuancé : on ne pourra pas anticiper toutes les pannes, mais celle-ci, comme celle de Crowdstrike avant elle, met en avant une concentration des services internationaux sur un trop petit nombre de lieux géographiques. Rappelant, au passage, que le cloud, ce n’est pas dans les nuages.
« Pour les services hautement critiques, l’utilisation d’une configuration multi-cloud peut améliorer la disponibilité lors d’incidents affectant l’ensemble d’un fournisseur, mais cette approche n’est pas faisable pour de nombreuses entreprises en raison des coûts de duplication et de la complexité supplémentaire », avance Ookla, avant de plaider pour une culture du « ralentissement progressif et non pas seulement de panne totale. »
Comment ? En étant capable de désactiver un à un certains services lourds pour protéger le cœur de l’activité. Sur un SnapChat, qui a été l’application la plus pénalisée lors de cette panne, cela pourrait se traduire par un arrêt du téléversement de média, l’application passant alors en lecture seule. Elle perd de l’intérêt, mais l’utilisateur peut toujours se promener dessus. Toujours mieux qu’une panne totale, en somme.
Vous avez lu 0 articles sur Numerama ce mois-ci
Tout le monde n'a pas les moyens de payer pour l'information.
C'est pourquoi nous maintenons notre journalisme ouvert à tous.
Mais si vous le pouvez,
voici trois bonnes raisons de soutenir notre travail :
- 1 Numerama+ contribue à offrir une expérience gratuite à tous les lecteurs de Numerama.
- 2 Vous profiterez d'une lecture sans publicité, de nombreuses fonctions avancées de lecture et des contenus exclusifs.
- 3 Aider Numerama dans sa mission : comprendre le présent pour anticiper l'avenir.
Si vous croyez en un web gratuit et à une information de qualité accessible au plus grand nombre, rejoignez Numerama+.
Toute l'actu tech en un clin d'œil
Ajoutez Numerama à votre écran d'accueil et restez connectés au futur !
Pour ne rien manquer de l’actualité, suivez Numerama sur Google !