Panne de plusieurs services AWS dans la région us-east-1

• Des pannes sont survenues sur plusieurs services dans la région us-east-1 d’AWS.
• En raison de cette panne, des entreprises utilisant des infrastructures cloud ont connu des interruptions de service.
• Des problèmes de disponibilité ont été signalés sur des services clés comme API Gateway, Lambda.
• Les ingénieurs doivent préparer des chemins de contournement et examiner des plans de secours d’urgence.
• AWS diffuse des informations en temps réel sur l’incident et des mises à jour via AWS Health Dashboard.

---

Vue d’ensemble de la panne de la région AWS us-east-1

• Le 21 octobre 2025, une panne a touché plusieurs services de la région us-east-1 selon AWS Health Dashboard.
• En particulier, des services importants comme API Gateway, Lambda, S3 ont été affectés, entraînant des interruptions de service pour de nombreux clients.
• Dès la détection de l’incident, AWS a immédiatement lancé l’analyse de la cause et les travaux de restauration.
• Les entreprises SaaS, startups et sociétés IT dépendantes de cette région ont signalé des retards de service et des temps d’arrêt.
• Les ingénieurs et administrateurs IT ont souligné le besoin de construire des contournements d’urgence et une stratégie de multi-région pour les services critiques.

Impact et réponse

• La région us-east-1 est l’une des zones les plus chargées en trafic de l’infrastructure cloud mondiale, et l’impact d’une panne y est donc très important.
• Concrètement, plusieurs clients ont signalé simultanément des interruption de service, des retards de réponse API et des incidents de traitement des données.
• AWS informe en temps réel via Health Dashboard et fournit de la documentation d’assistance ainsi que des mises à jour.
• Les équipes IT clientes ont mené des efforts pour limiter les impacts, notamment par le monitoring de l’incident, des contournements temporaires et des annonces aux utilisateurs.

Enseignements pour les ingénieurs

• Cette panne a remis en avant la nécessité de réaffirmer l’importance des systèmes de surveillance et des mécanismes d’alerte d’incident.
• La valeur d’une architecture résiliente a été soulignée, notamment avec le déploiement multi-région, des procédures automatiques de remédiation et des stratégies de sauvegarde.
• AWS Health Dashboard est utilisé comme un outil d’accès rapide à l’information et de soutien à la prise de décision en cas d’incident.

Conclusion

• Les grands fournisseurs de services cloud doivent impérativement prévoir des dispositifs de préparation à la possibilité de pannes de service.
• L’importance d’un redressement rapide, d’une communication transparente et d’une capacité efficace de gestion des incidents d’infrastructure en cas de panne a été à nouveau mise en évidence.

[GN⁺]

Commentaire Hacker News

• Ce fut une journée vraiment intéressante. J'étais sur le bridge de gestion d'incident depuis 3 heures du matin. La plupart des systèmes ont été restaurés, mais il reste un service back office qui bute encore sur un manque de ressources. Notre erreur majeure, côté équipe, a été d'avoir conçu un fonctionnement multirégion mais de ne pas être capables d'exécuter le process de failover. La raison : l'équipe sécurité nous a migrés vers Identity Center en ne le déployant qu'en us-east-1, ce qui a laissé toute l'entreprise totalement bloquée sur le control plane AWS. Quand on a sorti les credentials root du coffre-fort, le système était déjà presque rétabli. Cette histoire rappelle une fois de plus que la chaîne la plus faible détermine la robustesse globale.
  • Ça me rappelle il y a quelques années la fois où le datacenter Google de Paris était en pagaille après une inondation, puis un incendie. Nous n'avions pas de ressources de calcul directement là-bas, mais le calcul se trouvait sur un datacenter AWS en Europe, et le résolveur DNS pour les services Google était hébergé à Paris, donc le trafic était prioritairement routé vers Paris. Le contournement était plutôt amusant. C'est à ce moment-là que j'ai découvert qu'on pouvait modifier globalement le fichier /etc/hosts déployé sur Kubernetes très facilement, et que c'était vraiment indispensable. En temps normal je n'utiliserais pas /etc/hosts pour ça, mais comme patch temporaire c'était l'abstraction idéale.
  • Je me souviens d'un cas similaire où Facebook a rendu l'accès au coffre totalement impossible à cause d'une erreur de mise à jour BGP. Si le chemin d'authentification est cyclique, une panne DNS suffit pour bloquer toute action.
  • À la fin, il faut arriver au moment où quelqu'un embarque avec un token matériel, prend l'avion vers un autre datacenter et redémarre l'équipement clé qui fait repartir le système global.
  • On m'a dit qu'Identity Center devait être en us-east-1 uniquement, et je me demande s'il peut être placé sur plusieurs régions. La dernière fois que j'ai vérifié, on ne pouvait l'utiliser que dans une seule région, et il fallait d'abord le supprimer pour le déplacer.
  • Une sécurité trop verrouillée peut au contraire empêcher d'agir. Je me demande si l'équipe sécurité sera responsable de ce qui s'est passé. Ça va probablement ralentir tous les projets à venir. J'ai l'impression que l'équipe sécurité a poussé trop vite jusqu'ici. Qui surveille les surveillants ?
• Il semble que la panne majeure soit encore en cours, et l'état est pire qu'il y a 4 heures. Je suis data engineer, et Redshift ainsi qu'Airflow (services gérés AWS) sont complètement en vrac.
  • La panne dure depuis un bon moment, je me demande combien de « 9 » ont disparu. En faisant 365 × 24 × 0,0001, on obtient environ 8 heures, donc nous avons déjà perdu 99,99 % de disponibilité.
  • Je ne comprends pas pourquoi tant d'entreprises restent accrochées à us-east-1. En fréquence d'incidents, c'est de loin le pire cas. Notre entreprise avait décidé auparavant d'éviter us-east-1 et de n'utiliser que d'autres régions. Bien sûr, quand un service se dit « global », ça signifie souvent us-east-1 en pratique, donc ça ne sert pas toujours.
  • Les opérations de control plane Lambda create-function échouent encore avec InternalError. Les autres services (Lambda, SNS, SQS, EFS, EBS, CloudFront) sont revenus. Je fais une recherche de master en CS sur la résilience cloud, donc j'ai testé sur plusieurs comptes AWS de test et j'ai consigné la timeline et les impacts de la panne. Post d'analyse
  • Down Detector montre que l'incident AWS reste sévère. Amazon dit « service en cours de restauration », mais en réalité la recherche de produits ne fonctionne pas non plus sur Amazon.com. Page AWS Health
  • D'après Down Detector, à 12:52 AM PT (3:53 ET), il y avait 5 755 signalements de problèmes AWS ; à 4:22 AM PT (7:22 ET), ils étaient tombés à 1 190, puis remontés à 9 230 à 9:32 AM PT (12:32 ET). L'essor en Californie peut expliquer une partie de la hausse, mais on a l'impression qu'AWS ne maîtrise pas encore vraiment la situation.
• Cette panne m'a aussi affecté directement au quotidien. À New York, à Hudson Yards Whole Foods, j'allais acheter une barre de chocolat mais l'option Prime n'a pas été appliquée, donc je ne l'ai pas prise, et mon stock de chocolat est désormais très bas.
  • Ce matin, « Alexa, allume la cafetière » n'a pas non plus fonctionné. J'étais complètement perturbé.
  • À midi, j'ai pris un plat au hot bar et essayé le self-checkout ; j'ai longuement réfléchi à pourquoi le code-barres Whole Foods ne marchait pas. Ce n'est qu'après une vingtaine de secondes que j'ai compris que c'était la panne.
  • C'est une anecdote intéressante à partager. Mais ça m'amène à me demander ce qu'il est advenu des gens présents dans les magasins Amazon Go pendant une panne AWS.
• J'ai une réunion aujourd'hui avec le responsable de mon compte AWS. J'expliquerai qu'on va quitter la stratégie « All in on AWS » et répartir les workloads. La raison principale est que la vitesse d'innovation des services core ralentit, et que les services IA sont bien trop en retard par rapport aux concurrents. L'équipe AWS soutient toujours de ne pas faire de cloud distribué en s'appuyant sur l'extrême stabilité d'AWS. J'attends cette réunion avec intérêt.
  • Que ce soit chez AWS, Cloudflare, Google Cloud ou Akismet, il y a des pannes plus ou moins tôt ou tard. À chaque fois, je me dis qu'il faut envisager l'hébergement in-house. On finit par tout reprendre après remboursement, et relancer. Le résultat final est similaire, donc autant éviter de se fatiguer davantage.
  • Lors du précédent rapport de résultats, quand Andy Jassy a eu des reproches sur le retard d'innovation d'AWS, il a brandi la stabilité, la fiabilité et la durabilité. Mais vu la situation actuelle, cet argument ne tient pas.
  • En dehors de us-east-1, les autres régions tournent pas mal, assez stable. Notre entreprise est aussi en grande partie sur eu-west-1, et ça tourne bien sans gros incident.
  • AWS est en déclin structurellement. J'ai l'impression que la société se contente aujourd'hui d'entretenir ses services existants. Les profils les plus innovants semblent être étouffés par la bureaucratie interne et la pression de performance, et AWS prend aussi du retard côté IA.
  • L'idée qu'AWS soit exceptionnellement stable n'était pas vraie dès le départ. J'avais déjà déployé une supervision multi-cloud avec plusieurs clouds et serveurs dédiés ; on pouvait voir très concrètement qui tombait en premier. Les résultats montraient qu'AWS n'était pas toujours numéro un, et c'était cohérent avec les données de netcraft.com.
• La Premier League aussi prévoit de faire fonctionner de manière limitée le système VAR et la détection automatique du hors-jeu à cause de la panne AWS aujourd'hui. On vit vraiment une époque étrange. Lien BBC
  • Je me rends compte qu'il y a peut-être un petit côté positif au cloud (en panne).
• Si vous prenez us-east-1 comme région principale, lorsqu'une panne arrive, tout se bloque en même temps, donc on n'est pas le seul à galérer. Ce privilège n'existe pas dans les autres régions US.
  • Quand nous avons migré d'un datacenter interne vers AWS, un des avantages inattendus a été que si toute une région tombait, les clients devenaient bien plus compréhensifs. Tout le monde est impacté simultanément, donc ça passe plus facilement.
  • Il faut parfois que tout le monde vive une panne technique au moins une fois.
  • Ok, mettons toute notre infra sur US-East-1.
  • Il faut beaucoup de temps pour comprendre ce qui compte vraiment en entreprise. En pratique, une structure où l'on peut se reposer sur la faute d'autrui compte davantage que la disponibilité. Quand une erreur d'employé provoque 5 minutes de panne par an, c'est la responsabilité du CTO ; quand une panne AWS en provoque 5 heures, c'est juste « une situation inévitable » car tout le monde est gêné. Finalement, chez AWS, Crowdstrike et consorts, ce qui compte n'est pas la robustesse du système, le coût-efficacité ou la gestion des risques, mais une période où tout le monde souffre en même temps. C'est désagréable, mais c'est la réalité. Quand on aime quand la technologie tourne bien, ça laisse un goût amer.
  • La région de Tokyo fonctionne bien actuellement ! Seules certaines fonctionnalités, comme la connexion à la console, restent problématiques.
• Il y avait un message disant : « Les résultats préliminaires suggèrent un problème de résolution DNS lié à l'endpoint API DynamoDB de US-EAST-1. Nous travaillons en parallèle pour accélérer la restauration », et une fois de plus, la cause finit toujours par être le DNS.
  • Je me demande si la panne était vraiment un problème de résolution DNS ou un souci d'affectation interne des serveurs DNS / du magasin de données ; je penche pour la seconde hypothèse.
  • Dans le message de suite, la cause a été donnée comme une panne du load balancer réseau. Le DNS est donc un symptôme de la cause profonde. Le DNS a pu perturber les health checks, mais à mon avis le cœur du problème est côté réseau.
  • Le BGP a peut-être été un déguisement d'un problème DNS.
  • La cause est toujours us-east-1.
  • Même quand ce n'est pas le DNS, on revient quand même au DNS.
• Notre architecture conçue pour la résilience a marché comme prévu. En mettant des origines de sites static en multirégion via CloudFront, la panne n'a pas eu d'impact. Le control plane est aussi en architecture multirégion native, donc il dépend de nombreux services tout en conservant la disponibilité. Chaque région fonctionne de manière indépendante, la réplication de données se fait, et même si la réplication vers us-east-1 échoue, l'impact reste nul. Le service lui-même est multirégion avec bascule gérée sur plusieurs couches (DNS, routing, choix de destination). Bien sûr, cette approche n'est pas parfaite, les modes de panne restent nombreux, mais cette fois elle tient le coup, et ça fait plaisir. Ce que j'ai fait n'est ni de la « rocket science » ni coûteux, mais c'est une approche un peu différente de la norme. Si vous avez des questions, je suis à votre disposition.
  • Mettre des origines static en multirégion derrière CloudFront pour éviter cette panne : ça devrait être la base en 2025, et pourtant c'est encore digne d'un compliment.
  • Je me demande si c'est un setup active/active, et comment est votre stack de données ; c'est précisément ce qui me semble le plus difficile.
  • Je suis curieux de savoir comment vous avez implémenté la tolérance de panne pour les clés et les certificats.
• Le point problématique majeur est qu'une surcharge ou une panne du système IAM/auth a déclenché une cascade de pannes. On avance parfois que DynamoDB en est la cause, mais je me demande si IAM dépend en interne de Dynamo. Avec un système massif complexe, les dépendances se mélangent vite ; Auth/IAM pouvant devenir un point d'entrée global, j'aimerais limiter les dépendances. Mais extensibilité, cohérence, etc. sont aussi importantes, donc on finit par utiliser des DB éprouvées. Du coup, l'interdépendance devient complexe, et quand le système tombe, on passe par un bootstrap compliqué. J'aimerais savoir comment vous gérez ça.
  • Il y a eu il y a ~2017 une grande panne liée à DynamoDB. EC2 stockait la liste des serveurs dans DynamoDB, donc quand DynamoDB est tombé, EC2 aussi. Comme DynamoDB fonctionnait sur EC2, impossible de restaurer en redémarrant de nouvelles instances EC2. Il a fallu lancer et rétablir manuellement des instances pendant plusieurs jours. Depuis, j'ai essayé de réduire au maximum les dépendances entre systèmes de premier niveau comme S3, DynamoDB et EC2. Bien sûr, atteindre la perfection est difficile.
  • Beaucoup de clients AWS, à cause de politiques de retry mal conçues, surchargeent les autres systèmes lors d'une panne d'un côté. La panne DynamoDB a donc entraîné une surcharge jusqu'à IAM.
  • En interne chez Amazon existe une plateforme KV nommée Dynamo, différente de DynamoDB. La cause peut donc être liée au routage DNS ou au déploiement des nœuds. Ce type d'incident revient sans cesse dans les post-mortems de grosses pannes.
  • Quand je travaillais chez AWS, IAM ne dépendait pas de Dynamo. Je ne sais pas si cela a changé, je n'en suis pas sûr. Un impact réseau à grande échelle semble plus probable. Pour qu'Auth/IAM ne devienne pas un point d'entrée global unique, l'architecture vise à réduire les dépendances au minimum. IAM a en fait son propre cache en lecture seule par région, et AWS SigV4 est conçu pour fonctionner région par région (documentation de référence).
  • Il est intéressant de noter que la cause récente de la panne de GCP semble être un problème similaire.
• AWS a annoncé à 3:03 AM PT qu'il était en cours de restauration, puis la situation a plutôt empiré. À 9:13 AM PT, il parle à nouveau d'analyse de cause. Ça inquiète de voir qu'AWS semble lui-même ne pas maîtriser la cause exacte.
  • C'est probablement lié au fait que cette semaine correspond à Diwali (le plus grand festival indien) et que pas mal d'ingénieurs indiens sont en congé. C'est la vraie poisse.