La violente tempête qui s'est abattue sur le milieu de l'Atlantique, vendredi soir, a provoqué des pannes électriques chez AWS. Les solutions Elastic Cloud Compute (EC2), Elastic Block Storage (EBS) et Relationnal Database Service (RDS) ont été touchées en premier, mais la panne s'est aussi étendue au « service de régulation » Elastic Load Balancer, qui sert justement à transférer le trafic hors de la zone affectée.

Suite à ses multiples coupures électriques, Amazon a dû recourir à des générateurs de secours. Peu de temps avant 20 heures, un générateur de secours n'a pu être mis en route après une panne de courant. Une autre alimentation supposée empêcher les coupures a été inefficace pendant environ 7 minutes. Pendant 10 minutes, à 20H04, certaines parties du datacenter affecté ont été privées de courant, si bien que les services EC2 et EBS étaient inaccessibles dans la zone concernée.

En conséquence, vendredi soir, pendant plus d'une heure - entre 20H04 et 21H10 - les clients d'AWS étaient dans l'impossibilité de créer de nouvelles instances EC2 ou de nouveaux volumes EBS. « La « plupart » des instances étaient à nouveau en ligne à partir de 23H15 jusqu'à un peu après minuit », a déclaré Amazon. Mais cette reprise a été quelque peu retardée à cause d'un goulot d'étranglement au redémarrage du serveur du fait du nombre important de demandes. « C'est un élément de la procédure que nous devons améliorer en cas de panne de courant », a déclaré le fournisseur de services en ligne.

Un système de bascule inopérant

AWS a divisé ses régions en zones de disponibilité multiples (Availability Zones). Normalement, le système a été conçu pour être à l'abri des pannes. Mais vendredi, même si le problème n'a concerné qu'une seule région, AWS a du faire face à un problème global, au moment où les équilibreurs de charge ont essayé de basculer le trafic vers des zones de disponibilités intactes. « Avec le retour du courant et la remise en route des systèmes, un grand nombre d'Elastic Load Balancers se sont trouvés dans une situation qui a déclenché un bug que nous n'avions jamais expérimenté », écrit Amazon. Ce bug a entrainé un afflux de demandes qui se sont ajoutées à la demande de reprise des instances EC2, provoquant un effet retard dans le système.

Entre temps, l'indisponibilité de l'EBS a eu un impact  sur le service de base de données relationnelle dans le cloud, RDS, qui a souffert aussi d'un autre bug logiciel. Les clients qui dépendaient du service RDS situé dans la zone affectée ont dû attendre la restauration de l'EBS. La plupart ont pu y avoir à nouveau accès à 23H00. Pour les clients dont la base de données était répartie entre des zones de disponibilité multiples, AWS a expliqué que le bug logiciel n'avait pas permis, pour certains clients, le basculement automatique vers des zones non touchées. Amazon ajoute que l'existence de ce bug était connue depuis le mois d'avril, et qu'elle disposait d'un correctif, encore en version bêta,  pour y remédier. Il sera déployé dans les prochaines semaines.

Des clients directement impactés dans leur activité

Même si seul un petit pourcentage de clients a été touché par la panne, celle-ci a concerné un grand nombre d'utilisateurs, compte tenu du large domaine d'application de chacun. Parmi eux figurent par exemple Netflix, Instagram et Pinterest. Pour Netfix, partiellement en panne entre 20H00 et 23H00, la coupure a eu lieu avant le week-end, à une heure de grande écoute : c'est le moment où la demande de films de la part d'utilisateurs vivant sur la côte pacifique est la plus forte. Adrian Cockcroft, architecte du cloud de Netflix avait, dans le passé, fait l'éloge d'AWS et de sa fiabilité. Entre vendredi soir et samedi, il a commenté minute après minute chaque étape de la panne sur son compte Twitter. « Notre entreprise a suivi à la lettre les spécifications d'AWS et à fait le choix des zones de disponibilité multiple. Mais, cela ne semble pas avoir fonctionné ce vendredi ». Samedi, il a tweeté : « Notre hardware n'est plus disponible dans une zone, nous avons dupliqué nos données dans trois zones. Mais l'acheminement du trafic a été bloqué dans toutes les zones ».

Selon Shahin Pirooz, CTO et CSO du fournisseur de cloud CenterBeam, dans cette panne, AWS doit certainement assumer une partie de la responsabilité. « On a le sentiment d'un château de cartes qui s'est effondré sur eux », a-t-il déclaré. Celui-ci se dit surpris qu'autant de systèmes soient tombés en panne en même temps chez AWS. « Amazon a échoué, leurs systèmes de basculement ont échoué. AWS a sa part de responsabilité dans ces évènements », a-t-il estimé. Selon lui, « pour éviter ces concours de circonstances à l'avenir, il faudrait trouver une autre solution pour l'équilibreur de charge, les systèmes de noms de domaine et les offres de reprise après sinistre, pour ces systèmes tierces parties qui ne sont pas AWS ». Différentes entreprises offrent ce type de services, comme par exemple New Start, Akamai et DynDNS. « La situation idéale serait d'offrir aux clients la possibilité de fédérer les services à travers de multiples fournisseurs de cloud publics ». Mais Shahin Pirooz pense que « cette solution ne sera pas applicable avant 5 ou 10 ans, en tout cas pas tant que les fournisseurs de l'industrie adoptent des normes de migrations communes ».

C'est un peu ce que OpenStack essaye de faire. Mais des concurrents Open Source, comme CloudStack de Citrix, se sont raliés à AWS pour faire de ses systèmes un standard de facto.