Une panne mondiale de Canva, Perplexity, Snapchat, Fortnite... : Amazon détaille l'incident improbable qui a paralysé des milliers de services.
La panne AWS du 19 octobre a eu des conséquences graves pour de très nombreux services web. La région d'Amazon qui concentrait énormément de services au cœur des applications modernes s'est avérée être le point faible de la chaîne. Les explications sont précieuses et montrent que l'imprudence architecturale a joué un rôle dans ce désastre.
La panne du service AWS d’Amazon n’est pas une panne commune, mais son ampleur et sa durée ont immobilisé des dizaines de services. La base de données DynamoDB a été touchée, ainsi que les répartiteurs de charge réseau et les serveurs virtuels EC2. Les impacts se sont propagnés en cascade sur de nombreux clients qui utilisaient cette infrastructure pour héberger leurs applications.
Le problème initial était un défaut latent dans le système de gestion DNS de DynamoDB. Ce système utilise des centaines de milliers d'enregistrements DNS qui orientent le trafic vers les bons serveurs. Mais lorsqu'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. Le plan « obsolète » venait juste d'être appliqué, ce qui a eu pour effet d'effacer complètement l'adresse DNS de DynamoDB.
La panne de DynamoDB a déclenché une réaction en chaîne catastrophique. Les systèmes EC2 qui géraient le lancement de nouveaux serveurs virtuels ont été paralysés, car ils utilisaient DynamoDB pour maintenir leur état de santé. Le système Network Load Balancers a également connu des problèmes de vérification, provoquant des erreurs de connexion.
L'éditeur de DownDetector, Ookla, a compilé les réactions de sa communauté et a raconté cet incident majeur vu de l'extérieur. Les utilisateurs ont signalé plus de 17 millions de signalements d'utilisateurs dans plus de 60 pays, soit une augmentation de 970 % par rapport à la normale.
La région AWS US-EAST-1, qui est la région AWS la plus ancienne et la plus utilisée au monde, a été touchée. Les applications 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 éviter une telle panne, il est important de mieux se préparer. L'utilisation d'une configuration multi-cloud peut améliorer la disponibilité lors d'incidents affectant l'ensemble d'un fournisseur. Cependant, cette approche n'est pas faisable pour de nombreuses entreprises en raison des coûts de duplication et de la complexité supplémentaire.
La culture du "ralentissement progressif" est également importante. En désactivant un à un certains services lourds pour protéger le cœur de l'activité, les entreprises peuvent éviter une panne totale. Par exemple, sur un Snapchat qui a été l'une des applications les plus pénalisées 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.
La panne AWS du 19 octobre a eu des conséquences graves pour de très nombreux services web. La région d'Amazon qui concentrait énormément de services au cœur des applications modernes s'est avérée être le point faible de la chaîne. Les explications sont précieuses et montrent que l'imprudence architecturale a joué un rôle dans ce désastre.
La panne du service AWS d’Amazon n’est pas une panne commune, mais son ampleur et sa durée ont immobilisé des dizaines de services. La base de données DynamoDB a été touchée, ainsi que les répartiteurs de charge réseau et les serveurs virtuels EC2. Les impacts se sont propagnés en cascade sur de nombreux clients qui utilisaient cette infrastructure pour héberger leurs applications.
Le problème initial était un défaut latent dans le système de gestion DNS de DynamoDB. Ce système utilise des centaines de milliers d'enregistrements DNS qui orientent le trafic vers les bons serveurs. Mais lorsqu'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. Le plan « obsolète » venait juste d'être appliqué, ce qui a eu pour effet d'effacer complètement l'adresse DNS de DynamoDB.
La panne de DynamoDB a déclenché une réaction en chaîne catastrophique. Les systèmes EC2 qui géraient le lancement de nouveaux serveurs virtuels ont été paralysés, car ils utilisaient DynamoDB pour maintenir leur état de santé. Le système Network Load Balancers a également connu des problèmes de vérification, provoquant des erreurs de connexion.
L'éditeur de DownDetector, Ookla, a compilé les réactions de sa communauté et a raconté cet incident majeur vu de l'extérieur. Les utilisateurs ont signalé plus de 17 millions de signalements d'utilisateurs dans plus de 60 pays, soit une augmentation de 970 % par rapport à la normale.
La région AWS US-EAST-1, qui est la région AWS la plus ancienne et la plus utilisée au monde, a été touchée. Les applications 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 éviter une telle panne, il est important de mieux se préparer. L'utilisation d'une configuration multi-cloud peut améliorer la disponibilité lors d'incidents affectant l'ensemble d'un fournisseur. Cependant, cette approche n'est pas faisable pour de nombreuses entreprises en raison des coûts de duplication et de la complexité supplémentaire.
La culture du "ralentissement progressif" est également importante. En désactivant un à un certains services lourds pour protéger le cœur de l'activité, les entreprises peuvent éviter une panne totale. Par exemple, sur un Snapchat qui a été l'une des applications les plus pénalisées 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.
C'est vraiment incroyable qu'une panne de Canva et d'autres services puisse avoir des conséquences aussi graves ! 
Il semble que les gens sont vraiment dépendants de ces services pour leurs activités quotidiennes. Je pense qu'il est temps de réfléchir à notre dépendance à l'égard de ces outils et de chercher à diversifier nos activités. 
C'est pourquoi j'aime cette approche de "ralentissement progressif" pour éviter les pannes totales, c'est une bonne façon de prendre le contrôle de ses systèmes ! 
! On nous dit que c'était une imprudence architecturale, mais moi je pense qu'il faut aussi prendre en compte le fait que les gens sont vraiment trop dépendants des services cloud. C'est comme si on avait un père qui te disait "tu vas être heureux toute ta vie" et tu te trompes avec ça 
. Et maintenant on s'en fout ? Non, non, je plaisante ! Mais sérieusement, il faut prendre des mesures pour prévenir de tels incidents. La culture du "ralentissement progressif" est un excellent conseil. Et si Amazon avait mis en place une configuration multi-cloud, peut-être aurait-elle pu éviter tout cela 
. Mais c'est comme dire "je suis tropasseur", je veux être prêt à tout ! 
C'est incroyable qu'une panne de serveurs puisse avoir un impact aussi important sur des milliers de services web ! 
Je suis heureux qu'Ookla ait compilé les réactions de sa communauté pour raconter cet incident majeur.
C'est vraiment dommage qu'un problème aussi simple dans le DNS de DynamoDB ait pu s'aligner pour créer une panne si grave ! La manière dont les entreprises ont conçu leurs architectures est souvent trop complexe et dépendante d'une seule région... ça ne fait pas envie. 
C'est un bon rappel que nous devons être plus prudents avec notre architecture numérique, surtout si on dépend de services tiers comme AWS.