Résumé

  • Le 21 avril 2011, une modification de capacité sur le réseau principal d’EBS a envoyé du trafic vers un réseau de réplication moins capacitaire dans une zone de disponibilité de la région US East. Le retour de connectivité a déclenché des recherches simultanées de répliques, épuisant la capacité libre et amplifiant l’incident.
  • La responsabilité opérationnelle porte autant sur l’enveloppe de reprise — capacité de réserve, temporisation, isolation, délestage et visibilité — que sur la prévention du déclencheur initial. Les données publiques ne permettent toutefois ni d’identifier un responsable individuel ni de conclure à une faute juridique.

Une chronologie qui sépare le déclencheur de la cause profonde

À 0 h 47, heure du Pacifique, le 21 avril 2011, une opération de capacité sur le réseau principal d’Amazon Elastic Block Store a provoqué un déplacement incorrect du trafic vers le réseau de réplication. Selon le compte rendu d’AWS, ce second réseau disposait d’une capacité inférieure. De nombreux nœuds d’une zone de disponibilité de la région US East se sont alors retrouvés privés d’une connectivité primaire et secondaire réellement exploitable.

Ce geste est le déclencheur documenté. Il ne suffit pas, à lui seul, à expliquer l’ampleur ni la durée de la panne. L’architecture EBS de 2011 organisait le stockage en grappes répliquées contenues dans une zone de disponibilité, tout en s’appuyant sur un plan de contrôle régional. Après le rétablissement de la connectivité, les nœuds ont cherché simultanément des partenaires afin de rétablir leur niveau de réplication. Cette convergence de demandes a consommé la capacité disponible plus vite qu’elle ne pouvait être reconstituée.

Le mécanisme de protection est ainsi devenu un amplificateur. Une temporisation insuffisante entre les tentatives et une condition de concurrence rare ont entretenu une « tempête » de re-mirroring : plus les nœuds tentaient de restaurer leurs répliques, plus ils occupaient la réserve nécessaire à la reprise des autres. L’analyse technique d’InfoQ corrobore cette lecture générale, mais les faits internes sur l’architecture et la séquence restent attribués au rapport d’AWS.

Du stockage localisé au plan de contrôle régional

La dégradation principale concernait une zone de disponibilité, non l’ensemble de la région et encore moins le réseau mondial d’AWS. Pourtant, certaines conséquences ont franchi cette frontière. Des appels de création de volumes sont restés ouverts longtemps et ont occupé les threads d’un pool du plan de contrôle régional. Cette saturation a produit des erreurs et de la latence dans les API EBS au-delà de la zone directement touchée, pendant des périodes circonscrites.

Cette distinction est essentielle pour l’analyse de responsabilité. Un composant peut être isolé physiquement tout en partageant une ressource de coordination. La promesse d’une frontière de panne dépend donc non seulement de l’emplacement des données, mais aussi des files d’attente, pools de threads, mécanismes de temporisation et chemins de commande communs. AWS a progressivement isolé la grappe dégradée et limité la charge afin de rétablir les fonctions du plan de contrôle, tandis que l’ajout de capacité physique et la restauration des répliques se poursuivaient par étapes.

Les jalons ne doivent pas être confondus. Arrêter la croissance du dommage ne signifie pas que toutes les répliques sont restaurées. Rendre les API de nouveau utilisables ne signifie pas que les files d’attente sont vidées. Stabiliser une grappe ne signifie pas que chaque volume a retrouvé un état cohérent. C’est pourquoi la reprise s’est étendue sur plusieurs jours, avec des traitements de backlog et des interventions résiduelles après les premières améliorations visibles.

Deux pourcentages, deux questions différentes

AWS a indiqué qu’environ 13 % des volumes de la zone de disponibilité affectée étaient encore bloqués lorsque la grappe a été stabilisée. Ce chiffre ne concerne ni tous les volumes de la région US East, ni tous les clients, ni l’ensemble d’AWS. Il mesure une population de volumes dans une zone déterminée à une étape précise de la reprise.

AWS a ensuite déclaré que 0,07 % des volumes de cette même zone n’avaient pas pu être restaurés dans un état cohérent. Ce second pourcentage ne peut pas être substitué au premier : il décrit une issue finale plus étroite et possède son propre dénominateur. Les sources examinées ne donnent ni le nombre de clients correspondant, ni le volume d’octets ou d’enregistrements concernés, ni une estimation complète du préjudice économique. Parler d’une perte généralisée de données dépasserait donc les éléments disponibles.

Cette rigueur de dénominateur est une composante de la responsabilité. Un indicateur sans population, instant de mesure et définition de l’état peut rassurer ou inquiéter à tort. Une clôture auditable doit montrer combien d’objets ont été touchés, combien ont été restaurés, lesquels restent incertains et quels écarts nécessitent encore une intervention manuelle.

RDS et les dépendances en aval

L’incident a aussi révélé qu’un service présenté à un niveau d’abstraction supérieur peut conserver une dépendance critique au stockage. Amazon RDS utilisait EBS pour les bases et leurs journaux. AWS a rapporté qu’une condition jamais rencontrée auparavant avait empêché le basculement automatique d’un sous-ensemble d’instances Multi-AZ, imposant une intervention manuelle. Cela ne signifie pas que toutes les configurations Multi-AZ ont échoué, ni que leur comportement était identique à celui des instances à zone unique.

Heroku a décrit directement une panne applicative étendue sur sa plateforme. Les reportages contemporains ont aussi nommé plusieurs services publics affectés et évoqué les difficultés rencontrées autour de RDS. Ces éléments établissent une chaîne de dépendance et un impact visible. Ils ne démontrent pas que chaque service a subi la même cause technique, la même durée, la même qualité de reprise ou la même conséquence sur ses données.

La séparation des rôles doit rester tout aussi nette. Le fournisseur contrôlait l’architecture du stockage, les réseaux internes, la capacité de réserve, le plan de contrôle et les mécanismes de reprise. Les clients contrôlaient leur architecture applicative, certaines options de redondance et leurs procédures de continuité. Mais l’existence d’un choix client ne transfère pas au client la responsabilité de défauts internes qu’il ne pouvait ni observer ni corriger. Inversement, la responsabilité du fournisseur ne garantit pas qu’une application dépourvue de plan de reprise échappe à toute interruption.

Les mesures annoncées et leur limite probatoire

Après l’incident, AWS a annoncé une augmentation des réserves de capacité de reprise, des temporisations plus agressives, la correction de la condition de concurrence, de meilleurs timeouts et mécanismes de délestage, un isolement renforcé entre zones, davantage d’automatisation de la reprise, des outils Multi-AZ améliorés et des communications plus fréquentes.

Cette liste répond de façon cohérente à la chaîne causale observée. Plus de capacité réduit le risque qu’une restauration massive épuise la réserve. La temporisation empêche tous les nœuds de réclamer simultanément les mêmes ressources. Le délestage protège le plan de contrôle. L’isolation limite la propagation. Des outils de reprise et une visibilité plus fine raccourcissent le temps entre diagnostic et action.

Cependant, les cinq sources scellées prouvent que ces changements ont été annoncés, pas qu’ils ont tous été achevés, testés indépendamment ou maintenus sous la même forme jusqu’à aujourd’hui. L’architecture décrite est celle de 2011. Elle ne doit pas être présentée comme une description actuelle d’EBS ni comme une évaluation de la fiabilité contemporaine d’AWS.

La capacité de reprise comme contrôle de responsabilité

La leçon la plus importante n’est pas qu’un réseau de secours doit être aussi grand qu’un réseau principal en toute circonstance. Elle est qu’un opérateur doit connaître l’enveloppe de reprise de son système : combien de composants peuvent réclamer une nouvelle réplique ensemble, quelle capacité libre cette demande consomme, quand les tentatives ralentissent, quelles ressources communes peuvent saturer et à quel moment l’automatisation doit céder la place à une intervention contrôlée.

Cette enveloppe devient un contrôle de responsabilité lorsqu’elle est mesurable avant l’incident et vérifiable après celui-ci. Les tests devraient inclure une restauration simultanée à grande échelle, la pénurie partielle de capacité, la lenteur d’un partenaire, la saturation du plan de contrôle et une condition de concurrence. Ils devraient vérifier non seulement le retour nominal du service, mais aussi la conservation de l’isolation, la progression du backlog et la cohérence finale des objets.

L’incident n’établit pas une faute individuelle, une négligence, une violation contractuelle ou réglementaire, ni une responsabilité juridique. Le dossier public n’identifie pas qui a approuvé la modification réseau, quelles informations étaient disponibles à cette personne ou quels contrôles précis entouraient la décision. En revanche, il permet de distinguer trois niveaux : le geste qui déclenche, les conditions qui amplifient et les choix de conception ou d’exploitation qui déterminent la capacité à réduire le dommage.

Ce que le dossier permet d’affirmer

Le cas EBS montre qu’une reprise peut échouer par excès de demandes légitimes plutôt que par absence de protection. La réplication a bien cherché à restaurer la redondance ; c’est son activation simultanée, dans une enveloppe de capacité trop étroite et avec une temporisation insuffisante, qui a créé la boucle d’amplification. Le plan de contrôle régional a ensuite fourni un second canal de propagation, malgré la concentration du dommage de stockage dans une zone.

Il montre aussi pourquoi la communication doit suivre la granularité réelle des ressources. Un statut régional trop large masque les différences entre zone touchée, API dégradée et services dépendants. Un statut trop optimiste, fondé sur le seul retour d’une API, masque le travail de restauration encore en cours. Des mises à jour utiles devraient distinguer confinement, disponibilité du contrôle, restauration des répliques, cohérence des volumes et cas résiduels.

Enfin, le dossier ne justifie pas de transformer un incident ancien en jugement sur le service actuel. Sa valeur réside dans la méthode : reconstruire la chronologie, séparer déclencheur et causes contributives, respecter les dénominateurs, identifier les ressources partagées, attribuer les actions annoncées et conserver les inconnues. C’est à cette condition qu’une panne devient une source d’assurance plutôt qu’un récit de blâme.

Sources