Modèles de lancement et configuration ASG

Un modèle de lancement est un plan versionné qui indique aux groupes Auto Scaling (et directement à EC2) comment lancer des instances. Il regroupe dans un seul document réutilisable l’ID AMI, le type d’instance, la paire de clés, les groupes de sécurité et les données utilisateur facultatives. Contrairement à l’ancienne configuration de lancement, un modèle de lancement prend en charge plusieurs versions et peut être mis à jour sans remplacer l’ASG.

Vous pouvez créer un modèle de lancement avec AWS CLI à l’aide de create-launch-template. Le paramètre --launch-template-data accepte un objet JSON qui définit tous les paramètres de l’instance. La gestion des versions vous permet de faire évoluer le modèle sans affecter les instances en cours d’exécution, jusqu’à ce que vous soyez prêt à le déployer.

Chaque modèle de lancement commence à la version 1. Lorsque vous créez une nouvelle version, vous pouvez remplacer uniquement les champs qui ont changé : tous les autres paramètres sont hérités de la version source. L’ASG peut être configuré pour utiliser une version $Latest (toujours la plus récente) ou une version $Default (désignée explicitement). L’utilisation de $Default permet de contrôler les déploiements, tandis que $Latest est pratique dans les environnements de développement.

Un Auto Scaling Group (ASG) gère un parc d’instances EC2 dans des limites définies : minimum (plancher), maximum (plafond) et capacité souhaitée (nombre cible à tout moment). Lorsque des instances échouent aux vérifications d’état ou que la stratégie de mise à l’échelle se déclenche, ASG lance ou termine automatiquement des instances afin de maintenir le nombre souhaité entre le minimum et le maximum.

Lorsque vous créez un ASG, vous référencez un modèle de lancement (et non une AMI spécifique directement). Vous indiquez également les sous-réseaux du VPC dans lesquels les instances seront lancées. La répartition sur plusieurs sous-réseaux (un par AZ) vous offre une redondance multi-AZ intégrée : si une AZ tombe en panne, ASG lance automatiquement des instances de remplacement dans les AZ restantes.

Par défaut, un ASG utilise les vérifications d’état EC2, qui ne signalent une instance comme défaillante que si elle est arrêtée, terminée ou si l’hyperviseur indique qu’elle a échoué. Lorsque vous associez un répartiteur de charge, vous devez utiliser les vérifications d’état ELB afin que l’ASG remplace les instances qui sont en fonctionnement mais renvoient des erreurs HTTP 5xx. Il s’agit d’une question fréquente aux examens : choisissez toujours les vérifications d’état ELB lorsqu’un répartiteur de charge est présent dans l’architecture.

Il est essentiel de définir correctement les limites de capacité. Le minimum garantit que votre application peut toujours traiter le trafic (elle ne descend jamais en dessous de cette valeur). Le maximum empêche une mise à l’échelle incontrôlée qui pourrait épuiser les limites de service ou le budget. La capacité souhaitée est la cible initiale ; les stratégies de mise à l’échelle l’ajustent dynamiquement. Si vous définissez min=max=desired, l’ASG fonctionne comme un groupe de taille fixe, ce qui est utile pour les déploiements de modèles de lancement ou pour une capacité fixe.

Pour les applications de niveau Web, associez l’ASG à un groupe cible d’Application Load Balancer. Chaque nouvelle instance lancée par l’ASG est automatiquement enregistrée dans le groupe cible, et les instances terminées en sont automatiquement désenregistrées. Ainsi, le trafic est uniquement dirigé vers des instances saines et en fonctionnement. Vous devez également définir le type de vérification d’état sur ELB afin que l’ASG puisse détecter les défaillances au niveau du répartiteur de charge.

Les données utilisateur sont un script shell (encodé en Base64) qui s’exécute une fois, lors du premier démarrage d’une instance. Dans un modèle de lancement, c’est l’emplacement approprié pour installer des paquets, configurer des agents (CloudWatch, SSM) et récupérer le code de l’application. Veillez à rendre les données utilisateur idempotentes : les scripts pouvant être exécutés plusieurs fois sans danger évitent les problèmes lors de l’actualisation des instances. Pour les configurations complexes, faites appel à AWS Systems Manager ou à un outil de gestion de configuration plutôt que d’intégrer de longs scripts.

Un Warm Pool préinitialise un ensemble d’instances EC2 arrêtées (ou en fonctionnement) dans un état prêt, en dehors de l’ASG. Lorsque l’ASG doit effectuer une mise à l’échelle horizontale, il utilise les instances du pool préchauffé au lieu de lancer des instances à froid, ce qui réduit considérablement le temps nécessaire pour ajouter de la capacité. Les instances du pool préchauffé entraînent des coûts liés à l’état arrêté (EBS uniquement, sans frais de CPU), ce qui revient bien moins cher que de conserver des instances de secours entièrement en fonctionnement.

Lorsque l’ASG réduit sa capacité, il doit décider quelles instances terminer. La stratégie de terminaison par défaut sélectionne d’abord l’AZ qui compte le plus d’instances (pour rééquilibrer), puis le modèle de lancement le plus ancien, puis l’instance la plus proche du début de son heure de facturation. Vous pouvez personnaliser cet ordre ; par exemple, choisissez OldestLaunchTemplate pour supprimer en premier les instances exécutant des configurations obsolètes. ASG effectue également automatiquement un rééquilibrage entre AZ après qu’un sous-réseau est devenu disponible ou après des modifications manuelles.

Dans cette leçon, vous avez appris que les modèles de lancement fournissent un modèle d’instance versionné et réutilisable prenant en charge plusieurs versions ainsi que les pointeurs de version $Latest/$Default ; que les limites de capacité ASG (min/max/desired) contrôlent la taille du parc avec une répartition multi-AZ automatique entre les sous-réseaux ; et que les vérifications d’état ELB doivent être activées lorsqu’un ASG se trouve derrière un répartiteur de charge, afin que les défaillances au niveau de l’application déclenchent un remplacement. Nous allons maintenant étudier les stratégies de mise à l’échelle, notamment le suivi de cible et la mise à l’échelle par paliers.