Amazon SOA-C02: Calcul et Auto Scaling — Guide d'étude

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Fait partie du AWS SysOps Administrator Associate SOA-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Ce domaine couvre la gestion des instances EC2 et de l’Auto Scaling pour fournir une capacité de calcul fiable et rentable. Il se concentre sur les opérations du cycle de vie des instances, les stratégies de mise à l’échelle, l’intégration avec les load-balancers, le placement pour la performance et la résilience, ainsi que les comportements de maintenance et de terminaison qui affectent la disponibilité et l’état. La maîtrise opérationnelle implique de choisir les bons types d’instances, les bons modèles de configuration de lancement, les bonnes stratégies de mise à l’échelle et la bonne intégration des vérifications de l’état (health checks) pour respecter les SLA tout en contrôlant les coûts.

Cycle de vie et gestion des instances EC2

La gestion du cycle de vie EC2 commence au niveau de la configuration de lancement : utilisez les Launch Templates (aws ec2 create-launch-template / console) pour définir l’AMI, le type d’instance, le profil d’instance IAM, les user-data, les interfaces réseau, le mappage EBS et les options de métadonnées ; les modèles prennent en charge le versioning, ce qui simplifie les déploiements immuables. Les déploiements immuables utilisent une nouvelle version de launch template (ou un nouveau launch template) et créent soit un nouveau groupe Auto Scaling, soit utilisent le rafraîchissement d’instances ASG pour remplacer les instances ; évitez les mises à niveau sur place des instances en cours d’exécution lorsque les changements affectent le comportement au démarrage ou les correctifs au niveau de l’AMI.

Les modèles opérationnels en CLI/console incluent

undefined

pour les lancements ponctuels et

undefined

pour les lancements pilotés par un ASG. Choisissez entre la création d’AMI (« baking » avec Packer/CodeBuild) et les scripts de démarrage user-data en fonction du temps de démarrage : intégrez (« bake ») les dépendances lourdes dans les AMI pour réduire la durée de démarrage ; utilisez les user-data pour la configuration spécifique à l’environnement. Pour le stockage éphémère, n’oubliez pas que les volumes de stockage d’instance sont perdus lors de la terminaison ; configurez les volumes racine et de données avec DeleteOnTermination=false si vous avez besoin de la persistance d’EBS après la terminaison de l’instance.

Groupes Auto Scaling, stratégies et hooks de cycle de vie

Les Auto Scaling Groups (ASG) sont configurés avec un launch template ou une launch configuration et contrôlent la capacité souhaitée/minimale/maximale à travers les zones de disponibilité. Choisissez un launch template + MixedInstancesPolicy pour des flottes optimisées en coût qui combinent des instances On-Demand et Spot avec une liste de types d’instances ; utilisez la pondération d’instances et les stratégies d’allocation optimisées pour la capacité (capacity-optimized) pour une capacité prévisible. Pour les déploiements, préférez les modèles immuables : créez une nouvelle version de launch template et effectuez un rafraîchissement d’instances ASG ou un échange blue/green plutôt que de reconfigurer les instances existantes.

Les stratégies de mise à l’échelle (scaling policies) se déclinent comme suit :

Suivi de cible (PolicyType=TargetTrackingScaling) : définissez une métrique prédéfinie comme ALB RequestCountPerTarget ou la moyenne CPU de l’ASG et une valeur cible ; l’ASG gère les ajustements automatiquement.
Mise à l’échelle par paliers (PolicyType=StepScaling) : définissez des alarmes CloudWatch qui déclenchent des étapes d’ajustement spécifiques (par ex., +2, +4) en fonction de la gravité du dépassement ; utile pour les charges de travail en rafale.
Mise à l’échelle simple (legacy) : ajustements en une seule étape avec un temps de recharge (cooldown) ; généralement remplacée par le suivi de cible ou la mise à l’échelle par paliers.

Utilisez les hooks de cycle de vie (

undefined

) pour mettre en pause la terminaison/le lancement d’une instance. Les hooks de cycle de vie vous permettent de drainer les connexions, de répliquer l’état (vers S3/RDS) ou de notifier les systèmes d’orchestration via SNS/SQS/Lambda avant la finalisation ; définissez toujours un HeartbeatTimeout et une action par défaut pour éviter les états bloqués.

Types d’Elastic Load Balancing et vérifications de l’état

Choisissez le type de load balancer en fonction du modèle de trafic : Application Load Balancer (ALB) pour HTTP/HTTPS avec routage basé sur le contenu et des règles de host/path ; Network Load Balancer (NLB) pour des performances extrêmes et des adresses IP statiques pour TCP/UDP ; Classic Load Balancer (CLB) uniquement pour les stacks existants (legacy). Créez des ALB et des groupes de cibles avec

undefined

; enregistrez les cibles de l’ASG en utilisant l’association du groupe de cibles de l’ASG pour une intégration automatique de la surveillance de l’état (health) du cycle de vie.

L’intégration des vérifications de l’état (health checks) nécessite d’aligner celles de l’ASG et de l’ELB : définissez le HealthCheckType de l’ASG sur ELB (

undefined

) afin qu’une instance ne soit considérée comme saine qu’après que le load balancer a marqué sa cible comme saine. Types de vérifications de l’état et implications :

Vérification de l’état du groupe de cibles ALB/NLB : prend en charge HTTP/HTTPS/TCP et mesure la disponibilité au niveau de l’application ; recommandé pour les applications web.
Vérifications de l’état de l’ASG seules : à utiliser pour des vérifications simples au niveau de l’hôte (par ex., les vérifications de statut EC2).
HealthCheckGracePeriod : donnez aux nouvelles instances le temps de démarrer, d’exécuter les user-data et de passer les vérifications au niveau de l’application.

Implications de la persistance de session (stickiness) : la persistance de session du groupe de cibles de l’ALB utilise une affinité basée sur un cookie applicatif (basée sur la durée), ce qui peut améliorer l’affinité de session mais réduit la répartition uniforme et complique les mises à jour progressives (rolling updates). Le NLB prend en charge l’affinité par adresse IP client ; n’utilisez la persistance de session que lorsque l’état de la session ne peut pas être externalisé.

Placement des instances, planification de la capacité et métriques de mise à l’échelle

Les décisions de placement affectent la latence et les domaines de défaillance : les groupes de placement offrent des stratégies de type cluster (réseau à faible latence), spread (une instance par rack pour les instances critiques) et partition (partitions isolées des pannes). Les ASG répartissent les instances entre les AZ par défaut ; préférez une planification de la capacité tenant compte des AZ pour éviter les points chauds dans une seule AZ. Pour la CLI : aws ec2 create-placement-group –strategy cluster|spread|partition.

La planification de la capacité prend en compte les types d’instances, les options d’achat et les métriques :

Types d’instances : choisissez des familles optimisées pour le CPU, la mémoire ou le réseau (M/C/R/T/D/I) en fonction de la charge de travail ; mesurez avec des tests de charge représentatifs.
Achat : On-Demand pour la prévisibilité, instances réservées ou Savings Plans pour des réductions de coûts en régime permanent, Spot pour l’efficacité des coûts pour les charges transitoires ; utilisez une MixedInstancesPolicy pour combiner les types et les options d’achat.
Métriques de mise à l’échelle : les métriques par défaut des ASG utilisent la moyenne du CPU sur l’ensemble du groupe ; préférez des métriques au niveau de l’application telles que ALB RequestCountPerTarget ou des métriques CloudWatch personnalisées (par ex., la profondeur de la file d’attente) pour le suivi de cible. Patrons courants :
Utilisez le suivi de cible avec ALB/request-count-per-target lorsque vous avez besoin d’un nombre stable de requêtes par instance.
Utilisez la mise à l’échelle par paliers pour les pics soudains et importants avec des étapes de récupération définies.
Envisagez la mise à l’échelle prédictive (Predictive Scaling) pour les charges de travail cycliques quotidiennes.

Restauration d’instance, comportement à la terminaison et maintenance

Planifiez les pannes d’instances et la maintenance en activant la restauration automatique pour les problèmes matériels (alarme CloudWatch avec l’action EC2 Recover) et en gérant les événements planifiés (describe-instance-status). Configurez les indicateurs instance-initiated-shutdown-behavior et EBS DeleteOnTermination pour contrôler le cycle de vie des volumes ; utilisez aws ec2 modify-instance-attribute –instance-id i-xxx –block-device-mappings pour ajuster.

Comportement à la terminaison dans les ASG : les politiques de terminaison des ASG décident quelle instance terminer en premier (Par défaut : la plus ancienne configuration de lancement ou des heuristiques basées sur l’état de santé de l’instance et l’équilibrage des AZ). Détails opérationnels importants :

L’état local est éphémère : les volumes de stockage d’instance (instance-store) et les caches en mémoire sont perdus à la terminaison. Ne présumez pas que le remplacement préserve l’état local ; persistez les données critiques sur EBS (avec des snapshots/sauvegardes appropriés), S3 ou un cache externe (ElastiCache).
Utilisez des hooks de cycle de vie (lifecycle hooks) pour drainer le trafic et décharger l’état avant la terminaison.
Utilisez l’actualisation d’instance (instance refresh) ou le blue/green pour la maintenance afin de remplacer les instances en toute sécurité ; aws autoscaling start-instance-refresh –auto-scaling-group-name my-asg –preferences file://prefs.json.

Pièges courants et critères de décision

Se fier aux délais de récupération (cooldowns) par défaut et aux métriques basées uniquement sur le CPU : choisissez des métriques alignées sur le comportement de l’application (ALB RequestCountPerTarget, profondeur de la file d’attente) ; définissez les cooldowns pour tenir compte du temps de démarrage et le HealthCheckGracePeriod pour éviter l’oscillation.
Ne pas utiliser de hooks de cycle de vie pour une terminaison en douceur (graceful termination) : sans hooks, les requêtes en cours et les caches locaux sont perdus ; implémentez des hooks avec SNS/SQS/Lambda pour drainer et persister l’état.
Présumer que le remplacement d’une instance préserve l’état local : les stockages d’instance locaux et les caches en mémoire sont éphémères ; concevez des instances sans état (stateless) ou répliquez l’état vers des stockages durables.
Abuser de la persistance de session (stickiness) : la persistance de session augmente la répartition inégale de la charge et complique la mise à l’échelle et les mises à jour ; préférez des magasins de session externes (ElastiCache, DynamoDB) pour le scale-out.
Ignorer l’équilibrage entre les AZ et les groupes de placement : placer trop d’instances dans une seule AZ ou un groupe de type cluster peut créer des points de défaillance uniques (single points of failure) ; utilisez la distribution multi-AZ des ASG et des stratégies de groupes de placement appropriées.
Mal configurer l’intégration des vérifications de l’état de santé : le health-check-type de l’ASG doit correspondre aux vérifications de l’état de santé de l’ELB/groupe cible et le HealthCheckGracePeriod doit être suffisamment long pour l’initialisation de l’application, sinon des instances saines seront terminées.

Problème pratique : Scénario d’utilisation

StreamingCo exploite une API de vignettes vidéo qui subit des pics de trafic quotidiens et utilise des caches sur disque local sur des instances EC2 ; récemment, la mise à l’échelle (scale-up) a été lente et les instances terminées perdent leur cache, ce qui entraîne de mauvais temps de réponse.

Migrer la configuration de lancement vers un modèle de lancement (Launch Template) et créer une AMI légère avec les dépendances d’exécution ; utiliser aws ec2 create-launch-template et le versioning pour des déploiements immuables.
Configurer un ASG avec une MixedInstancesPolicy qui liste plusieurs types d’instances et une allocation Spot + On-Demand pour équilibrer le coût et la capacité.
Attacher un ALB et utiliser une politique de mise à l’échelle par suivi de cible (TargetTrackingScaling) sur la métrique ALB RequestCountPerTarget avec un HealthCheckGracePeriod défini sur le temps de démarrage de l’application.
Implémenter des hooks de cycle de vie sur les terminaisons d’ASG pour drainer les connexions et exécuter un flux Lambda/SNS pour persister les clés de cache nécessaires vers ElastiCache ou S3 avant la terminaison.
Externaliser l’état de session et de cache vers ElastiCache ou S3 et utiliser des groupes de placement/distribution entre AZ pour répondre aux exigences de latence et de domaine de défaillance.

Justification : L’utilisation de modèles de lancement et de déploiements immuables réduit la variabilité au démarrage ; le suivi de cible basé sur l’ALB lie la mise à l’échelle à la charge de requêtes plutôt qu’au CPU ; les hooks de cycle de vie empêchent la perte de données à la terminaison ; l’externalisation du cache supprime la dépendance à l’état local éphémère, permettant une mise à l’échelle rapide et sûre et un coût réduit grâce à des stratégies mixtes d’instances/d’achat.

← Stockage et gestion des données · Tous les domaines · Bases de données et mise en cache →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →