Modèles de lancement vs configurations de lancement — à quoi ressemble vraiment la migration

La console affiche un avertissement quand vous ouvrez l’ASG qui roule depuis 2021 : « Ce groupe Auto Scaling utilise une configuration de lancement. AWS ne supporte plus la création de nouvelles configurations de lancement. » L’ASG fonctionne encore — les instances démarrent, scalent à la hausse, scalent à la baisse. Rien n’est cassé. Mais l’équipe doit ajouter des instances Spot pour absorber la rafale du matin, et la politique d’instances mixtes n’existe que pour les modèles de lancement. Pas de chemin sans migrer. La migration est mécanique mais pas sans risque, et la façon dont la LC actuelle encode l’AMI, les données utilisateur et le profil IAM laisse quelques angles vifs.

Ce qui se passe

Les configurations de lancement étaient la manière originale de décrire comment un ASG devait démarrer une instance : AMI, type d’instance, paire de clés, groupes de sécurité, données utilisateur, profil d’instance IAM. Un seul tir, immuable. Pour changer quoi que ce soit, vous créiez une nouvelle LC, l’attachiez à l’ASG, et attendiez le prochain rafraîchissement d’instances. Les modèles de lancement font tout ce que faisaient les LC et plus, avec une différence structurelle : les modèles sont versionnés. L’ASG référence une version de modèle (ou $Latest, ou $Default), donc changer l’AMI devient une nouvelle version de modèle plutôt qu’une nouvelle ressource.

Ce que vous n’avez pas avec une configuration de lancement :

Politique d’instances mixtes. Base à la demande + Spot pour la rafale, diversification de types d’instances entre familles. Les ASG sur LC sont à un seul type d’instance.
Plusieurs interfaces réseau. Utile pour des instances qui ont besoin d’une interface publique et d’une privée, ou qui parlent à plusieurs VPC.
Imposition d’IMDSv2. Vous pouvez exiger l’accès aux métadonnées par jeton au niveau du lancement, pas seulement par instance.
Réservations de capacité et placement sur hôtes dédiés. La LC n’a ni l’un ni l’autre.
Mode de crédit illimité T2/T3 au niveau du lancement. Vous pouvez fixer le comportement en rafale dans le modèle plutôt que par instance.
Configurations License Manager. Pour les charges BYOL.
Spécifications de tags appliquées au lancement de l’instance et des volumes. La LC ne taguait que l’instance et exigeait un aws ec2 create-tags séparé pour les volumes.

Les fonctionnalités qui semblent identiques mais ne le sont pas :

Données utilisateur. Les deux acceptent du base64. Les modèles permettent des données utilisateur par version, ce qui veut dire que le retour arrière sur un mauvais user-data est update-auto-scaling-group --launch-template Version=N-1 plutôt qu’une LC à recréer.
Référence AMI. Les LC tiennent un ID d’AMI. Les modèles aussi, mais vous pouvez le changer en créant une nouvelle version du même modèle. L’ASG qui référence $Latest capte le changement au prochain rafraîchissement, ce qui est plus proche de la manière dont les équipes pensent un déploiement.
Mappages de périphériques de bloc. Les deux les supportent. Les modèles permettent de marquer un volume comme chiffré par défaut et de référencer une clé KMS, ce que la LC supportait partiellement.

La fonctionnalité structurelle qui piège les équipes : les modèles de lancement ont la notion de $Default et $Latest. $Latest est toujours le numéro de version le plus élevé. $Default est la version que vous avez marquée comme telle — souvent la dernière connue bonne. Les ASG qui référencent $Default ne capteront pas une nouvelle version en cours tant que vous ne l’avez pas adoubée. Ceux qui référencent $Latest oui. Choisissez un modèle et documentez-le.

Comment vérifier

Trouver tous les ASG encore sur configuration de lancement :

aws autoscaling describe-auto-scaling-groups \
  --query 'AutoScalingGroups[?LaunchConfigurationName!=null].[AutoScalingGroupName,LaunchConfigurationName]' \
  --output table

Pour chaque LC, tirer la configuration complète pour avoir une référence côte à côte avant de la supprimer :

aws autoscaling describe-launch-configurations \
  --launch-configuration-names my-app-prod-lc-2021 \
  --query 'LaunchConfigurations[0]' \
  --output json > my-app-prod-lc-2021.json

Le fichier contient chaque champ que la migration doit traduire : ImageId, InstanceType, KeyName, SecurityGroups, IamInstanceProfile, UserData (base64), BlockDeviceMappings, EbsOptimized, InstanceMonitoring, SpotPrice si applicable, AssociatePublicIpAddress, et MetadataOptions.

AWS fournit un assistant qui crée un modèle de lancement à partir d’une LC. Utilisez-le comme point de départ, pas comme artefact final :

aws ec2 create-launch-template \
  --launch-template-name my-app-prod-lt \
  --source-version 1 \
  --launch-template-data file://my-app-prod-lc-2021.json

L’assistant préserve ce qu’il peut mais rate deux choses que les équipes rencontrent : le format des groupes de sécurité (les LC utilisent des noms, les modèles exigent des IDs dans les VPC non par défaut), et le profil d’instance IAM (les LC acceptent IamInstanceProfile comme chaîne, les modèles exigent {"Name": "..."} ou {"Arn": "..."}). Ouvrir le JSON résultant et réconcilier ces deux champs à la main avant de lancer quoi que ce soit.

Vérifier que le modèle produit une instance identique avant de basculer l’ASG. Démarrer une instance issue du modèle dans un VPC hors prod :

aws ec2 run-instances \
  --launch-template LaunchTemplateName=my-app-prod-lt,Version=1 \
  --subnet-id subnet-0123456789abcdef0

Se connecter en SSH. Confirmer l’AMI, le rôle IAM visible via curl http://169.254.169.254/latest/meta-data/iam/info, l’exécution des données utilisateur, les groupes de sécurité attachés, les tailles de volumes et le chiffrement. La vérification « ça a l’air pareil » est ce qui attrape la traduction nom-vs-id des groupes de sécurité.

La correction

La migration sur un ASG vivant, sans perturbation du rafraîchissement d’instances :

Photographier l’état actuel. aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names my-app-prod-asg --output json > my-app-prod-asg-pre-migration.json. C’est l’artefact de retour arrière.
Créer le modèle de lancement en traduisant les champs de la LC, en faisant la réconciliation des IDs de groupes de sécurité et du profil IAM, et en ajoutant les nouvelles fonctionnalités attendues (l’imposition d’IMDSv2 est la plus commune). La version 1 du modèle est l’équivalent de la LC. Résister à l’envie d’ajouter des changements pendant la migration — d’abord traduire, ensuite changer.
Tester un lancement hors bande, dans un VPC hors prod, avec la même version du modèle. Confirmer tout comme à l’étape de vérification.
Basculer la référence de l’ASG. C’est le moment critique :
```
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-app-prod-asg \
  --launch-template LaunchTemplateName=my-app-prod-lt,Version='$Default'
```
Les instances en cours ne sont pas touchées. Les prochains scale-out utiliseront le modèle. La LC est maintenant orpheline mais reste attachée comme métadonnée historique.
Faire rouler la flotte via un rafraîchissement d’instances, avec un pourcentage de santé minimum raisonnable. Ne pas tout rouler d’un coup à la première migration :
```
aws autoscaling start-instance-refresh \
  --auto-scaling-group-name my-app-prod-asg \
  --preferences MinHealthyPercentage=90,InstanceWarmup=300
```
Surveiller CloudWatch pour le vrai signal de santé applicative, pas seulement InService. L’erreur sur le grace-period des health checks pendant un refresh est un sujet KB à part — voir Health checks EC2 vs ELB.
Décommissionner la configuration de lancement après que le refresh est complet et qu’un cycle d’affaires complet a tourné sur le modèle. aws autoscaling delete-launch-configuration --launch-configuration-name my-app-prod-lc-2021.

Les pièges qui mordent sur les ASG de 5 ans, par fréquence :

Nom vs ID de groupe de sécurité. Les LC d’avant l’ère VPC-par-défaut acceptaient des noms. Les modèles dans tout VPC non par défaut exigent des IDs. L’assistant laisse silencieusement le nom, le test échoue avec « InvalidGroup.NotFound », et l’équipe pense que la LC était mal configurée. Elle ne l’était pas — le format exigé a changé.

Forme du profil d’instance IAM. Même cause. L’assistant passe la chaîne telle quelle. Le lancement retourne une erreur « champ requis manquant » qui ne nomme pas clairement le champ.

Défaut des options de métadonnées. Les nouveaux modèles ont IMDSv2 optionnel par défaut (jeton-ou-pas). Pour imposer v2 sur la flotte, mettre HttpTokens=required et HttpEndpoint=enabled dans MetadataOptions. Certains logiciels anciens (très vieux SDK, vieilles versions de cloud-init) ne gèrent pas v2 — vérifier au test.

Héritage de tags. Les LC propageaient les tags aux instances. Les modèles utilisent TagSpecifications pour l’instance et les volumes EBS. Migrer les paramètres de propagation de tags de l’ASG et les TagSpecifications du modèle séparément — ce n’est pas redondant, ils couvrent des ressources différentes à des moments différents.

La migration est mécanique tant que vous la traitez comme un exercice de traduction et non de mise à niveau. Traduire la LC en un modèle v1 qui démarre des instances identiques. Faire rouler la flotte là-dessus. Puis empiler instances mixtes, imposition d’IMDSv2, warm pools et le reste comme des changements séparés et revus — chacun une nouvelle version du modèle avec un chemin de retour arrière propre.

Stack Harbor opère les paliers applicatifs sur ASG et les politiques d’auto-scaling à coût plafonné dans le cadre de Gestion AWS et de la couche Auto-scaling. Si vos événements de scaling sont encore des surprises, commencez par une consultation d’infrastructure.