Consultation

Étude de cas · Infonuagique

AWS us-east-1 : un enregistrement DNS vide, une journée de pannes en cascade

Monde, octobre 2025. Une condition de concurrence dans l'automatisation DNS de DynamoDB prive la région d'une adresse, et de nombreux services tombent avec elle.

En une phraseUn enregistrement DNS vide dans une région : quatorze heures et demie de perturbation. Le coupable n'était pas un serveur, c'était l'automatisation.

Secteur
Infonuagique, tous secteurs
Région
us-east-1 (Virginie du Nord)
Date
19–20 octobre 2025
Durée de l'événement
Environ 14 h 30, de 23 h 48 (HAP) à 14 h 20 (HAP)
Cause selon AWS
Condition de concurrence latente dans la gestion DNS de DynamoDB

Analyse fondée uniquement sur des informations publiques. FZ Consultation n'a pas participé à cet incident et n'a aucun lien avec les organisations mentionnées.

Ce qui s'est passé

  1. 19 oct., 23 h 48 (HAP)

    Les appels à l'API DynamoDB échouent en us-east-1 : clients et services AWS ne peuvent plus ouvrir de nouvelles connexions.

  2. 20 oct., 0 h 38

    AWS identifie l'état DNS de DynamoDB comme source du problème.

  3. 2 h 25 – 2 h 40

    Toutes les informations DNS sont rétablies ; les enregistrements en cache expirent et les clients se reconnectent. DynamoDB est de retour, après environ 2 h 52.

  4. 2 h 25 – 10 h 36

    Le lancement d'instances EC2 continue d'échouer pendant des heures après le retour de DynamoDB.

  5. 5 h 30 – 14 h 09

    Les répartiteurs de charge réseau (NLB) renvoient des erreurs de connexion, à cause d'échecs de vérification de santé.

  6. 20 oct., 14 h 20

    Fin de l'événement selon AWS. Certains clusters Redshift restent altérés jusqu'au 21 octobre.

Ce qui a mal tourné

D'après les sources publiques citées plus bas.

Une automatisation qui se défait elle-même

Selon AWS, deux « Enactors » DNS se sont croisés : l'un, en retard, a appliqué un ancien plan après un plan plus récent ; le nettoyage a ensuite supprimé l'ancien plan et retiré toutes les adresses du point d'accès régional. Le système, incohérent, a exigé une intervention manuelle.

Le correctif n'était que la moitié de la reprise

Une fois le DNS rétabli à 2 h 25, le lancement d'instances EC2 a échoué jusqu'à 10 h 36 et les erreurs NLB ont duré jusqu'à 14 h 09. La reprise d'un service en amont ne règle pas ses dépendants.

Les outils pour réagir étaient dans la zone touchée

Les connexions à la console AWS par utilisateurs IAM ont échoué pendant plus d'une heure et demie et l'accès aux dossiers du Centre de support a été bloqué pendant près de trois heures.

Les leçons pour votre organisation

  1. 1

    Trouvez votre dépendance régionale cachée

    Beaucoup de services « globaux » reposent en réalité sur une région. Cartographiez-les avant la panne.

    Savoir : mesurer ce qu'un arrêt coûterait
  2. 2

    Testez la panne du fournisseur, pas seulement la vôtre

    Simulez la perte d'une région et chronométrez la reprise réelle, avec les dépendances en cascade.

    Prouver : répéter avant le vrai jour
  3. 3

    Gardez un canal hors bande

    Prévoyez comment joindre équipes, clients et fournisseur quand vos outils habituels sont inaccessibles.

    Liste de vérification rançongiciel

À vérifier lundi matin

Trois questions à poser à votre propre organisation cette semaine. Si vous ne pouvez pas répondre à l'une d'elles en cinq minutes, c'est votre première tâche.

  1. Quels services de votre organisation dépendent d'une seule région infonuagique, y compris pour l'identité, les files de messages ou la configuration ?
  2. Si la console de votre fournisseur et son support étaient inaccessibles, comment joindriez-vous vos équipes et vos clients ?
  3. Avez-vous déjà simulé la perte d'une région, pas seulement d'un serveur, en mesurant le temps réel de reprise ?
Chiffrer une journée de panne infonuagique

Sources

Autres études de cas