L’ingénierie du Chaos et AWS Fault Injection Simulator

L’ingénierie du Chaos est aujourd’hui une discipline essentielle pour assurer la fiabilité et la résilience des systèmes modernes.

Elle consiste à provoquer volontairement, de manière contrôlée, reproductible et sécurisée, des défaillances au sein d’un environnement de production ou de préproduction afin d’observer la manière dont le système réagit.

L’objectif de cette approche est d’identifier les failles de résilience (resilience gaps) qui ne sont pas détectées par les formes de tests traditionnelles (telles que les tests unitaires, d’intégration ou de charge) et d’améliorer la capacité du système à maintenir un service continu face à des perturbations aussi réelles que possibles.

Contrairement aux tests classiques, qui cherchent à vérifier que l’application se comporte comme prévu dans des conditions normales ou face à des erreurs anticipées, l’ingénierie du Chaos s’attache à évaluer la robustesse du système dans des situations imprévues:

pannes de réseau
latences anormales
perte de ressources
comportements dégradés de dépendances externes
…

Cette approche proactive permet de mieux comprendre les limites d’un système et de renforcer sa tolérance aux pannes avant qu’un incident réel ne se produise.

Intégration avec AWS Fault Injection Simulator (FIS)

Sur AWS, la mise en pratique de l’ingénierie du Chaos est facilitée par le service AWS Fault Injection Simulator (FIS).

Ce service managé permet d’exécuter des expériences de chaos de manière sûre, contrôlée et reproductible directement sur des environnements AWS.

FIS offre un cadre structuré pour simuler différents types de défaillances telles que:

l’arrêt ou la dégradation d’instances EC2
la perturbation du trafic réseau (perte d’un Zone de disponibilité (AZ) ou une Région)
la variation de latence sur les appels API
la réduction de la capacité d’un cluster ECS ou EKS.

L’un des principaux avantages d’AWS FIS réside dans son intégration native avec l’écosystème AWS.

Il permet de définir des scénarios d’expérimentation ciblés, d’en mesurer les impacts grâce à CloudWatch et AWS X-Ray, et d’automatiser leur exécution via des pipelines CI/CD ou des workflows orchestrés (Step Functions, EventBridge, etc.).

Cette approche permet d’introduire progressivement des tests de résilience dans le cycle de vie applicatif, tout en garantissant la sécurité des environnements grâce à des mécanismes de garde-fous intégrés (stop conditions, permissions IAM limitées, etc.).

En combinant la rigueur du Chaos Engineering avec les capacités natives d’observation et d’automatisation d’AWS, FIS constitue un outil stratégique pour renforcer la robustesse des architectures cloud et valider leur comportement face aux défaillances réelles.

Bonnes pratiques et garde-fous

L’expérimentation du Chaos n’a de sens que si elle est menée de manière contrôlée, mesurable et sans risque pour les utilisateurs finaux et pour l’infrastructure testée. Bien que l’objectif soit de provoquer des défaillances, la démarche doit avant tout renforcer la confiance dans la résilience du système, et non créer de nouvelles sources d’instabilité.

Voici quelques principes fondamentaux essentiels pour mettre en œuvre AWS Fault Injection Simulator (FIS) de manière sécurisée et efficace.

1. Définir des objectifs clairs et mesurables

Avant de lancer une expérience de Chaos, il est essentiel de définir ce que l’on souhaite apprendre ou valider.
Chaque test doit répondre à une hypothèse précise du type :

“Si une zone de disponibilité devient indisponible, notre service doit rester accessible avec une latence inférieure à 500 ms.”

Cette approche hypothético-déductive permet de donner un cadre scientifique à l’expérimentation et d’éviter les tests “pour le test”.

Les métriques de validation (latence, taux d’erreur, disponibilité, throughput, etc.) doivent être mesurables via des outils permettant de valider le test, tels que CloudWatch, Prometheus ou Datadog.

2. Commencer petit et progresser par itérations

Le Chaos Engineering repose sur une progression contrôlée, on travaille par itérations successives.
Il est recommandé de démarrer dans un environnement de préproduction et sur un scope limité :

une seule instance EC2,
un cluster ECS restreint,
un service spécifique d’une architecture microservices.

Au fil du temps, les expérimentations peuvent être étendues sur toute l’infra et vers la production, mais uniquement une fois les garde-fous validés.

Cette montée en puissance progressive limite les risques tout en renforçant la confiance de l’équipe dans les mécanismes de résilience. Et permet de corriger au fur et à mesure des avancées les défauts de comportement, s’il y en a.

3. Mettre en place des conditions d’arrêt (Stop Conditions)

AWS FIS permet de configurer des conditions d’arrêt automatiques basées sur des alarmes CloudWatch.

Ces garde-fous sont indispensables pour interrompre immédiatement l’expérience si des seuils critiques sont dépassés (par exemple : latence, erreurs HTTP 5xx, CPU, saturation de file SQS).

Ainsi, même en cas de dérive inattendue, l’expérience reste sous contrôle et ne compromet pas la disponibilité réelle du service.

4. Sécuriser les permissions IAM

Les expériences FIS doivent être exécutées avec le principe du moindre privilège.

Création d’un rôle IAM dédié, n’autorisant que :

la lecture et l’injection de pannes sur les ressources ciblées,
la création et la suppression contrôlée d’expériences,
l’accès en lecture aux métriques CloudWatch.

C’est une évidence mais comme toutes les évidences, il est préférable de les énoncer :

Ne pas utiliser de rôles génériques ou administrateurs. Cela réduit les risques de déclenchement accidentel ou de mauvaises configurations.

5. Communiquer et documenter

Le Chaos Engineering doit être une pratique d’équipe, non une initiative isolée.

Avant chaque expérience :

On planifie les exercices et on informe les équipes concernées (exploitation, support, développement),
On documente le plan d’expérimentation (objectifs, périmètre, conditions de succès, garde-fous),
On prépare un plan de retour à la normale clair.

Après l’expérience, organiser un retour d’expérience (post-mortem) pour analyser les résultats, identifier les faiblesses et décider des actions correctives. Cette boucle d’apprentissage continue est la clé de la résilience organisationnelle.

6. Automatiser et intégrer dans la CI/CD

Pour maximiser la valeur du Chaos Engineering, intégrer progressivement FIS dans vos pipelines CI/CD ou vos tests de résilience automatisés.

Par exemple :

Définir des semaines de tests de résilience PRA pour commencer,
Dans l’idéal déclencher une expérience FIS à chaque déploiement majeur pour vérifier que les mécanismes de failover ou d’auto-scaling fonctionnent toujours comme prévu.

Cette intégration continue transforme le Chaos Engineering en un processus de validation proactive, et non en un exercice ponctuel.

7. Apprendre des incidents réels

Enfin, chaque incident de production constitue une opportunité d’expérimentation ciblée.

Une fois l’incident résolu, recréer les conditions similaires via FIS pour valider que les correctifs mis en place empêchent sa réapparition.

C’est ainsi que le Chaos Engineering devient un véritable outil d’amélioration continue, ancré dans la réalité opérationnelle.

A retenir

L’utilisation d’AWS FIS et du Chaos Engineering ne se fait pas sans base et sans une vision d’ensemble de ce qu’on cherche à valider.

Il est nécessaire de gérer :

Les attendus : qu’est-ce qu’on cherche à tester
La sécurité : on ne fait pas n’importe quoi, on maîtrise ce qui doit l’être
On commence petit et on itère pour couvrir le maximum du scop fonctionnel et applicatif
On apprend de nos erreurs et de nos pannes.

La mise en œuvre d’AWS FIS ne consiste pas simplement à “casser pour voir”, mais à tester pour comprendre et renforcer. Avec des objectifs précis, des garde-fous solides et une culture de collaboration, cette démarche transforme le Chaos en levier de fiabilité durable des infrastructures.

Tarification

AWS Fault Injection Simulator est facturé en fonction du nombre d’actions d’injection de panne exécutées (Fault Injection Actions) au cours de vos expériences.

Le modèle de tarification est simple et ne dépend pas de la durée de l’expérience ni du type de ressource ciblée (EC2, RDS, ECS, etc.).

Type de Coût	Détail	Prix (par action)
Coût de base	Chaque action d’injection de panne réussie ou échouée (démarrée)	0,10 $ USD (par action)
Coûts additionnels	Ressources AWS consommées pendant l’expérience (EC2, CloudWatch, etc.)	Standard (selon les services utilisés)

Calcul des actions d’injection de panne

Une action d’injection de panne correspond à une action spécifiée dans le template d’expérience FIS qui affecte directement une ressource.

Exemple 1 : Arrêt d’instance EC2
- Si votre template contient une action aws:ec2:terminate-instances ciblant un groupe de 5 instances (avec COUNT(1) dans la sélection des cibles), l’expérience exécute 1 action d’injection de panne, même si elle affecte une ressource spécifique.
- Coût pour FIS : 0,10 $ USD
Exemple 2 : Multi-actions
- Si votre template exécute deux actions distinctes simultanément :
  1. aws:ec2:reboot-instances (redémarrage d’un EC2)
  2. aws:rds:reboot-db-instances (redémarrage d’une instance RDS)
- L’expérience compte 2 actions d’injection de panne.
- Coût pour FIS : 2 x 0,10 $ = 0,20 $ USD
Exemple 3 : Actions séquentielles ou répétées
- Si vous définissez une expérience avec trois étapes séquentielles, chacune contenant une seule action d’injection de panne (par exemple : latence → perte_AZ → arrêt_EC2), cela compte 3 actions.
- Coût pour FIS : 3 x 0,10 $ = 0,30 $ USD

Récapitulatif tarification

La tarification d’AWS FIS est prévisible : vous payez uniquement pour chaque type d’injection de panne que vous configurez et exécutez dans vos expériences.

Scénario d’Expérience	Nombre d’Actions	Coût FIS
Arrêt d’une instance EC2	1	0,10 $
Arrêt de 50% d’un cluster ECS	1	0,10 $
Injection de latence sur un groupe d’instances + Arrêt d’une instance RDS (2 actions)	2	0,20 $
10 exécutions de l’expérience simple d’arrêt d’EC2 (pour tests)	10	1,00 $

Note importante : Cette tarification ne couvre que l’utilisation du service FIS lui-même. Vous restez responsable des coûts liés aux ressources AWS (EC2, CloudWatch, etc.) consommées ou redémarrées pendant et après l’expérience.

AWS Fault Injection Simulator : Explication par l’exemple

Prenons le cas simple d’une infrastructure trois tiers bien connue :

Objectif

Simuler la perte d’une instance web (EC2) dans un Auto Scaling Group afin de valider :

le comportement de l’ALB (basculer vers instances saines),
la capacité de l’ASG à restaurer la capacité désirée,
l’absence d’impact critique sur la base RDS,
la cohérence avec les exigences du PRA (RTO / RPO attendus).

Architecture ciblée

ALB (public) → Target Group → ASG → EC2 (tag Service=web, Environment=staging)
RDS (standalone / multi-AZ selon votre infra)

Pré-requis

Une stack déployée (ALB, Target Group, ASG, instances avec tags).

Ce repo git contient le nécessaire pour déployer l’infra de base.

Il contient un exemple simple d’infrastructure Terraform qui provisionne :

Un VPC avec deux sous‑réseaux publics (eu-west-1a / eu-west-1b)
Un Application Load Balancer (ALB) + Target Group
Un groupe Auto Scaling avec un Launch Template (instances web)
Une instance RDS (MySQL ou Postgres selon main tf)
Des alarmes CloudWatch utilisées comme conditions d’arrêt pour une expérience FIS
Un template AWS FIS pour terminer une instance du groupe Auto Scaling

Fichiers principaux :

main.tf : ressources réseau, ALB, ASG, RDS, launch template
data.tf : data source AMI
cloudwatch.tf : CloudWatch alarms (stop conditions)
fis.tf : rôle IAM FIS et aws_fis_experiment_template
local.tf : variable locale prefix

Cette infra est minimaliste et publique pour les tests. Elle n’est pas optimisée pour la production (multi-AZ RDS, backups, subnets privés…).

Déploiement

terraform init
terraform plan
terraform apply

Après apply, vous aurez :

un ALB public avec target group → ASG EC2,
un ASG de 2 instances web,
un RDS MySQL/Postgres prêt à recevoir des connexions.

Cette infra est prête à être utilisée comme cible pour FIS (arrêt / termination d’instance, test de résilience).

CloudWatch collecte ces métriques et contient au moins 3 alarmes prêtes :

<CLOUDWATCH_ALARM_ARN_HTTP_5XX> (ALB 5xx),
<CLOUDWATCH_ALARM_ARN_HIGH_LATENCY> (ALB latency),
<CLOUDWATCH_ALARM_ARN_DB_CONNECTIONS_CRITICAL> (RDS connections).

Rôle IAM dédié pour FIS créé avec le principe du moindre privilège.

Autoriser les SRE/DevOps concernés et informer le support/ops avant toute exécution.
Mise en place de la solution

AWS fournit des templates

Stop conditions (garde-fous)

Avant l’exécution, vérifier que les alarmes suivantes existent et sont référencées dans le template :

ALB_HTTP_5XX_Alarm : stop si Sum(HTTPCode_Target_5XX_Count) > 10 sur 1 minute.
ALB_Latency_Alarm : stop si Avg(TargetResponseTime) > 1.5 s sur 2 minutes.
RDS_Connections_Critical : stop si DatabaseConnections > seuil critique.

Exécution (runbook simplifié)

Avant : annoncer la fenêtre d’expérimentation à toutes les équipes (Slack/email), ouvrir un canal d’urgence.
Lancer : aws fis start-experiment –experiment-template-id <ID> ou via Console FIS. :

Surveiller (t = 0 → t + 15 min) : CloudWatch dashboard contenant ALB, ASG, EC2, RDS. Vérifier HealthyHostCount, HTTPCode_Target_5XX_Count, TargetResponseTime, GroupInServiceInstances, DatabaseConnections. → capture d’écran : CloudWatch dashboard pendant l’expérience.
Stop automatique : si une stop condition déclenche, FIS arrête l’expérience. Vérifier logs & events FIS.
Après : post-mortem immédiat — collecter métriques, logs applicatifs, traces X-Ray, et noter décisions/action items.

Critères de succès (exemples)

HTTPCode_Target_5XX_Count reste < 10 pendant et 5 minutes après l’expérience.
TargetResponseTime médian < 500 ms (tolérances business).
ASG restaure InServiceInstances = DesiredCapacity en < 10 min.
RDS : aucune déconnexion critique des connexions applicatives (ou reconnection acceptée).

Remarques & extensions pédagogiques

Alternative : tester stop (redémarrage possible) au lieu de terminate si vous voulez simuler un arrêt transitoire.
Injection de latence : si vous souhaitez simuler une dégradation réseau, utilisez SSM + tc/netem via un aws:ssm:send-command (assurez-vous que SSM Agent + permissions existent).
Montée progressive en charge : exécutez d’abord en staging puis, après validation, planifiez une expérience en production sur une fenêtre faible trafic (avec plus de garde‑fous).

Bibliographie

Documentation AWS FIS : Documentation AWS FIS
AWS FIS tutorial : Tutoriels AWS FIS
Guide de l’utilisateur AWS Fault Injection Simulator : Guide de l’utilisateur AWS FIS
Liste des Services AWS exploitables par FIS : Cible pour AWS FIS
Référence de l’API AWS Fault Injection Simulator : Référence de l’API AWS FIS
Référence des commandes AWS CLI pour FIS : Référence CLI AWS FIS

AWS Fault Injection Simulator: Valider la résilience de vos infrastructures cloud

Auteur

Partager