Les ruptures de services cloud sont relativement fréquentes. Pour apporter un grain de résilience supplémentaire aux entreprises rencontrant des incidents et pannes en tous genres, AWS propose Fault Injection Service pour aider les entreprises à les anticiper. « Vous pouvez utiliser les scénarios pour mener des expériences afin de vous assurer que votre application (qu'elle soit mono ou multi-régionale) fonctionne comme prévu en cas de problème, de mieux comprendre les dépendances directes et indirectes et de tester le temps de récupération », explique AWS.
Fault Injection Service est loin d'être une nouveauté puisque cette offre est proposée à tous les clients (EC2, S3...) du fournisseur cloud américain depuis 2021. Mais AWS vient de l'enrichir avec des scénarios inédits et particulièrement dans l'ère du temps : interruption d'alimentation, perte de connectivité, interruption de trafic, indisponibilité de service... « Chaque scénario est utilisé pour créer un modèle d'expérience. Vous pouvez utiliser les scénarios tels quels ou prendre n'importe quel modèle comme point de départ et le personnaliser ou l'améliorer à votre guise », explique le fournisseur.
Des scénarios d'incidents et de pannes courantes
Par exemple le scénario d'interruption de courant consiste à « débrancher » temporairement un ensemble ciblé des ressources dans une seule zone de disponibilité, notamment les instances EC2 (y compris celles des clusters EKS et ECS), les volumes EBS, Auto Scaling Groups, les sous-réseaux VPC, les clusters ElastiCache for Redis et Relational Database Service (RDS).
Autre exemple poussé par le groupe : un souci de connectivité avec un scénario qui empêche l'application dans une région de test de pouvoir accéder aux ressources dans une région cible. Cela inclut le trafic provenant des instances EC2, des tâches ECS, des pods EKS et des fonctions Lambda attachées à un VPC. Et inclut également le trafic circulant à travers les passerelles de transit et les connexions de peering VPC, ainsi que la réplication S3 et DynamoDB interrégionale. « Ce scénario se déroule pendant 3 heures (sauf si vous modifiez le paramètre disruptionDuration) et isole la région de test de la région cible de la manière spécifiée, avec des paramètres avancés pour contrôler et sélectionner les ressources AWS affectées dans la région isolée », indique la société.
Commentaire