L'incident AWS : ce n'était pas une panne, c'était un rappel à la réalité

Venmo, Fortnite, Snapchat, Zoom, Coinbase… tout l'écosystème AWS s'est mis à planter. Pas à cause d'un ransomware, d'une attaque à grande échelle ou d'un conflit géopolitique. Non. Parce qu'un composant d'AWS US-EAST-1, en Virginie du Nord, a déraillé.

On appelle ça un « incident technique ». Moi j'appelle ça un symptôme. Et un aveu de fragilité systémique.

Ce n'était pas un hack. C'était pire.

Quand il y a un attaquant, on peut identifier un adversaire, un vecteur, une intention. Ici, il n'y avait rien de tout ça. Juste un petit raté interne, avec des conséquences massives.

Le résumé officiel publié par Amazon est sans ambiguïté : dans la nuit du 19 au 20 octobre 2025, une « race condition » latente dans le système de gestion DNS de DynamoDB a produit un enregistrement DNS vide pour le point d'entrée régional du service, dynamodb.us-east-1.amazonaws.com. En clair, l'adresse du service a purement et simplement disparu.

Le mécanisme est presque banal. Deux automates se partagent la mise à jour du DNS : un « DNS Planner » qui calcule le plan d'adressage, un « DNS Enactor » qui l'applique dans Route 53. Cette nuit-là, un exécuteur a pris du retard sur un ancien plan pendant qu'un second en appliquait un plus récent, puis lançait le nettoyage. Résultat : le plan périmé a écrasé le bon, et toutes les adresses IP du point d'entrée régional se sont volatilisées. Pas une intrusion, pas un sabotage : deux composants internes qui se sont marché dessus au mauvais moment.

Pas de bruit. Pas d'alerte. Juste un silence brutal. Et tout un écosystème mondial qui se bloque. Parce qu'une zone géographique unique concentre trop de dépendances.

C'est ça, le vrai danger. Pas le hacker. Le monopole technique silencieux.

Comment un seul bug DNS a-t-il paralysé la moitié du web ?

Parce que rien, dans cette architecture, n'est vraiment isolé. Une fois l'adresse de DynamoDB évaporée, l'effet domino a été immédiat. Les serveurs EC2 ne pouvaient plus être lancés, les répartiteurs de charge échouaient sur leurs contrôles de santé, et des dizaines de services suivaient en cascade : Lambda, ECS, EKS, Fargate, Redshift, jusqu'aux briques d'authentification IAM et STS qui, elles, servent la planète entière.

Côté public, la liste des victimes ressemble à un annuaire du numérique quotidien : Alexa, Snapchat, Fortnite, Venmo, Coinbase, Zoom, Reddit, Disney+, Roblox, Bank of America, Lyft, DoorDash, le New York Times, et jusqu'à Amazon.com lui-même. Le défaut DNS a beau avoir été colmaté vers 2 h 40 du matin, la remise en état des services dépendants s'est étirée toute la journée : le lancement d'instances EC2 n'est revenu à la normale que vers 13 h 50, les équilibreurs de charge vers 14 h 09, heure du Pacifique. Près de quinze heures d'un silence en cascade, du milieu de la nuit au début d'après-midi.

Un seul détail technique, dans une seule région, chez un seul fournisseur qui pèse environ 30 % du marché mondial du cloud. Voilà la surface réelle de notre dépendance.

Une panne isolée, ou un signal de fond ?

Non, ce n'est pas un accident propre à Amazon. Moins d'un mois plus tard, le 18 novembre 2025, c'est Cloudflare qui s'effondrait à son tour : un simple changement de configuration d'une base de données a généré un fichier corrompu, propagé à tout le réseau, et une partie du web est devenue inaccessible, de ChatGPT à X, Spotify, Uber ou Canva. Un fournisseur différent, une cause différente, exactement le même scénario : un maillon central lâche, et des milliers de services tombent avec lui.

Deux géants, deux ratés internes, deux effets domino planétaires en quatre semaines. Ce n'est pas de la malchance. C'est la signature d'une infrastructure numérique mondiale posée sur une poignée d'acteurs, dont la moindre toux se propage à la planète entière.

Le cloud n'est pas magique. Il est mécanique.

Beaucoup d'organisations ont adopté le cloud comme on avale un somnifère : pour dormir tranquilles. Moins d'infrastructure, moins de complexité, moins de coûts.

Mais ce qu'on a gagné en confort, on l'a perdu en maîtrise.

Aujourd'hui, une grande majorité des entreprises ne savent pas d'où dépendent vraiment leurs services. Elles utilisent des outils numériques « prêts à l'emploi », interconnectés, empilés, souvent d'origine extérieure. Mais au fond, tout repose sur quelques zones très localisées, toujours les mêmes.

Et ces zones, elles aussi, peuvent tomber.

Une crise de gouvernance avant d'être une crise technique

Ce que cet incident révèle, c'est notre manque de rigueur sur les sujets critiques :

• On externalise sans stratégie de repli.
• On accumule les outils sans véritable plan de secours.
• On fait confiance les yeux fermés sans poser les bonnes questions.

En situation de crise, ce n'est pas l'outil qui fait la différence. C'est la capacité à comprendre vite, à pivoter, à décider.

Et pour ça, il faut des cartes lisibles. Pas des schémas obsolètes dans un dossier introuvable.

Les trois angles morts que personne n'aime regarder.

• La concentration géographique : trop de données, de services, de clients reposent sur un seul point névralgique. Ce n'est pas une « stratégie d'hébergement », c'est un goulot d'étranglement. US-EAST-1 est l'une des plus anciennes régions d'AWS, celle où sont ancrés des services dits « globaux » comme l'authentification IAM et STS, précisément ceux qui ont lâché ce jour-là.
• L'illusion de la redondance : croire qu'on a une alternative, alors qu'en fait tout passe par les mêmes structures invisibles (connexions, authentifications, flux).
• Le déficit d'autonomie : on ne forme pas les équipes à fonctionner sans leurs outils favoris. Le jour où l'outil plante, tout le monde attend que ça revienne.

Faut-il quitter AWS après une panne pareille ?

Non. Reproduire le même schéma chez un autre fournisseur ne règle rien.

Ce n'est pas Amazon le problème. C'est notre passivité collective.

Amazon fait ce qu'Amazon doit faire : optimiser, industrialiser, délivrer. Et l'entreprise a corrigé le défaut, documenté la chronologie et publié son analyse au grand jour. C'est même l'un des rares acteurs à le faire aussi ouvertement.

Le problème, c'est nous. C'est à nous de garder une architecture pensée pour l'échec. C'est à nous de répartir la charge sur plusieurs régions, voire plusieurs fournisseurs, plutôt que de tout empiler sur un seul point. C'est à nous de réduire la surface dépendante et de savoir ce qui se passe si notre prestataire préféré a un mauvais lundi.

Comment se préparer à la prochaine panne cloud ?

La bonne nouvelle, c'est qu'une panne comme celle-ci n'a rien d'imprévisible. C'est une hypothèse de conception, pas une surprise.

Concrètement : cartographier ses dépendances réelles, tester régulièrement le basculement, entraîner les équipes à opérer en mode dégradé, et vérifier que la « redondance » n'est pas une illusion qui repartage les mêmes tuyaux.

La question n'est pas « quand AWS tombera encore », mais « est-ce que vous saurez faire sans lui pendant quelques heures ? »

En savoir plus sur Christophe Mazzola

---

Sources

• Cause technique (« race condition » DNS, DNS Planner et DNS Enactor), chronologie précise et services AWS affectés : résumé officiel de l'incident, Amazon Web Services, 20 octobre 2025.
• Entreprises grand public touchées et part de marché d'AWS dans le cloud (environ 30 %) : Engadget, 20 octobre 2025.
• Chronologie et périmètre de la panne : « 2025 Amazon Web Services outage », Wikipedia.
• Panne Cloudflare du 18 novembre 2025 (changement de configuration, effet domino) : « 2025 Cloudflare outage », Wikipedia.