La panne d'AWS du 7 décembre dernier avait perturbé des milliers de sites web dont The Associated Press, Disney+ et Netflix. L'incident, qui a duré plusieurs heures, avait affecté les infrastructures du groupe dans la région US-EAST-1 et débouché sur des indisponibilités de services EC2, Connect, DynamoDB, Glue, Athena, Timestream, Chime... Des explications ont été fournies par Amazon pour mieux comprendre ce qui s'est passé. Dans un billet de blog, le groupe indique d'abord s'appuyer sur un réseau interne pour héberger ses services « fondamentaux » incluant la surveillance, le DNS interne, les services d'autorisation, ainsi que des parties de son control plane EC2. « Compte-tenu de l'importance de ces services sur son réseau interne, AWS le connecte sur de multiples équipements isolés géographiquement et met à l'échelle sa capacité pour s'assurer de la disponibilité de sa connectivité », explique le groupe. Ces équipements fournissent du routage additionnel et de la translation d'adresse réseau permettant aux services AWS de communiquer entre le réseau interne et le principal. 

A 7:30 AM PST, AWS relate qu'une activité automatisée pour faire évoluer la capacité de l'un de ses services hébergés dans son réseau principal a déclenché un comportement inattendu de la part d'un grand nombre de postes clients à l'intérieur de son réseau interne. « Cela a entraîné une forte augmentation de l'activité de connexion qui a submergé les équipements réseau entre le réseau interne et le principal, entraînant des retards de communication entre les deux », poursuit la société. « Ces retards ont augmenté la latence et les erreurs pour les services communiquant entre ces réseaux, entraînant encore plus de tentatives et de nouvelles tentatives de connexion. Cela a entraîné une congestion persistante et des problèmes de performances sur les équipements connectant les deux réseaux ».

Le réseau interne congestionné

Suite à cet événement, la congestion réseau a impacté la fiabilité des données de surveillance temps réel, entravant le travail des équipes d'exploitation pour identifier son origine. « Les opérateurs se sont plutôt appuyés sur les logs pour comprendre ce qui se passait et ont initialement identifié des erreurs DNS internes élevées. Étant donné que le DNS interne est fondamental pour tous les services et que ce trafic était censé contribuer à la congestion, les équipes se sont concentrées sur l'éloignement du trafic DNS interne des chemins réseau encombrés », fait savoir le fournisseur. Une fois les erreurs de résolution DNS réparées à 9h28, la disponibilité de plusieurs services a été améliorée sans pour autant être totalement résorbée.

« Les opérateurs ont continué à travailler sur un ensemble de mesures correctives pour réduire la congestion sur le réseau interne, notamment en identifiant les principales sources de trafic à isoler sur des périphériques réseau dédiés, en désactivant certains services gourmands en ressources et en mettant en ligne une capacité réseau supplémentaire. Cela a progressé lentement pour plusieurs raisons. Premièrement, l'impact sur le contrôle interne a limité notre capacité à comprendre le problème. Deuxièmement, nos systèmes de déploiement internes, qui fonctionnent dans notre réseau interne, ont été touchés, ce qui a encore ralenti nos efforts de remédiation. Enfin, étant donné que de nombreux services sur le réseau AWS principal et les applications clientes fonctionnaient toujours normalement, nous voulions être extrêmement prudent pour éviter un impact sur les charges de travail opérationnelles », explique le fournisseur. Il aura fallu attendre jusqu'à 13h34 pour voir l'incident se résorber partiellement et 14h22 totalement.

De multiples impacts sur les services AWS

Suite à cet incident, plusieurs services ont rencontré des problèmes de control plane utilisé pour créer et gérer les ressources AWS, ceux-ci reposant justement sur des services hébergés dans le réseau interne du fournisseur. En particulier à cause d'une défaillance des API : « alors que l'exécution d'instances EC2 n'a pas été affectée par cet événement, les API EC2 que les clients utilisent pour lancer de nouvelles instances ou pour décrire leurs instances actuelles ont connu des taux d'erreur et des latences accrus à partir de 7h33 PST », observe AWS. De même, si les services Elastic Load Balancers (ELB) existants n'ont pas été directement impactés, les taux d'erreur d'API et les latences élevés pour les API ELB ont entraîné une augmentation des temps de provisionnement pour les nouveaux équilibreurs de charge, et aussi des délais d'enregistrement d'instances pour ajouter des VM supplémentaires.

« De plus, les API Route 53 ont été altérées de 7h30 PST à 14h30 PST, empêchant les clients d'apporter des modifications à leurs entrées DNS, même si celles existantes et les réponses aux requêtes DNS n'ont pas été affectées pendant cet événement », précise AWS. Le service Secure Token Service (STS) a aussi rencontré des latences élevées lors de l'envoi d'informations d'identification pour des fournisseurs d'identité tiers via OpenID Connect (OIDC). « Cela a entraîné des échecs de connexion pour d'autres services AWS qui utilisent STS pour l'authentification, tels que Redshift », explique Amazon. La console de supervision CloudWatch a aussi été touchée et l'accès aux buckets Amazon S3 et aux tables DynamoDB via les points de terminaison VPC a été altéré. «  Les API Lambda et l'appel des fonctions Lambda ont fonctionné normalement tout au long de l'événement. Cependant, API Gateway, qui est souvent utilisé pour appeler des fonctions Lambda ainsi qu'un service de gestion d'API pour les applications client, a connu des taux d'erreur accrus. Les serveurs API Gateway ont été affectés par leur incapacité à communiquer avec le réseau interne au début de cet événement », a fait savoir l'éditeur. « EventBridge, qui est également souvent utilisé en conjonction avec Lambda, a rencontré un nombre élevé d'erreurs au cours des phases initiales de l'événement, mais a connu une certaine amélioration à 9h28 PST lorsque le problème DNS interne a été résolu ».

Les services de conteneur AWS, y compris Fargate, ECS et EKS, ont connu une augmentation des taux d'erreur et des latences d'API pendant l'événement. Alors que les instances de conteneur existantes (tâches ou pods) ont continué de fonctionner normalement pendant l'événement, si une instance de conteneur était arrêtée ou rencontrait une défaillance, elle ne pouvait pas être redémarrée en raison de l'impact sur les API du control plan EC2. En outre, Amazon Connect a aussi connu des taux d'échec élevés pour la gestion des appels téléphoniques, des sessions de discussion et des contacts de tâches pendant l'événement. Les problèmes avec les passerelles API utilisées par Connect pour exécuter des fonctions Lambda ont entraîné des taux d'échec élevés pour les appels téléphoniques entrants, les sessions de discussion...

Empêcher le problème de ressurgir

Pour éviter que cet événement ne se reproduise, AWS a désactivé les activités de mise à l'échelle automatisée ayant déclenché cet événement mais prévoit de les reprendre quand toutes les mesures correctives auront été prises. Nous développons un correctif pour ce problème et prévoyons de déployer ce changement au cours des deux prochaines semaines. Nous avons également lancé une configuration réseau supplémentaire qui protège les équipements réseau potentiellement touchés si ce cas de figure de congestion ressurgit », indique AWS. Des mesures correctives qui doivent donner au fournisseur l'assurance de ne plus voir ce problème se reproduire.