5 Si vous n’avez pas subi l’interruption directement, vous en avez forcément entendu parler : la région AWS la plus sollicitée des États-Unis s’est éteinte (en anglais) et a entraîné avec elle de larges pans du web. Cette panne est un rappel brutal : même le plus grand fournisseur cloud (et l’épine dorsale d’une grande partie de l’économie numérique) peut tomber en panne. Des systèmes essentiels, dont les répartiteurs de charge, le DNS et DynamoDB, ont cessé de fonctionner, déclenchant une réaction en chaîne rapide. Les applications se sont figées, les transactions se sont bloquées et l’activité s’est arrêtée pour des millions d’utilisateurs. Le site d’e-commerce d’Amazon lui-même, Alexa et les sonnettes Ring ont été touchés, de même que de grandes plateformes grand public et professionnelles comme WhatsApp, ChatGPT, Venmo, Robinhood et Snapchat. Même certains services publics et de jeux ont connu des interruptions. Les ingénieurs d’AWS ont réagi rapidement et communiqué tout au long de l’incident. Les conséquences ont pourtant été considérables. Lorsqu’une seule entreprise exploite une part aussi importante de l’infrastructure mondiale, un seul dysfonctionnement peut se propager partout. Les détails de cet épisode s’estomperont peut-être, mais des événements de ce type se reproduiront. Le problème de fond : la dépendance excessive à un seul fournisseur Au cours de la dernière décennie, de nombreuses organisations ont regroupé presque tout sur un seul cloud public pour simplifier leur exploitation. Les garanties de niveau de service peuvent sembler solides, mais elles n’éliminent pas le risque concentré qu’implique cette dépendance. Lorsque toutes les charges de travail se trouvent au même endroit, toute perturbation se propage rapidement. Une stratégie résiliente exige davantage de contrôle et de diversité dans la conception de l’infrastructure. Les entreprises qui disposaient de systèmes distribués sont restées en ligne. Elles avaient testé leurs chemins de restauration et gardé leurs données essentielles sous leur propre contrôle. Cette approche est parfois qualifiée de « cloud-smart ». Elle conserve les avantages du cloud computing tout en préservant l’autonomie grâce à des infrastructures hybrides, privées et edge. Les principes suivants constituent un guide pratique pour bâtir ce type de résilience. Cinq principes pratiques pour une résilience cloud-smart Assumez la responsabilité de votre disponibilité. Même lorsque les fournisseurs cloud proposent des fonctions de résilience intégrées, votre disponibilité dépend toujours de leur infrastructure. Avec une architecture hybride ou sur site, vous n’attendez pas que la page d’état d’un tiers se mette à jour. Vous maîtrisez votre propre disponibilité et pouvez concevoir une redondance qui protège votre activité, et pas seulement le SLA de votre fournisseur. Que faire : identifiez les applications qui doivent rester en ligne en toutes circonstances. Créez pour elles des chemins redondants, idéalement répartis sur plusieurs régions ou environnements en dehors de votre fournisseur principal. Revoyez votre plan de continuité pour vous assurer que chaque dépendance externe est couverte. Gardez vos données essentielles à portée de main. Les grands jeux de données sont lents à déplacer, surtout en pleine crise. La restauration devient plus simple lorsque les informations critiques existent à plusieurs emplacements. Des copies locales ou régionales raccourcissent le chemin de la restauration. Que faire : classez vos données selon leur importance et l’interruption acceptable. Répliquez les jeux de données les plus critiques et les plus consultés sur plusieurs emplacements sécurisés. Testez régulièrement la restauration pour vérifier la rapidité d’accès, l’intégrité et l’immuabilité. Gardez le contrôle direct de la sécurité et de la conformité. Les fournisseurs cloud sécurisent leur infrastructure, mais la responsabilité de la protection des données vous incombe. Les exigences réglementaires, les politiques de chiffrement et la gouvernance doivent toujours être appliquées en interne. Que faire : gérez les clés de chiffrement en interne. Choisissez des emplacements de stockage conformes aux politiques légales et internes. Auditez régulièrement toutes les configurations cloud et sur site pour vous assurer qu’aucune ne dérive hors de la conformité. Préparez-vous aux coûts imprévus de la restauration. En cas de panne, la restauration entraîne souvent des dépenses supplémentaires. Les transferts de données, la capacité temporaire et la dégradation des performances peuvent tous faire grimper les coûts dans des moments difficiles. Que faire : modélisez l’impact financier d’une perturbation à grande échelle, y compris les frais de récupération des données, de sortie et de capacité temporaire. Intégrez ces variables à votre budget de résilience et gardez des systèmes secondaires prêts afin que la restauration ne dépende pas uniquement de ressources cloud à la demande. Associez agilité et contrôle Les architectures cloud apportent la flexibilité, tandis que les systèmes sur site apportent cohérence et supervision. Les organisations les plus solides appliquent les deux principes et apportent une agilité de type cloud partout où se trouvent leurs données. Les charges de travail s’exécutent là où elles sont le plus performantes et peuvent se déplacer lorsque les conditions changent. Que faire : identifiez les charges de travail qui ont besoin d’élasticité et celles qui exigent cohérence ou gouvernance. Placez-les en conséquence et concevez votre environnement pour que données et applications puissent passer d’un cloud, d’une infrastructure privée ou d’un site à l’autre avec un minimum de reconfiguration. Le cloud computing reste un modèle puissant pour la croissance et l’innovation. L’objectif est de bâtir suffisamment d’indépendance pour continuer à fonctionner lorsqu’une partie du système tombe en panne. Une conception résiliente apporte cette indépendance. Lorsque l’infrastructure dispose de plusieurs chemins, les interruptions deviennent gérables au lieu d’être paralysantes. La véritable résilience vient de la préparation et d’une architecture réfléchie, et non des garanties des fournisseurs. La résilience se construit, elle ne s’emprunte pas La récente panne d’AWS a montré à quel point Internet peut être fragile lorsque trop de choses dépendent d’une seule région ou d’une seule plateforme. Une seule défaillance technique a touché des entreprises dans le monde entier, révélant à quel point l’infrastructure moderne est devenue concentrée. Scality aide depuis plus de quinze ans les organisations à éviter ce type d’exposition. Nos logiciels de stockage de données prennent en charge des environnements hybrides, distribués et compatibles S3 qui gardent les données accessibles même lorsque des services externes tombent en panne. Comme toujours, AWS retrouvera toutes ses capacités. Mais pour de nombreuses entreprises touchées, le mal est déjà fait, et la leçon est claire. Une résilience durable naît de la liberté de choix. C’est avoir la possibilité d’utiliser les ressources cloud lorsqu’elles apportent de la valeur. De garder les charges de travail essentielles à proximité. De rendre les déplacements entre environnements simples et fiables. AWS reste une excellente plateforme, mais les organisations les plus résilientes ne s’appuient pas uniquement sur elle.
