Quand us‑east‑1 éternue : Guide sur la panne AWS du 19–20 oct.

Name

Akira Sakamoto

Updated on 22/10/2025

Date de l'événement : 19–20 oct. 2025 (heure du Pacifique)
Déclencheur primaire : défaut d'automatisation DNS pour le endpoint régional de DynamoDB
Périmètre d'impact : DynamoDB → lancements EC2 → Network Manager → NLB → (Lambda, STS, IAM sign‑in, Redshift, ECS/EKS/Fargate, Connect) dans us‑east‑1

TL;DR (pour les pressés)

• Déclenchement (23:48 le 19 oct.) : Une condition de course dans la gestion automatisée du DNS de DynamoDB a fait que le endpoint régional dynamodb.us-east-1.amazonaws.com a basculé sur un enregistrement vide. Toute tentative d'ouvrir une nouvelle connexion vers DynamoDB en us‑east‑1 échouait à la résolution DNS.
• Rétablissement primaire de DynamoDB (02:25–02:40 le 20 oct.) : AWS a restauré les enregistrements DNS ; les clients ont récupéré au fur et à mesure de l'expiration des caches DNS.
• Pourquoi ça ne s'est pas arrêté là : Le plan de contrôle d'EC2 dépend de DynamoDB pour les baux des hôtes (« droplets »). Ces baux ont expiré pendant la fenêtre DNS, provoquant un effondrement congestionnel dans le Droplet Workflow Manager (DWFM) et un arriéré dans Network Manager. Les nouveaux lancements EC2 échouaient ou démarraient sans état réseau.
• Turbulences des load balancers (05:30–14:09) : Les health checks du Network Load Balancer (NLB) ont vu du flapping à cause d'une propagation réseau retardée, entraînant des suppressions intermittentes de capacité et des erreurs de connexion.
• Retour à l'état stable : La plupart des services se sont stabilisés tôt l'après‑midi du 20 oct. ; les derniers effets sur Redshift (remplacements d'EC2) se sont achevés le 21 oct. à 04:05.

Le « que s'est‑il passé », en une timeline schématique (PDT)

Deux minutes sur les concepts clés (pour les nouveaux lecteurs)

DNS (Domain Name System)
Pensez au DNS comme au bottin téléphonique d'Internet. Vous demandez un nom ; il renvoie où appeler (adresses IP). À l'hyperscale, les fournisseurs utilisent des enregistrements DNS et des health checks pour orienter le trafic sur d'énormes flottes et Availability Zones. C'est rapide et omniprésent, mais ce n'est pas une base de données transactionnelle ; la cohérence et l'ordonnancement des changements sont des problèmes difficiles qui doivent être contournés par la conception.

DynamoDB
Base clé‑valeur/NoSQL managée d'AWS. Latence très faible, élastique, et utilisée partout — y compris par AWS lui‑même pour des plans de contrôle et des métadonnées. Global Tables répliquent entre régions. Si votre appli ou un sous‑système AWS ne peut pas lire/écrire l'état de contrôle dans DynamoDB, les problèmes s'accumulent rapidement.

EC2 et le plan de contrôle
EC2 exécute vos instances sur des « droplets » (hôtes physiques). Des services internes gèrent les baux sur ces hôtes et propagent l'état réseau (routes, security groups, etc.). Lancer une instance est simple — sauf si la coordination interne est dégradée ou en retard.

NLB (Network Load Balancer)
Un load balancer de couche 4. Il exécute des health checks et peut router entre AZ. Si les health checks flappent ou si le basculement basé sur DNS est trop agressif, on peut retirer trop de capacité au moment précis où on en a le plus besoin.

Ce qui a réellement échoué : l'automatisation DNS de DynamoDB

AWS sépare la gestion DNS de DynamoDB en deux rôles :

• DNS Planner : calcule les jeux d'enregistrements désirés (quels load balancers, avec quels poids) pour chaque endpoint (régional, FIPS, IPv6, spécifique au compte).
• DNS Enactor : trois workers redondants dans des AZ différentes qui appliquent ces plans sur Route 53, chacun effectuant des mises à jour transactionnelles.

Dans une situation de contention particulière, un Enactor a progressé lentement tandis qu'un autre a pris de l'avance avec des plans plus récents puis a garbage‑collecté les générations plus anciennes. Le plan plus lent contenant une version obsolète a alors écrasé le endpoint régional immédiatement avant que le fast Enactor ne supprime ce plan ancien — supprimant toutes les IPs pour le endpoint et laissant le système dans un état qui bloquait les mises à jour automatiques ultérieures. Des opérateurs humains sont intervenus pour réparer.

Pourquoi c'était important : le endpoint régional a disparu. Tout ce qui nécessitait une nouvelle résolution DNS vers DynamoDB en us‑east‑1 a immédiatement échoué. Les connexions existantes, en général, ont continué de fonctionner.

Pourquoi cela a enchaîné : couplages étroits et la flèche du temps

1. Contrôle‑plan couplé (EC2 ⇄ DynamoDB).
   Le Droplet Workflow Manager (DWFM) d'EC2 conserve des baux sur les hôtes physiques. Ces vérifications dépendent de DynamoDB. Pendant l'incident DNS, les baux ont expiré, rendant les droplets inéligibles pour de nouveaux placements d'instances. Quand DynamoDB est revenu, le DWFM a dû rétablir les baux sur une immense flotte, a subi des timeouts de file d'attente, et s'est encombré.

2. Propagation réseau retardée.
   Même lorsque des instances ont commencé à redémarrer, Network Manager avait un arriéré pour publier leur état réseau. Des instances sont arrivées sans connectivité complète jusqu'à ce que les propagations rattrapent le retard (≈ 10:36).

3. Boucles de rétroaction des health checks (NLB).
   La nouvelle capacité sans état réseau complet semblait unhealthy, donc NLB a retiré des nœuds ou des AZ du DNS, réduisant temporairement la capacité et aggravant les erreurs de connexion. Les opérateurs ont mis en pause le basculement automatique des health checks pour arrêter l'oscillation, puis l'ont réactivé après la stabilisation d'EC2.

4. Écho vers les services aval.
   Lambda a throttlé certains chemins pour protéger les invocations synchrones ; STS/IAM sign‑in a vacillé puis s'est rétabli ; les plans de contrôle de conteneurs (ECS/EKS/Fargate) et Connect ont subi l'effet combiné EC2/NLB ; Redshift a eu une complication supplémentaire : l'authentification des requêtes via IAM a brièvement échoué globalement, et certains clusters ont attendu des remplacements d'hôtes EC2, prolongeant l'incident jusqu'au 21 oct.

Si vous pensez en termes de « modèle du gruyère » — plusieurs couches fines de défense alignées de façon malheureuse — vous êtes dans le bon.

Une perspective des systèmes complexes (pourquoi la « cause racine » ne suffit pas)

Plusieurs praticiens ont cité Richard Cook (How Complex Systems Fail) et Perrow (Normal Accidents). Ce cadre s'applique étrangement bien ici :

• Pas de cause unique. La course DNS a allumé l'étincelle, mais la longue traîne est venue du mode de récupération métastable d'EC2 et de l’oscillation des health checks NLB — chacun une conception localement rationnelle qui a mal interagi sous contrainte.
• Les systèmes fonctionnent souvent dégradés. Retentatives Planner/Enactor, expirations de baux, arriérés — des frictions normales que le système tolère — se sont alignées de façon malheureuse.
• Les humains créent la sécurité. L'automatisation a calé ; les opérateurs ont improvisé des réparations (restauration DNS manuelle, throttling/restarts du DWFM, désactivation de l'auto‑failover NLB) pour recoudre le tissu.

Conclusion : Corriger le bug est nécessaire, mais il faut aussi chasser les pièges de récupération métastable et les boucles de rétroaction qui transforment de petits incidents en pannes majeures.

Ce qu’AWS dit qu’ils vont changer

• Automatisation DNS DynamoDB : désactivée globalement pendant la correction ; ajout de garde‑fous pour empêcher l'application ou la suppression de plans incorrects.
• NLB : ajouter un contrôle de vitesse pour empêcher que le basculement des health checks ne retire trop de capacité trop rapidement.
• EC2 : nouvelles suites de tests de récupération pour DWFM ; meilleur throttling conscient des files sur les systèmes de propagation d'état.

Ce sont les bonnes classes d'atténuations : empêcher les mauvaises écritures, modérer l'auto‑guérison, et exercer les chemins de récupération sous charge.

Ce que vous pouvez faire (checklist du lundi matin)

Même si vous ne pouvez pas changer AWS, vous pouvez adoucir l'impact dans votre propre stack.

1. Préférez les endpoints régionaux et supprimez les dépendances cachées sur us‑east‑1.
   Quand les services proposent des plans de contrôle régionalisés (p.ex. STS), utilisez‑les. N'accumulez pas l'auth ou les métadonnées dans us‑east‑1 par habitude.

2. Concevez pour l'accès multi‑région — surtout pour l'état de contrôle critique.
   DynamoDB Global Tables peuvent permettre de basculer les lectures/écritures vers une seconde région. Votre code doit tolérer le lag de réplication et réconcilier ensuite.

3. Échouez fermés sur l'oscillation des health checks.
   Verrouillez l'auto‑failover avec de la modulation : plusieurs échecs consécutifs, hystérésis, et plafonds de suppression de capacité par minute. Envisagez un override manuel (circuit breaker) pour arrêter le flapping.

4. Rendez explicites vos graphes de dépendances.
   Documentez quels services doivent être opérationnels pour lancer/mettre à l'échelle (auth, queues, stores de config). Entraînez‑vous au scénario « que se passe‑t‑il si X est lent/indisponible pendant 2 heures ? »

5. Entraînez‑vous aux récupérations métastables.
   Journée chaos pour le plan de contrôle, pas seulement pour le data plane :

   • Simulez l'expiration des baux sur une tranche de la flotte.
   • Inondez votre propagateur de config réseau.
   • Répétez la séquence pression‑back‑pressure et levée de throttles.

6. Cachez avec intention.
   Les caches DNS ont masqué le retard de récupération (les clients attendaient l'expiration du TTL). Pour des SDKs qui ouvrent de nouvelles connexions agressivement, considérez pooling de connexion et backoff exponentiel avec jitter pour éviter les retries synchronisés.

7. Construisez des runbooks « mode sûr ».

   • Concurrence réduite ou limites de taux en cas de pics d'erreur.
   • Préférez vider les arriérés avant de réactiver les autoscalers.
   • Utilisez des feature flags pour désactiver les jobs de fond coûteux pendant un incident du plan de contrôle.

8. Protégez vos propres patterns « planner/enactor ».
   Si vous générez un état désiré et l'appliquez ailleurs, ajoutez :

   • Plans versionnés avec sémantique compare‑and‑swap.
   • Nettoyage qui ne peut pas supprimer le dernier plan connu bon.
   • Un lease single‑writer par endpoint ou un petit séquenceur (horloge vectorielle / compteur monotone).

S'agit‑il d'un « mauvais usage du DNS » ?

Pas exactement. À l'hyperscale, le DNS est un outil de service‑discovery et de pilotage du trafic parce que chaque client, librairie et resolver VPC le parle. Le problème n'était pas l'utilisation du DNS en soi ; c'était de permettre des écritures concurrentes et qu'un janitor interagisse avec elles sans garanties d'ordonnancement strictes, puis de laisser la logique basée sur les health checks supprimer la capacité trop vite pendant un arriéré de propagation réseau. Ce sont des choix d'ingénierie corrigeables.

Glossaire (rappels de 60 secondes)

• Route 53 : service DNS et health‑check d'AWS. Supporte le routage pondéré/latence/santé et les changements transactionnels d'enregistrements.
• TTL (time to live) : durée pendant laquelle un resolver peut mettre en cache une réponse DNS. Des TTL courts accélèrent le basculement et amplifient le taux de requêtes.
• DWFM (Droplet Workflow Manager) : sous‑système EC2 qui gère les baux sur les hôtes physiques.
• Network Manager : publie la configuration VPC/réseau vers les instances et les appliances réseau.
• Global Tables (DynamoDB) : réplication multi‑région pour les tables, avec cohérence éventuelle et résolution de conflits.

Réflexions finales

Cette panne n'était pas « juste DNS ». C'était DNS + récupération du plan de contrôle + dynamique des health checks + intervention humaine — un rappel que la disponibilité est une propriété du système, pas une fonctionnalité d'un composant. La partie encourageante est la précision des mitigations proposées : sérialiser l'application des plans, modérer la suppression de capacité, tester la récupération sous charge. Reprenez ces modèles dans votre propre stack, et la prochaine fois que us‑east‑1 éternuera, votre appli aura besoin de moins de mouchoirs.