Multicloud, responsabilité partagée, résilience : les leçons à retenir de la panne d’AWS
L’incident technique subi par AWS le 20 octobre met en lumière plusieurs problèmes inhérents au cloud, à AWS et au modèle de responsabilité partagée. Les experts du milieu rappellent la nécessaire vigilance des DSI en matière de résilience et d’investissement IT.
La panne de la région cloud AWS US-East 1 (Virginie du Nord) du 20 octobre a affecté un grand nombre d’applications et de systèmes. Elle a concerné Canva, Slack, Datadog,Salesforce, GitHub, Vodafone, Lloyd Bank, et bien d’autres applications grand public (Fortnite, Snapchat, Roblox, Clash Royale, Epic Game Store, etc.).
Vu de loin, il a suffi de la défaillance d’un seul service AWS, Amazon DynamoDB, pour que 141 autres soient impactés. Entre la déclaration de la panne et le retour à la normale, 15 heures se sont écoulées.
AWS a promis un post-mortem détaillé. En attendant, ces équipes mettent en évidence le déclencheur de l’événement. Il s’agit d’un problème de résolution DNS affectant les API régionales du service de base de données NoSQL DynamoDB. En clair, ces API n’étaient pas joignables, ce qui ne permettait pas de résoudre les noms d’hôte en IP. « C’est toujours le DNS », dit un vieux dicton d’administrateurs système.
« C’est toujours la faute du DNS »
La cause profonde a été identifiée environ deux heures après les premières erreurs observées. DynamoDB a été restaurée une heure après. Or, le SGBD NoSQL est utilisé pour gérer le sous-système interne qui lance les instances EC2. Ce qui a fait tousser le service de calcul. Et l’ensemble des services associés.
« Alors que nous continuions à travailler sur les défaillances du lancement des instances EC2, les contrôles d’intégrité du répartiteur de charge réseau ont également été affectés, ce qui a entraîné des problèmes de connectivité dans plusieurs services tels que Lambda, DynamoDB et CloudWatch », expliquent les SRE d’AWS. Une réaction en chaînes, donc.
Ces effets indésirables ont réclamé de limiter certaines opérations, « dont le lancement d’instances EC2, le traitement des files d’attente SQS via le mappage de sources d’événements et les invocations Lambda asynchrones ».
L’objectif était de contrôler le trafic et empêcher l’effondrement des systèmes fonctionnels le temps de la restauration des différents services. Dans un même temps, les SRE ont travaillé pour rétablir la connectivité.
Un problème de concentration, selon Forrester
Ce n’est pas la première panne qui affecte la région est des États-Unis. Selon Brent Ellis, analyste principal chez Forrester, c’est la quatrième en cinq ans.
Celle du 20 octobre, l’une des plus longues à ce jour, met en lumière plusieurs problèmes. Le premier n’est pas exclusif à AWS. La majorité des sites Web, des applications et des services exposés sur le Web dépendent d’un système de nom de domaine. Ce protocole créé en 1983, et qui a permis l’émergence d’Internet, demeure complexe à déployer et à maintenir.
Dans ce cas précis, la panne a d’abord affecté une « brique centrale » du dispositif d’AWS. En effet, DynamoDB est utilisé pour enregistrer les états de différents services et en administrer la synchronisation, de même qu’il peut gérer la réplication des données entre différentes régions cloud.
Autre problème, US-East 1 est la région par défaut de nombreux services AWS. En outre, elle abrite le control plane de Route 53, le service qui gère les DNS publics et privés, et le control plane du gestionnaire des identités et des accès (IAM) d’AWS.
« Un risque systémique dangereusement puissant apparaît lorsque tant d’entreprises de tous les secteurs deviennent dépendantes d’un seul fournisseur de cloud [et d'une seule région couverte par lui]. »
Brent EllisAnalyste principal, Forrester
Qui plus est, la région US-East 1 est souvent la mieux dotée en services. Et la moins chère. Comme beaucoup d’entreprises s’appuient sur cette même région pour propulser leurs solutions, la concentration auprès de la filiale d’Amazon devient un problème mondial au moment d’une panne.
« Un risque systémique dangereusement puissant, mais souvent négligé, apparaît lorsque tant d’entreprises de tous les secteurs deviennent dépendantes d’un seul fournisseur de cloud et, plus précisément, d’une seule région couverte par ce fournisseur », note Brent Ellis.
Personne n’est à l’abri d’un couac informatique. Même les géants du cloud, rappelle l’analyste de Forrester. Dans la plupart des cas, AWS renvoie à son modèle de responsabilité partagée. Celui-ci stipule les briques dont AWS a l’administration exclusive, celles dont il partage le contrôle et celles qui sont à la charge des clients.
« Mais lorsque des services essentiels tels que le DNS tombent en panne, même les applications bien conçues peuvent devenir instables », note l’analyste de Forrester. « AWS s’efforce de réparer son infrastructure, mais de nombreuses entreprises doivent attendre que cela soit fait, même si elles ont suivi les modèles de conception recommandés », poursuit-il.
Un rappel nécessaire des pratiques de résilience
Un problème « récurrent dans la région US-East-1 où les clients sont laissés pour compte lorsqu’il s’agit de faire face aux conséquences de la panne ». AWS n’est toutefois pas le seul à souffrir de ce défaut, souligne l’analyste.
Brent Ellis recommande d’investir dans l’observabilité, l’automatisation du fail-over, et la mise en place de tests à l’échelle des systèmes de backup et de reprise après sinistre. Pour que cela fonctionne, d’autres précautions sont nécessaires.
En matière de résilience, l’approche multi-AZ ne semble pas suffire. Surtout si ces zones de disponibilités sont présentes dans une seule région cloud. L’approche multirégion est plus indiquée. C’est le choix qu’a fait la startup Oso, éditrice d’une solution d’IA agentique. Elle suit en grande partie les préceptes érigés par AWS dans sa documentation « Well Architect Framework ».
Cette précaution a permis de ne pas subir l’arrêt des services, même si quelques ralentissements se sont fait ressentir. Plusieurs professionnels s’exprimant sur le Web estiment désormais que le déploiement multirégion n’est plus une option. En tout cas, pour les applications critiques.
Ce choix n’est toutefois pas anodin. Il faut que les instances nécessaires au fonctionnement des SI soient déjà en route et que les données soient en cache, pour ne pas subir les effets de bord qui affecteraient la région principale. Tout cela représente la mobilisation de ressources financières supplémentaires. C’est aussi, de manière générale, plus complexe à configurer. De même, la migration d’une région cloud AWS à une autre est un processus coûteux, dixit les internautes.
Apologie du multicloud
Ce ne serait pas forcément suffisant, selon un expert.
« Les déploiements multirégion offrent une protection contre les pannes d’infrastructure régionales, mais pas contre les pannes du plan de contrôle centralisé, qui peuvent avoir un impact mondial », souligne pour sa part Rohit Sharma, directeur associé IA et architecte principal chez Cognizant.
« La véritable solution exige que les fournisseurs de services cloud investissent dans la décentralisation des plans de contrôle, mais il s’agit là d’un projet architectural colossal dont le retour sur investissement est incertain compte tenu de la dynamique concurrentielle actuelle », poursuit-il.
« Les architectes doivent comprendre que pour garantir une véritable résilience face aux défaillances au niveau des fournisseurs, il faut probablement mettre en place des stratégies multicloud. »
Rohit SharmaDirecteur associé IA et architecte principal, Cognizant
Pour autant, il semble plus important pour les fournisseurs cloud d’investir dans les fermes GPU et l’infrastructure réseau associée.
« En attendant que cela se produise, les architectes doivent comprendre que pour garantir une véritable résilience face aux défaillances au niveau des fournisseurs, il faut probablement mettre en place des stratégies multicloud, et pas seulement multirégionales au sein d’un même fournisseur », conseille Rohit Sharma. Un autre constat partagé par plusieurs ingénieurs sur LinkedIn et Twitter.
Dans l’Union européenne, le Data Act est censé simplifier l’interopérabilité des déploiements multicloud et abaisser les coûts de migrations. Les fournisseurs de cloud commencent à s’y plier, mais aimeraient faire bouger les lignes pour conserver leur part de marché (et en gagner). Ils sont également concernés, dans le secteur de la finance, par la loi DORA.
Est-ce toujours la responsabilité du client ?
Peu importe l’approche choisie, Brent Ellis estime que cela va au-delà de l’application des lois comme le Data Act et DORA.
En clair, c’est à nouveau au client de prendre leur responsabilité. À eux de cartographier leurs dépendances, de s’assurer que leurs fournisseurs ont eux-mêmes bâti des plans pour contrer les pannes. C’est d’autant plus vrai à l’ère du SaaS où les éditeurs ont concentré les déploiements cloud.
Outre le fait d’ouvrir les yeux sur les moyens techniques de résilience, l’incident subi par AWS peut aussi être l’occasion de lancer des discussions contractuelles, croit l’analyste de Forrester.
« Si vous souhaitez obtenir une compensation financière ou des remises pour les temps d’arrêt, préparez-vous à négocier », écrit-il « Si les fournisseurs refusent, demandez-vous si le prix que vous avez négocié est toujours raisonnable et, éventuellement, s’il est judicieux de continuer à faire affaire avec eux ».
