Auto Scaling avec Launch Template

À la fin de ce tutoriel, vous aurez un Launch Template moderne et un Auto Scaling Group lié à un target group ALB, avec politiques de scaling simples — sans Launch Configuration (obsolète).

Niveau : Intermédiaire · Temps estimé : 60–75 min · Versions testées : EC2 Auto Scaling 2026, Launch Template, AWS CLI v2 · Dernière vérification : 2026-09-10 · Region : ca-central-1

← Précédent : ALB · → Suivant : EC2 types & Spot · Hub : Démarrer avec AWS

Prérequis

• Concepts EC2 + SG (EC2, ALB)
• VPC avec 2 subnets (idéalement 2 AZ) pour l’ASG
• Profil lab — coût : N instances × temps ; min=0 ou delete immédiat en fin de lab

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1

Ce que nous allons construire

Launch Template lab-lt-web (AMI + SG + user-data)
        │
        ▼
Auto Scaling Group (min 1, desired 2, max 4)
        │  subnets multi-AZ
        ▼
Target Group ALB  ←── health check ELB

(Schéma — alt : « Launch Template + ASG derrière ALB ».)

Étape 1 — Pourquoi Launch Template (pas Launch Configuration)

	Launch Configuration	Launch Template
Statut	Legacy	Standard 2026
Versions	Non	Versionning (Default / Latest / numéro)
Mix instances / Spot	Limité	Oui (MP + Spot)
T5/nouveautés	Bloqué progressivement	Supporté

Pour l’examen : toute nouvelle conception = Launch Template.

Étape 2 — Launch Template

AMI_ID=$(aws ssm get-parameters 
  --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 
  --query 'Parameters[0].Value' --output text)

# Réutilisez SG app (source = ALB) du tuto ALB, ou créez lab-app-sg
SG_APP=$(aws ec2 describe-security-groups 
  --filters Name=group-name,Values=lab-app-sg 
  --query 'SecurityGroups[0].GroupId' --output text)

USERDATA=$(echo '#!/bin/bash
dnf install -y nginx
systemctl enable --now nginx
echo "ASG-$(hostname)" > /usr/share/nginx/html/index.html
' | base64 -w0)

aws ec2 create-launch-template 
  --launch-template-name lab-lt-web 
  --version-description v1 
  --launch-template-data "{
    "ImageId": "$AMI_ID",
    "InstanceType": "t3.micro",
    "SecurityGroupIds": ["$SG_APP"],
    "IamInstanceProfile": {"Name": "lab-ec2-profile"},
    "UserData": "$USERDATA",
    "TagSpecifications": [{
      "ResourceType": "instance",
      "Tags": [{"Key": "Name", "Value": "lab-asg-web"}]
    }]
  }"

Sous PowerShell, encodez UserData en Base64 via [Convert]::ToBase64String.

Étape 3 — Auto Scaling Group

VPC_ID=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true 
  --query 'Vpcs[0].VpcId' --output text)
SUBNETS=$(aws ec2 describe-subnets --filters Name=vpc-id,Values="$VPC_ID" 
  Name=map-public-ip-on-launch,Values=true 
  --query 'Subnets[].SubnetId' --output text)
SUBNET_A=$(echo $SUBNETS | awk '{print $1}')
SUBNET_B=$(echo $SUBNETS | awk '{print $2}')

TG_ARN=$(aws elbv2 describe-target-groups --names lab-tg-web 
  --query 'TargetGroups[0].TargetGroupArn' --output text)
# Si absent : créez TG + ALB comme dans le tuto ALB avant de continuer

aws autoscaling create-auto-scaling-group 
  --auto-scaling-group-name lab-asg-web 
  --launch-template LaunchTemplateName=lab-lt-web,Version='$Latest' 
  --min-size 1 --max-size 4 --desired-capacity 2 
  --vpc-zone-identifier "${SUBNET_A},${SUBNET_B}" 
  --target-group-arns "$TG_ARN" 
  --health-check-type ELB 
  --health-check-grace-period 120 
  --tags "Key=Name,Value=lab-asg-web,PropagateAtLaunch=true"

HealthCheckType=ELB : une cible unhealthy dans le TG peut être remplacée par l’ASG (après grace period).

Étape 4 — Politiques de scaling

Target tracking (CPU) — simple et recommandé

aws autoscaling put-scaling-policy 
  --auto-scaling-group-name lab-asg-web 
  --policy-name lab-cpu-50 
  --policy-type TargetTrackingScaling 
  --target-tracking-configuration '{
    "TargetValue": 50.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    }
  }'

Step scaling / Simple scaling

Toujours possibles, plus verbeux ; target tracking couvre la majorité des labs et de la prod web.

Scheduled actions

Utile pour scale-up matinal / scale-down nuit — hors lab minimal.

Étape 5 — Vérifier le remplacement d’instance

aws autoscaling describe-auto-scaling-groups 
  --auto-scaling-group-names lab-asg-web 
  --query 'AutoScalingGroups[0].{Desired:DesiredCapacity,Instances:Instances}'

aws elbv2 describe-target-health --target-group-arn "$TG_ARN"

Forcez un scale :

aws autoscaling set-desired-capacity 
  --auto-scaling-group-name lab-asg-web --desired-capacity 3

Observez 3 instances, puis remettez à 1 ou 0 pour économiser.

Étape 6 — Warm pools, instance refresh (aperçu SA)

Feature	Rôle
Instance refresh	Déployer une nouvelle version de LT progressivement
Warm pool	Instances pré-initialisées (scale plus rapide, coût+)
Mixed instances / Spot	Économies (tuto Spot suivant)
Lifecycle hooks	Drain / register avant InService

Capacity rebalance & Spot (teaser)

Si vous mélangez Spot dans le Launch Template / mixed policy, activez Capacity Rebalance pour recevoir l’avis de rebalancing avant interruption Spot. Détails dans le tuto Spot — ici gardez t3.micro On-Demand pour un lab stable.

Étape 7 — Vérification

Checklist : LT créé · ASG multi-AZ · desired atteint · cibles ALB healthy · policy target tracking présente · pas de Launch Configuration.

aws ec2 describe-launch-templates --launch-template-names lab-lt-web
aws autoscaling describe-policies --auto-scaling-group-name lab-asg-web

Nettoyage

aws autoscaling update-auto-scaling-group 
  --auto-scaling-group-name lab-asg-web 
  --min-size 0 --desired-capacity 0
# attendre terminaison instances
aws autoscaling delete-auto-scaling-group 
  --auto-scaling-group-name lab-asg-web --force-delete
aws ec2 delete-launch-template --launch-template-name lab-lt-web
# ALB/TG : supprimer si plus utilisés (tuto ALB)

Termination policies

Par défaut l’ASG choisit quelles instances tuer au scale-in (AZ équilibre, puis OldestLaunchTemplate, etc.). Vous pouvez forcer OldestInstance ou protéger certaines instances (ProtectedFromScaleIn). Utile en dépannage pour ne pas tuer le nœud que vous déboguez.

Erreurs fréquentes

Symptôme	Cause	Correction
Instances tournent mais unhealthy	User-data / SG / grace trop court	Augmenter grace ; vérifier nginx
ASG ne scale pas	Alarmes / rights CloudWatch	Target tracking crée les alarmes ; vérifier IAM service-linked role
ValidationError LT	UserData base64 / JSON	Revoir escaping
Coût	desired>0 oublié	desired=0 puis delete ASG
Instance refresh stuck	MinHealthy trop haut / unhealthy	Baisser MinHealthy ; fixer user-data/SG
Scale-in tue mon debug	Termination policy / pas de protection	ProtectedFromScaleIn sur l’instance

Service-linked role Auto Scaling

Au premier ASG, AWS crée souvent AWSServiceRoleForAutoScaling. Sans ce rôle (comptes verrouillés SCP), create-auto-scaling-group échoue. En lab perso standard, il apparaît automatiquement.

Cooldown vs grace period

• Health check grace period : ignore unhealthy au démarrage (user-data).
• Default cooldown (simple scaling) : attend avant un autre scale-out/in.
• Target tracking gère ses propres délais — ne multipliez pas les politiques contradictoires sur le même ASG.

Versions de Launch Template

Chaque create-launch-template-version numérote une révision. L’ASG peut cibler $Latest, $Default ou un numéro fixe (recommandé en prod pour contrôler les déploiements). Flux typique lab → prod :

1. Créer LT v1 (AMI + user-data).
2. Pointer l’ASG sur Version=1 (ou $Default après modify-launch-template --default-version).
3. Publier v2 (nouvelle AMI) → instance refresh plutôt que de tout terminer à la main.

aws ec2 describe-launch-template-versions 
  --launch-template-name lab-lt-web 
  --query 'LaunchTemplateVersions[].{V:VersionNumber,Desc:VersionDescription}'

Lab bonus (5–8 min) — instance refresh

Avec desired ≥ 2 et une v2 de LT (même user-data OK pour la démo) :

aws autoscaling start-instance-refresh 
  --auto-scaling-group-name lab-asg-web 
  --preferences MinHealthyPercentage=50,InstanceWarmup=60
aws autoscaling describe-instance-refreshes 
  --auto-scaling-group-name lab-asg-web 
  --query 'InstanceRefreshes[0].{Status:Status,Pct:PercentageComplete}'

Vous observez le remplacement progressif des instances. Annulez si besoin avec cancel-instance-refresh. En lab, remettez ensuite desired-capacity bas pour limiter le coût.

Scénario examen classique

« Vous devez remplacer progressivement les instances d’un ASG par une nouvelle AMI sans downtime, derrière un ALB. » → Launch Template versionnée + instance refresh (ou rolling via politique) + health check ELB pour ne garder que les cibles healthy. Launch Configuration = réponse piège (legacy). Si la question parle d’économies batch interruptibles → mixed instances / Spot (tuto suivant), pas seulement On-Demand.

AZ rebalancing et max instance lifetime

L’ASG rééquilibre entre AZ quand c’est possible (lancer dans l’AZ sous-représentée, terminer dans celle en trop). Max instance lifetime force un recyclage périodique (patching / hygiène) — utile en prod, rare en lab court. Ne confondez pas avec le health check grace period : l’un recycle par âge, l’autre ignore unhealthy au boot.

Checklist lab anti-facture

1. Dès la création ASG : noter min / desired / max.
2. Fin de session : min=0 et desired=0 avant de fermer le laptop.
3. Puis delete-auto-scaling-group --force-delete + delete-launch-template.
4. Vérifier qu’aucune EC2 lab-asg-web ne reste (describe-instances).
5. ALB/TG du tuto précédent : supprimer s’ils ne servent plus.

Scaling policies : éviter les conflits

Ne cumulez pas target tracking CPU et step scaling agressif sur les mêmes conditions : les politiques se marchent dessus. Une métrique custom (files SQS, ALBRequestCountPerTarget) via target tracking est souvent plus parlante qu’un CPU seul pour une API I/O-bound. En ca-central-1, les alarmes créées par target tracking apparaissent dans CloudWatch → Autoscaling.

Lien avec le Free Tier

/ budget

Même en Free Tier, plusieurs t3.micro + ALB coûtent si vous oubliez le teardown. Habitude : fin de lab = desired=0 avant de fermer le laptop.

Attacher / détacher et standby

En dépannage, vous pouvez détacher une instance de l’ASG (elle survit hors groupe) ou la passer en Standby (hors service load balancing, toujours « connue » de l’ASG). Utile pour patcher à la main sans que le scale-in la tue. Réattachez-la ensuite ou terminez-la proprement. En lab ca-central-1, préférez set-desired-capacity et les health checks plutôt que de multiplier detach/attach — mais connaissez les verbes pour l’examen.

# Exemple : lister les instances gérées
aws autoscaling describe-auto-scaling-instances 
  --query 'AutoScalingInstances[?AutoScalingGroupName==`lab-asg-web`].[InstanceId,LifecycleState]' 
  --output table

Quiz (5 questions)

1. Pour une nouvelle architecture 2026, on choisit : – A. Launch Configuration
– B. Launch Template
– C. Seulement Spot Fleet sans template

2. HealthCheckType=ELB signifie surtout : – A. Ignorer l’ALB
– B. L’ASG peut remplacer une instance unhealthy au sens du target group
– C. Forcer CPU 100 %

3. Target tracking CPU 50 % : – A. Fixe toujours exact 2 instances
– B. Ajuste la capacité pour viser ~50 % CPU moyen
– C. Remplace IAM

4. Pour déployer une nouvelle AMI sans couper tout le trafic d’un coup : – A. Terminer le ASG entier
– B. Instance refresh (ou rolling) sur LT versionnée
– C. Changer seulement le Security Group

5. Health check grace period sert à : – A. Facturer moins cher
– B. Ignorer unhealthy pendant le boot / user-data
– C. Remplacer ACM

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

Pour aller plus loin

• Launch templates
• Auto Scaling groups
• Target tracking
• Instance refresh
• Mixed instances policy

Maillage série AWS (P1)

← Précédent	ALB
→ Suivant	EC2 types & Spot
Aussi	EC2 · IAM instance profile