Versionnement des modèles de lancement EC2 : gérer la config d'instance sans casser le parc

Un modèle de lancement EC2 est la définition versionnée de la façon dont vos instances démarrent — AMI, type d’instance, groupes de sécurité, user data, profil IAM, balises. Chaque modification crée une nouvelle version immuable, et les consommateurs (groupes Auto Scaling, flottes spot, appels run-instances) référencent soit un numéro épinglé, soit $Default, soit $Latest. La plupart des surprises de parc remontent à une seule décision : quelque chose en production qui référence $Latest, de sorte qu’une modification à moitié finie est partie en production dès que quelqu’un l’a sauvegardée.

Ce qui se passe

Les modèles de lancement ont remplacé les configurations de lancement comme façon de définir la config d’instance, et la différence qui compte en exploitation, c’est le versionnement : une configuration de lancement était immuable et jetable, tandis qu’un modèle de lancement est un contenant nommé qui accumule une liste de versions numérotées. (S’il reste des configurations de lancement dans le compte, commencez par modèles de lancement vs configurations de lancement — elles ne reçoivent plus de nouvelles fonctionnalités et les nouveaux comptes ne peuvent plus en créer.)

Trois façons pour un consommateur de référencer une version :

Un numéro épinglé (Version: "14") — le consommateur lance exactement cette config jusqu’à ce qu’un humain change la référence. Prévisible, auditable, plate. C’est ce que la production veut.
$Default — un pointeur que vous déplacez délibérément avec modify-launch-template. Modifier le modèle ne le déplace pas; promouvoir une version, oui. C’est le juste milieu raisonnable.
$Latest — toujours la version la plus récente, y compris celle qu’un collègue vient de sauvegarder pour tester une théorie. Pratique en dev, une arme chargée en prod : créer une version, c’est déployer.

Le piège subtil : créer une nouvelle version ne déplace pas $Default. Les équipes modifient le modèle, ne voient rien changer dans l’ASG, concluent que les modèles « ne marchent pas », puis quelqu’un bascule l’ASG sur $Latest pour que les modifications prennent effet — et désormais chaque modification future est un déploiement en direct.

Quoi vérifier en premier

Quelle référence de version chaque ASG utilise-t-il? $Latest en production, c’est le constat numéro un.
$Default égale-t-il le numéro de version le plus élevé? Un écart signifie généralement que quelqu’un modifie sans promouvoir — trouvez quelle version est réellement voulue.
Qui peut créer des versions? ec2:CreateLaunchTemplateVersion entre de mauvaises mains plus $Latest, ça égale des changements de production non révisés.
Les versions ont-elles des descriptions? Des descriptions vides, ça veut dire que personne ne peut reconstituer pourquoi la version 9 existe.
La référence d’AMI dans le modèle est-elle épinglée ou résolue depuis un paramètre SSM? Les deux sont légitimes; ne pas savoir lequel ne l’est pas.

Comment vérifier

Listez les modèles avec leur version par défaut et leur dernière version côte à côte :

aws ec2 describe-launch-templates \
  --query 'LaunchTemplates[].[LaunchTemplateName,DefaultVersionNumber,LatestVersionNumber]' \
  --output table

Inspectez ce que chaque version contient réellement, qui l’a créée et quand :

aws ec2 describe-launch-template-versions \
  --launch-template-name web-prod \
  --query 'LaunchTemplateVersions[].[VersionNumber,CreateTime,CreatedBy,VersionDescription]' \
  --output table

Voyez quelle version un groupe Auto Scaling résout :

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names web-prod-asg \
  --query 'AutoScalingGroups[].[AutoScalingGroupName,LaunchTemplate.Version,MixedInstancesPolicy.LaunchTemplate.LaunchTemplateSpecification.Version]'

Dans la console : EC2 > Launch Templates > (modèle) > Versions montre l’historique complet, et EC2 Auto Scaling > Auto Scaling Groups > Details montre la référence de version. CloudTrail enregistre les événements CreateLaunchTemplateVersion et ModifyLaunchTemplate — c’est votre piste d’audit pour « qu’est-ce qui a changé et quand ».

L’approche

Épinglez les ASG de production sur $Default, jamais $Latest. Ça transforme la création de version en geste sûr et révisable, et la promotion de version en déploiement. Les groupes de dev et de staging peuvent rouler $Latest si vous acceptez le compromis là.

Créez les versions à partir d’une base connue, pas à partir de zéro. Utilisez --source-version pour que chaque version soit un diff contre un ancêtre réel :

aws ec2 create-launch-template-version \
  --launch-template-name web-prod \
  --source-version 14 \
  --version-description "AMI 2026-07 reconstruction mensuelle" \
  --launch-template-data '{"ImageId":"ami-0abc1234def567890"}'

Promouvez délibérément. Déplacer le pointeur, c’est le moment du déploiement, alors ça appartient à votre processus de changement :
```
aws ec2 modify-launch-template \
  --launch-template-name web-prod --default-version 15
```
Faites rouler le parc après la promotion. Les instances existantes gardent leur ancienne config pour toujours; seuls les nouveaux lancements prennent la version. Déclenchez un rafraîchissement d’instances de l’ASG pour que le parc en marche converge au lieu de se scinder en trois configs.
Écrivez une description sur chaque version — une ligne qui dit ce qui a changé et le billet ou le commit derrière. Le vous du futur qui fait de l’analyse d’incident à 2 h du matin va lire ça.
Gérez le modèle par IaC (Terraform, CloudFormation) pour que la création de versions passe en révision, et traitez les modifications en console comme du bris de vitre seulement. La documentation EC2 couvre l’ensemble des champs supportés — gardez le modèle comme source d’autorité et le user data mince.
Élaguez les vieilles versions de temps en temps, en gardant assez d’historique pour le retour arrière. delete-launch-template-versions enlève le fouillis; on ne peut pas supprimer la version par défaut.

Quand c’est le mauvais choix

Si vous lancez une instance par trimestre à la main, la cérémonie du versionnement ajoute peu — un ID d’AMI épinglé dans un runbook fait la même job. Aussi, n’utilisez pas les versions de modèle comme mécanisme de déploiement applicatif : livrer le code d’application en cuisant un modèle par version et en recyclant l’ASG fonctionne, mais la boucle de rétroaction est lente comparée à un vrai pipeline de déploiement, et ça emmêle les changements d’infra et d’application dans un seul historique.

Erreurs fréquentes

$Latest sur un ASG de production — chaque modification sauvegardée devient instantanément la config de lancement du prochain événement de montée en charge.
Modifier le modèle et s’attendre à ce que les instances en marche changent. Les versions s’appliquent seulement au lancement; le parc doit être rafraîchi ou remplacé.
Surcharger des champs du modèle au niveau de l’ASG ou de run-instances et l’oublier — le modèle dit une chose, les lancements en font une autre, et le modèle cesse d’être la source de vérité.
Supprimer un modèle encore référencé par des politiques d’instances mixtes ou des flottes spot, ce qui apparaît comme des échecs de lancement à la prochaine montée en charge, au pire moment possible.

Garder le contrôle

Une vérification scriptée hebdomadaire qui signale tout ASG de production référençant $Latest ou un $Default en retard de plus d’une version sans changement ouvert.
Restreignez ModifyLaunchTemplate (la promotion) plus serré que CreateLaunchTemplateVersion (la proposition) dans IAM.
Alarmez sur les lancements échoués de l’ASG — une mauvaise version promue apparaît là en premier.
Gardez les définitions de modèles dans git; une version dont vous ne pouvez pas produire le diff est une version à laquelle vous ne pouvez pas faire confiance.

La discipline de versionnement sur les modèles de lancement coûte pas cher : épingler sur $Default, décrire chaque version, promouvoir exprès, rafraîchir le parc. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.