Le 20 octobre 2025, une panne majeure chez AWS a paralysé des dizaines de services numériques à travers le monde. Déclenché dans la région us-east-1, l’incident s’est propagé à plusieurs couches critiques du cloud public d’Amazon, révélant les fragilités d’une infrastructure centralisée. Retour en cinq temps sur les causes, la diffusion, les impacts et les leçons de gouvernance à tirer de cet événement d’ampleur mondiale.
Le point de départ de la panne est un bug de synchronisation dans le gestionnaire DNS interne d’AWS, qui a servi de déclencheur. Plus précisément, une condition de course est survenue dans le processus d’automatisation du DNS Planner, déclenchant à tort la restauration d’un ancien plan de routage. Ce plan, en principe désactivé, a supprimé les adresses IP d’un point de terminaison critique utilisé par DynamoDB dans la région us-east-1. Privés de ces adresses, les clients comme les services internes n’ont plus pu se connecter au moteur de base de données. L’erreur, survenue à 23 h 48 PDT le 19 octobre (8 h 48 à Paris le 20), illustre la fragilité de certains mécanismes internes chez les fournisseurs hyperscale, malgré leur apparente robustesse.
Dans les heures suivantes, les appels à DynamoDB ont échoué en cascade, bloquant des centaines d’applications. L’absence de redondance active vers une autre région a empêché toute reprise automatique. L’impact n’est pas demeuré dans les limites de la base de données. Il s’est rapidement étendu à l’infrastructure réseau, au calcul, et à d’autres services à forte interconnexion technique. Le correctif immédiat a consisté à désactiver les automatismes concernés, mais le système a peiné à se stabiliser, pas avant avant plusieurs heures.
Propagation en chaîne dans les services critiques
L’effet de bord s’est manifesté lorsque les Network Load Balancers (NLB) de la région us-east-1 ont enregistré une vague d’erreurs. Les systèmes AWS les ont considérés comme défaillants et les ont retirés du routage, ce qui a réduit la capacité réseau de nombreux clients. En parallèle, des instances EC2 ont échoué à se lancer. La congestion du système de gestion du réseau et l’indisponibilité temporaire de certaines métadonnées ont bloqué la mise à disposition de nouveaux environnements. Même des appels internes aux services d’authentification ont subi des ralentissements.
L’événement a révélé une architecture à forte densité d’interconnexion dans la région us-east-1. Malgré le principe d’isolation régionale revendiqué par AWS, la centralisation des ressources critiques dans un même point géographique a aggravé les effets de la panne. La dépendance à une chaîne logicielle partagée entre plusieurs services a multiplié les points de vulnérabilité. Cette situation a remis en question la perception de compartimentation défensive entretenue par les fournisseurs cloud.
Des clients critiques ont été pris au piège
Au-delà des plateformes grand public comme Snapchat, Signal ou Fortnite, l’incident a touché des secteurs sensibles. Selon Reuters, les banques britanniques HSBC, Lloyds et Barclays ont subi des interruptions ou des ralentissements sur leurs services en ligne. Des plateformes de e-commerce, des outils de veille et des services de réservation ont également été affectés. Le suivi réalisé par Downdetector a fait apparaître des signalements importants aux États-Unis, au Royaume-Uni, en Allemagne, en Inde et au Japon. Des éditeurs français hébergés chez AWS n’ont pas communiqué officiellement, mais plusieurs ont signalé en interne avoir activé des procédures de contournement.
La configuration monorégion s’est avérée comme l’un des points noirs révélés par cette panne. Nombre de clients d’AWS ont déployé leurs services uniquement sur us-east-1, région par défaut et historiquement la plus avantageuse en coût et en latence. Cette stratégie, bien que rationnelle sur le plan économique, les a exposés à une indisponibilité totale. De plus, la cartographie des dépendances internes aux services managés n’a jamais été publique ni totalement documentée pour les clients. Ce manque de transparence a fragilisé l’évaluation des risques.
AWS a réagi en publiant des mesures correctives initiales
Amazon Web Services a publié une explication technique le lendemain de l’incident. L’entreprise y a détaillé trois périodes distinctes d’impact : la panne de DynamoDB, la réduction de capacité du NLB et l’impossibilité de lancement de nouvelles instances EC2. Plusieurs mesures de remédiation ont été appliquées, parmi lesquelles la suspension temporaire de certains automatismes DNS, l’ajout de garde-fous dans le routage réseau et la refonte partielle du système de contrôle d’état des services. AWS a également promis la publication d’un post-mortem complet dans les jours suivants. En parallèle, les grands comptes concernés ont été contactés par les équipes de support entreprise.
Cette communication, bien qu’assez précise, a soulevé une question essentielle. Les clients peuvent-ils réellement gouverner une infrastructure qui leur est opaque, centralisée et dépendante d’automatismes qu’ils ne contrôlent ni dans leurs déclencheurs ni dans leurs effets ? La réponse à cette question conditionne leur stratégie d’engagement ou de désengagement vis-à-vis des hyperscalers, surtout dans les secteurs régulés.
Un signal d’alarme pour la souveraineté numérique
La panne AWS a agi comme un révélateur. Un dysfonctionnement technique sur un plan DNS américain a suffi à interrompre des opérations financières en Europe, des interactions citoyennes en Inde ou des services hospitaliers à distance. Ce constat a justifié un changement de posture. Les directives européennes, telles que DORA ont imposé dès 2025 aux acteurs financiers une évaluation des prestataires critiques, incluant leur capacité de remédiation et leur transparence opérationnelle. Des incidents de ce type pourraient déclencher des audits obligatoires et des sanctions en cas de défaillance des plans de continuité d’activité.
Sur le terrain, les DSI, en première ligne, sont à présent contraints de repenser leurs architectures, de relancer les scénarios de bascule interrégions, de reconsidérer la diversification des fournisseurs et d’évaluer l’intégration de services souverains pour les fonctions critiques. La dépendance implicite au fonctionnement interne des hyperscalers est devenue un enjeu stratégique. La gouvernance des infrastructures cloud ne peut plus être laissée à la seule appréciation des fournisseurs, aussi réputés soient-ils. Le 20 octobre 2025 a marqué une inflexion majeure dans la prise de conscience des risques liés à l’hypercentralisation des ressources numériques.
