Amazon Web Services : autopsie d’un pépin dans le cloud

A ses clients plus ou moins connus (Foursquare, Quora…), mais tous situés dans l’est des Etats-Unis, Amazon a donc présenté ses excuses et avait déjà expliqué techniquement le concours de circonstances qui a abouti aux pannes affectant le bon fonctionnement de ses services cloud EC2 dans un document de 25 pages.

Un crédit de dix jours d’utilisation est également offert à tous les clients qui sollicitaient les serveurs touchés par ces pannes. Ce sont les serveurs situés dans l’EBS (Elastic Block Stores) qui ont été touchés.

Les choses sont rentrées dans l’ordre dès le 24 avril, et le 25 avril, tout était à nouveau fonctionnel à presque 100%, même si certaines données ont été définitivement perdues.

Amazon profitera de l’incident pour en tirer des leçons et fiabiliser ses équipements. Mais on notera justement que l’élément déclencheur a été « une modification de la configuration du réseau » .

L’erreur est apparemment humaine et elle s’est traduite par une boucle sans fin : « a re-mirroring storm », littéralement une tempête liée à la réplication des données sur d’autres serveurs ou du moins à son impossibilité à le faire, d’où la boucle sans fin.

Cette erreur humaine serait intervenue lorsqu’il s’est agit de rediriger le trafic du réseau primaire qui était visé par une augmentation de sa capacité.

Le trafic ne l’a pas été vers un serveur redondant équivalent en capacité du réseau primaire, mais vers un réseau redondant de moindre capacité. S’en est suivie une impossibilité pour certains utilisateurs à accéder aux services.

En filigrane, c’est toute la question des services délocalisés dans le cloud qui se pose ou ne se pose pas, puisque tous les utilisateurs savent parfaitement que le risque 0 n’existe pas.

AWS garantit une disponibilité à 99.95% (SLA : Satisfaction Level Agreement) de ses niveaux de service d’Amazon EC2 pour chacune des régions Amazon EC2 (dont la région de l’est des Etats-Unis touchée cette fois-ci).

La redondance est là pour palier aux pannes mais Amazon se rend compte que l’erreur est presque systématiquement humaine que ce soit dans le cloud ou ailleurs et dans d’autres domaines.

De nouveaux garde-fous pourraient donc être mis en place pour vérifier que les commandes de redirection d’un serveur vers un autre dans le cloud ne restent pas lettre morte.