AWS us-east-1 : une panne de refroidissement dans une zone arrête Coinbase pendant plusieurs heures

2026-05-07 · Éditeur : AWS · Domaine : Cloud & DevOps

Le 7 mai 2026, un événement thermique dans une zone de disponibilité de us-east-1 prive des serveurs d'alimentation. Coinbase arrête ses échanges plusieurs heures : trois des cinq nœuds de son moteur d'appariement étaient dans la zone touchée.

Ce qui change

  • Événement thermique dans une zone de disponibilité de us-east-1 : refroidisseurs en panne, racks arrêtés.
  • EC2 et EBS dégradés ; AWS conseille d'utiliser les autres zones de la région.
  • Coinbase perd trois nœuds sur cinq de son moteur d'appariement, donc son quorum.
  • Le post-mortem de Coinbase pointe l'absence de bascule automatique entre zones.

### Ce qui change Le jeudi 7 mai 2026 en fin d'après-midi (heure du Pacifique), **AWS** signale un événement thermique dans une seule zone de disponibilité de sa région **us-east-1** (Virginie du Nord). Des refroidisseurs tombent en panne, des racks sont arrêtés par sécurité thermique, et AWS constate des instances EC2 et des volumes EBS dégradés. Elle recommande d'utiliser les autres zones de la région pendant la reprise. Cette panne est la quatrième de us-east-1 recensée en 2026, selon The Stack. ### Caractéristiques - Coinbase a publié un post-mortem : son moteur d'appariement est un cluster Raft placé dans un seul « cluster placement group » AWS, pour minimiser la latence. Trois de ses cinq nœuds ont disparu en même temps : le cluster a perdu son quorum et n'a plus pu traiter d'ordres. - Achats, ventes, dépôts, retraits et transferts ont été impossibles pendant plusieurs heures ; les échanges ont été rétablis par étapes, en mode « annulation seule » puis en enchères. - Problèmes d'architecture relevés : pas de bascule automatique vers une autre zone, infrastructure Kafka restée dans la zone en panne, reprise nécessitant des changements de code d'urgence et une reconstruction manuelle du cluster. - Mesures de Coinbase : reprise automatique entre zones, meilleures procédures de rétablissement du quorum, messagerie plus résiliente, tests de reprise élargis. ### Pourquoi c'est important AWS n'a perdu qu'une zone, ce qui est exactement le scénario que la conception multi-zones doit absorber : la panne a duré parce que le client avait concentré sa partie critique dans cette zone pour gagner en latence. Pour les DSI, la leçon est de distinguer ce que le fournisseur garantit (la zone peut tomber) de ce que l'architecture doit assurer (survivre à la perte d'une zone), en particulier pour les systèmes à quorum. ### À retenir Une panne de refroidissement dans une zone a suffi à arrêter un échange financier : la résilience se joue dans l'architecture du client.

Liens

Tags : Incident, AWS, Datacenter, Hyperscaler