Panne du service S3 chez AWS : Faut-il paniquer ?

10 avril 2018

– 3 min de lecture

Sébastien Grenier-Fontaine

Le service Cloud d’Amazon, AWS, a été victime récemment d’une panne majeure de son service de stockage simple nommé S3. Cette brique technique est très populaire et répandue pour implémenter des applications ou services hébergés chez AWS. Pour vous donner une idée de l’ampleur de son utilisation depuis son lancement en 2006, ce service permet aujourd’hui de stocker des dizaines de milliards d’objets. D’autres briques techniques chez Amazon peuvent s’appuyer sur ce stockage pour fonctionner comme le service Elastic Compute (EC2), Elastic Block Shop et Lambda. Cette panne de service a eu donc pour effet d’engendrer des perturbations majeures pour plusieurs applications hébergées chez AWS :

La messagerie instantanée Slack
Le service de stockage en ligne Box
Le service de livraison des pizzas Dominos
Les sites web communautaires Reddit et BuzzFeed

Heureusement la cause de l’incident a vite été repérée et corrigée par l’hébergeur. En revanche, elle a tout de même engendré des indisponibilités de plusieurs heures pour certaines de ces applications. Est-ce que les entreprises ayant pris la décision de faire appel à du Cloud Public doivent pour autant entrer en mode panique et rapatrier leurs applications et données chez eux ? La réponse est NON bien entendu. Amazon a rapidement communiqué que la nature de la panne du service S3 était due à une erreur humaine déclenchée par un employé ayant toutes les autorisations et qui aurait soumis une commande manuelle avec de mauvais paramètres. De plus, l’impact de la panne se limitait uniquement au « datacenter » de la région Virginie située sur la côte Est des Etats-Unis. Une telle erreur aurait pu donc se produire n’importe où, chez n’importe quel fournisseur d’hébergement y compris dans vos propres « datacenters ».

Cet incident nous rappelle seulement qu’il ne faut pas se fier uniquement à la résilience de la couche infrastructure Cloud, même chez le leader du marché, pour garantir une haute-disponibilité. Il est bon de rappeler ici que les engagements de service (SLA) pour la brique S3 ne sont que de 99,99%. Ceci signifie tout de même une indisponibilité potentielle de 87,5 heures pour une année ! Le fournisseur de service de vidéo en ligne Netflix est aussi hébergé chez AWS et il a pourtant été épargné par la panne du service S3. Une étude réalisée en interne en 2014 avait permis d’estimer une perte de 200 000$ de chiffre d’affaires pour une heure d’arrêt de la plateforme. Nous pouvons donc estimer qu’en 2017 le coût total d’une panne de 4 heures aurait pu leur coûter plus d’1 million de dollars. Ceci est sans compter l’impact négatif sur la réputation et image auprès de leurs usagers qu’une telle panne aurait pu occasionner . En tenant compte de ces besoins, les architectes techniques de Netflix ont conçu une architecture cloud résiliente basée sur plusieurs zones AWS. Ceci leur permet donc d’éviter toute perte de service en cas de panne ou incident et d’avoir un meilleur SLA que les 99,99% promis par le fournisseur.

L’impact financier de l’arrêt de votre application métier est probablement moindre que celui de Netflix. Vous n’avez peut-être pas non plus un fournisseur Cloud ayant plusieurs « datacenters » dans différentes régions comme peut l’offrir AWS. Pour autant déployer vos applications sur du Cloud Computing ne vous affranchit pas du tout des services d’un architecte technique, au contraire ! Celui-ci, s’il déroule une démarche prenant compte des besoins métiers et des exigences non fonctionnelles, saura vous proposer des scénarios d’architectures résilientes. L’architecture finale sera plus chère et complexe sans doute. Il ne faut pas oublier dans ce cas d’estimer l’impact et la probabilité d’une perte de service avant d’évaluer si ces coûts supplémentaires en valent la chandelle.

Sources d’information pour incident AWS S3 survenu en mars 2017 :