Ce 20 octobre, l’infrastructure cloud d’Amazon a connu une panne dont l’ampleur de l’impact montre à quel point l’architecture cloud est fortement centralisée, et comment une région clé peut devenir un point de fragilité critique.
20 octobre, 3:11 heure de la côte est des Etats-Unis. AWS est en panne suite à un dysfonctionnement du subsystem de monitoring des load balancers réseaux (cause probable largement évoquée). Ce composant interne est chargé de surveiller la charge des load balancers, les équilibreurs de charge. L’incident empêche AWS de correctement répartir ou router le trafic.
L’impact est massif, la panne a entraîné des erreurs en cascade dans les services dépendants. Par une effet domino – beaucoup d’applications AWS reposent les unes sur les autres – l’impact s’est propagé à toute une série de services AWS, notamment DynamoDB, Global Accelerator, VPC PrivateLink, Security Token Service, CloudFront, etc.
Et des services externes majeurs comme Snapchat, Fortnite, Amazon Alexa, Ring, Signal, Robinhood, Canva, Perplexity et d’autres ont été perturbés ou rendus inaccessibles.
La chronologie de la panne
- La panne du cloud d’Amazon commence vers 3:11 AM ET (heure de la côte est américaine) : AWS signale des taux d’erreurs accrus et des latences sur plusieurs services dans la région US-EAST-1.
- Le temps passe, les ingénieurs AWS investiguent, les rapports montrent que de nombreux services sont impactés.
- Le problème initial a été localisé, il s’agit d’un subsystem interne de monitoring des load balancers réseau.
- Vers 6:35 AM ET, AWS annonce la “remédiation technique complète”, même si certains services continuent à subir des backlogs ou des effets résiduels.
Les causes apparentes internes
Les éléments rendus publics ont confirmé l’origine de la panne, un dysfonctionnement du subsystem de monitoring des load balancers réseaux. Il n’y a pas eu d’attaque externe signalée. Il s’agirait d’une erreur interne ou un bug dans l’infrastructure.
Ce qui a donné de l’ampleur à l’incident, c’est la pression sur la région US-EAST-1 d’AWS qui en fait une zone critique. C’est en effet une région “pivot” dans l’infrastructure du cloud d’Amazon, qui fait office de zone “maître” ou région centrale. Et comme des incidents antérieurs l’ont déjà montré, cela la rend plus sensible à des pannes à fort impact.
Des milliers de services, sites, applications sont devenus indisponibles ou dégradés, en particulier ceux reposant sur AWS comme backend ou infrastructure principale. Des institutions financières, des services gouvernementaux, des opérateurs télécoms (comme Orange, BT, Vodafone, Sky) ont subi des perturbations.
La panne interroge sur la dépendance des réseaux
Le confinement de la panne dans US-EAST-1 a montré l’importance de la répartition géographique et de l’architecture multi-région pour résister à ce type d’événement.
La panne va également raviver les débats autour de la dépendance excessive aux grands fournisseurs de cloud (Amazon, Microsoft, Google) : quand un acteur central tombe, beaucoup d’acteurs « downstream » en souffrent.
La confiance des utilisateurs, clients ou services dépendants, en particulier les startups et les services critiques, peut être ébranlée.
Et sur le plan technique, la panne devrait générer des coûts additionnels (réactions d’urgence, redondances, reconfiguration) pour les entreprises qui l’ont subit.
