Panne géante d’AWS : comment une erreur DNS sur DynamoDB a paralysé des services mondiaux

La panne du service cloud d’Amazon Web Services (AWS) du 19 octobre 2025 a duré plus de 14 heures et affecté des dizaines de services et millions d’utilisateurs. Amazon et l’éditeur de DownDetector (Ookla) ont publié des analyses complémentaires qui expliquent l’origine technique de l’incident et sa propagation en chaîne.

Chronologie et origine technique

L’incident a commencé le 19 octobre 2025 à 23h48. Les trois systèmes principaux touchés étaient DynamoDB (base de données), les Network Load Balancers (NLB) et EC2 (instances de calcul). Selon Amazon, l’origine est un défaut latent dans le système de gestion DNS de DynamoDB.

DynamoDB s’appuie sur des centaines de milliers d’enregistrements DNS pour diriger le trafic. Ce mécanisme comprend un  » planificateur  » qui choisit quels serveurs utiliser, et des  » exécuteurs  » qui appliquent ces plans. Un bug de synchronisation très rare s’est produit : un exécuteur lent appliquait un ancien plan pendant qu’un exécuteur plus rapide en appliquait un récent et supprimait les plans jugés obsolètes. Le plan supprimé venait précisément d’être appliqué, ce qui a effacé l’adresse DNS de DynamoDB et rendu le service inaccessible.

Effet en cascade

La perte d’accès à DynamoDB a déclenché une réaction en chaîne. De nombreux composants d’AWS dépendent de cette base pour conserver l’état et la santé des systèmes. Sans DynamoDB :

• Le système EC2 a perdu sa capacité à démarrer de nouvelles instances, car les gestionnaires d’hôtes utilisent DynamoDB pour suivre l’état des serveurs physiques.
• Les Network Load Balancers ont rencontré des vérifications défaillantes, provoquant des erreurs de connexion.
• D’autres services critiques (authentification AWS, Redshift, Lambda, support client) ont été affectés.

Autrement dit, le composant effondré était suffisamment central pour paralyser des fonctions considérées comme fondamentales pour l’exploitation de la plateforme.

Ce que montrent les signalements externes

Du côté de DownDetector, Ookla a enregistré plus de 17 millions de signalements d’utilisateurs dans plus de 60 pays, soit une hausse d’environ 970 % par rapport à la normale. Plus de 3 500 entreprises ont été affectées simultanément, parmi lesquelles de grandes applications et services : Snapchat (environ 3 millions de rapports), Roblox (716 000 rapports), des établissements bancaires britanniques, des services gouvernementaux et des objets connectés (Ring, Alexa).

La répartition géographique des signalements : 6,3 millions aux États-Unis et 1,5 million au Royaume-Uni. Ookla souligne que, bien que l’origine technique se situe dans la région  » US-EAST-1  » (Virginie), l’impact fut mondial parce que nombre d’architectures d’applications critiques centralisent des fonctions d’authentification, de métadonnées ou d’état dans cette région historique et très utilisée d’AWS.

Le rôle des architectures modernes

Les applications contemporaines sont souvent assemblées à partir de services interdépendants (bases de données, files d’attente, fonctions serverless). Quand le DNS ne résout plus un point d’accès clé comme l’API DynamoDB, les erreurs se propagent en cascade vers tous les services qui s’y appuient. Certaines équipes n’ont même pas pu se connecter à la console AWS pour corriger la situation, puisque l’authentification dépendait aussi de DynamoDB – un cercle vicieux où l’outil de réparation est lui-même indisponible.

Prévenir et atténuer : impossibilité d’éviter toutes les pannes, mais des préparations possibles

Impossible d’empêcher toutes les pannes, mais on peut réduire les risques et les conséquences. Ookla rappelle que la concentration des services internationaux sur quelques régions augmente la vulnérabilité. Deux approches courantes se dégagent :

• Multi-cloud et redondance : répartir les dépendances critiques sur plusieurs fournisseurs peut améliorer la disponibilité en cas de panne totale d’un fournisseur, mais cela a un coût et une complexité importants.
• Dégradation progressive (graceful degradation) : concevoir les services pour pouvoir désactiver des fonctionnalités non essentielles (par exemple, rendre une application en lecture seule, ou suspendre les uploads) plutôt que subir une indisponibilité totale.

Ookla met en avant la nécessité d’une culture opérationnelle axée sur ces stratégies : mieux vaut conserver un service limité et utilisable que tout perdre. L’incident rappelle aussi que  » le cloud  » repose sur des infrastructures physiques et des choix architecturaux qui doivent être explicitement gérés.

En résumé

La panne AWS d’octobre 2025 résulte d’un bug de synchronisation dans le DNS de DynamoDB ayant conduit à l’effacement d’un enregistrement critique. L’impact s’est propagé à des dizaines de services et à des millions d’utilisateurs, illustrant la dépendance importante des architectures modernes à des points critiques centralisés. Si l’on ne peut pas éliminer totalement le risque, des pratiques comme la redondance maîtrisée et la dégradation progressive peuvent limiter les dégâts en cas d’incident majeur.