Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Groupes Auto Scaling
**Note**
Si vous découvrez les groupes Auto Scaling, suivez les étapes du didacticiel [Create your first Auto Scaling group](create-your-first-auto-scaling-group.md) pour commencer et voir comment un groupe Auto Scaling réagit lorsqu'une instance du groupe se termine.
Un *groupe Auto Scaling* contient un ensemble d'instances EC2 traitées comme un regroupement logique, aux fins de mise à l'échelle et de gestion automatique. Ils vous permettent également d'utiliser des fonctionnalités Amazon EC2 Auto Scaling telles que les remplacements des surveillances de l'état et des politiques de mise à l'échelle. La mise à l'échelle et le maintien automatiques du nombre d'instances dans un groupe Auto-Scaling constitue la fonctionnalité de base du service Amazon EC2 Auto Scaling.
La taille d'un groupe Auto Scaling dépend du nombre d'instances que vous définissez en tant que capacité souhaitée. Vous pouvez ajuster sa taille afin de répondre à la demande, manuellement ou à l'aide de la scalabilité automatique.
Un groupe Auto Scaling démarre en lançant suffisamment d'instances pour atteindre la capacité souhaitée. Le groupe maintient le nombre d'instances en réalisant des surveillances périodiques de l'état sur les instances du groupe. Le groupe Auto Scaling continue à conserver un nombre fixe d'instances, même si une instance devient défectueuse. Si une instance devient défectueuse, le groupe la résilie et en lance une autre pour la remplacer. Pour de plus amples informations, veuillez consulter [Surveillance de l’état des instances dans un groupe Auto Scaling](ec2-auto-scaling-health-checks.md).
Vous pouvez utiliser des politiques de mise à l'échelle pour augmenter ou réduire dynamiquement le nombre d'instances du groupe et répondre ainsi aux changements de conditions. Lorsque la politique de mise à l'échelle est appliquée, le groupe Auto Scaling ajuste la capacité souhaitée du groupe, entre les valeurs de capacité minimum et maximum que vous spécifiez, et lance les instances ou la résilie le cas échéant. Vous pouvez également mettre à niveau selon un calendrier. Pour de plus amples informations, veuillez consulter [Choisissez votre méthode de mise à l’échelle](scaling-overview.md).
Lors de la création d’un groupe Auto Scaling, vous pouvez choisir de lancer les instances à la demande et/ou les instances Spot. Vous pouvez spécifier plusieurs options d'achat pour votre groupe Auto Scaling uniquement lorsque vous utilisez unlaunch template. Pour de plus amples informations, veuillez consulter [Groupes Auto Scaling combinant plusieurs types d'instances et options d'achat](ec2-auto-scaling-mixed-instances-groups.md).
Les instances Spot vous permettent d'accéder à des fonctionnalités non-utilisées de EC2 tout en bénéficiant de remises conséquentes par rapport aux tarifs à la demande. Pour plus d'informations, consultez [Amazon EC2 instances Spot](https://aws.amazon.com/ec2/spot/pricing/). Il existe des différences importantes entre les instances ponctuelles et les instances à la demande :
+ Le prix des instances ponctuelles varie en fonction de la demande
+ Amazon EC2 peut résilier une instance Spot individuelle au fur et à mesure que la disponibilité ou le prix des instances Spot change
Lorsque votre instance Spot est résiliée, le groupe Auto Scaling tente de lancer une instance de remplacement pour maintenir la capacité souhaitée pour le groupe.
Lorsque les instances sont lancées, si vous avez spécifié plusieurs zones de disponibilité, la capacité souhaitée est distribuée entre ces zones de disponibilité. Si une action de mise à l'échelle se produit, Amazon EC2 Auto Scaling gère automatiquement l'équilibre entre l'ensemble des zones de disponibilité que vous spécifiez.
**Topics**
+ [Créer des groupes Auto Scaling à l’aide de modèles de lancement](create-auto-scaling-groups-launch-template.md)
+ [Créer des groupes Auto Scaling à l’aide de configurations de lancement](create-auto-scaling-groups-launch-configuration.md)
+ [Lancer des instances de manière synchrone](launch-instances-synchronously.md)
+ [Mettre à jour un groupe Auto Scaling](update-auto-scaling-group.md)
+ [Baliser des groupes et des instances Auto Scaling](ec2-auto-scaling-tagging.md)
+ [Politiques de maintenance des instances](ec2-auto-scaling-instance-maintenance-policy.md)
+ [Hooks de cycle de vie Amazon EC2 Auto Scaling](lifecycle-hooks.md)
+ [Réduisez la latence pour les applications dont le temps de démarrage est long à l'aide de pools chauds](ec2-auto-scaling-warm-pools.md)
+ [Changement de zone du groupe Auto Scaling](ec2-auto-scaling-zonal-shift.md)
+ [Distribution des zones de disponibilité d’un groupe Auto Scaling](ec2-auto-scaling-availability-zone-balanced.md)
+ [Détachez ou attachez des instances de votre groupe Auto Scaling](ec2-auto-scaling-detach-attach-instances.md)
+ [Supprimer temporairement des instances du groupe Auto Scaling](as-enter-exit-standby.md)
+ [Supprimer votre infrastructure Auto Scaling](as-process-shutdown.md)
# Créer des groupes Auto Scaling à l’aide de modèles de lancement
Si vous avez créé un modèle de lancement, vous pouvez créer un groupe Auto Scaling qui utilise le modèle de lancement comme modèle de configuration pour ses instances EC2. Le modèle de lancement spécifie plusieurs informations, notamment l’identifiant d’AMI, le type d’instance, la paire de clés, les groupes de sécurité et le mappage de périphérique de stockage en mode bloc pour les instances. Pour de plus amples informations sur la création de modèles de lancement, veuillez consulter [Créer un modèle de lancement pour un groupe Auto Scaling](create-launch-template.md).
Vous devez disposer des autorisations nécessaires pour créer un groupe Auto Scaling. Vous devez également disposer des autorisations nécessaires pour créer un rôle lié à un service qu’Amazon EC2 Auto Scaling utilise pour effectuer les actions en votre nom, s’il n’existe pas encore. Pour obtenir des exemples de politiques IAM qu’un administrateur peut utiliser comme référence pour vous accorder des autorisations, consultez [Exemples de politiques basées sur l’identité](security_iam_id-based-policy-examples.md) et [Contrôlez l'utilisation du modèle de lancement Amazon EC2 dans les groupes Auto Scaling](ec2-auto-scaling-launch-template-permissions.md).
**Topics**
+ [Créer un groupe Auto Scaling avec un modèle de lancement](create-asg-launch-template.md)
+ [Créer un groupe Auto Scaling avec l'Amazon EC2 Launch Wizard](create-asg-ec2-wizard.md)
+ [Groupes Auto Scaling combinant plusieurs types d'instances et options d'achat](ec2-auto-scaling-mixed-instances-groups.md)
# Créer un groupe Auto Scaling avec un modèle de lancement
Lorsque vous créez un groupe Auto Scaling, vous devez indiquer les informations nécessaires pour configurer les instances Amazon EC2, les zones de disponibilité et les sous-réseaux VPC pour les instances, la capacité souhaitée et les limites de capacité minimale et maximale.
Pour configurer des instances Amazon EC2 lancées par votre groupe Auto Scaling, vous pouvez spécifier un modèle de lancement ou une configuration du lancement. La procédure suivante montre comment créer un groupe Auto Scaling avec un modèle de lancement.
**Conditions préalables**
+ Vous devez avoir créé un modèle de lancement. Pour de plus amples informations, veuillez consulter [Créer un modèle de lancement pour un groupe Auto Scaling](create-launch-template.md).
**Pour créer un groupe Auto Scaling avec un modèle de lancement (console)**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Dans la barre de navigation en haut de l'écran, choisissez le même Région AWS que celui que vous avez utilisé lors de la création du modèle de lancement.
1. Choisissez **Créer un groupe Auto Scaling**.
1. Dans la page **Choose launch template or configuration** (Choisir un modèle de lancement ou une configuration), procédez comme suit :
1. Pour **Auto Scaling group name** (Nom du groupe Auto Scaling), saisissez un nom pour votre groupe Auto Scaling.
1. Dans **Launch template** (Modèle de lancement), choisissez un modèle de lancement existant.
1. Pour **Version du modèle de lancement**, indiquez si le groupe Auto Scaling utilise la version par défaut, la version la plus récente ou une version spécifique du modèle de lancement lors de l'évolutivité horizontale.
1. Vérifiez que votre modèle de lancement prend en charge toutes les options que vous envisagez d'utiliser, puis choisissez **Next** (Suivant).
1. Sur la page **Choisir les options de lancement d’instance**, si vous n’utilisez pas plusieurs types d’instance, vous pouvez ignorer la section **Exigences relatives au type d’instance** pour utiliser le type d’instance EC2 indiqué dans le modèle de lancement.
Pour utiliser plusieurs types d’instances, consultez [Groupes Auto Scaling combinant plusieurs types d'instances et options d'achat](ec2-auto-scaling-mixed-instances-groups.md).
1. Sous **Network** (Réseau), pour **VPC**, choisissez un VPC. Le groupe Auto Scaling doit être créé dans le même VPC que le groupe de sécurité que vous avez spécifié dans votre modèle de lancement.
1. Pour **Availability Zones and subnets** (Zones de disponibilité et sous-réseaux), choisissez un ou plusieurs sous-réseaux dans le VPC spécifié. Utilisez les sous-réseaux dans plusieurs zones de disponibilité pour une haute disponibilité. Pour de plus amples informations, veuillez consulter [Considérations à prendre en compte lors du choix des sous-réseaux VPC](asg-in-vpc.md#as-vpc-considerations).
1. Pour **la distribution par zone de disponibilité**, sélectionnez une stratégie de distribution. Pour de plus amples informations, veuillez consulter [Distribution des zones de disponibilité d’un groupe Auto Scaling](ec2-auto-scaling-availability-zone-balanced.md).
1. Si vous avez créé un modèle de lancement avec un type d'instance spécifié, vous pouvez passer à l'étape suivante pour créer un groupe Auto Scaling qui utilise le type d'instance dans le modèle de lancement.
Vous pouvez également choisir l'option **Remplacer le modèle de lancement** si aucun type d'instance n'est spécifié dans votre modèle de lancement ou si vous souhaitez utiliser plusieurs types d'instance pour la scalabilité automatique. Pour de plus amples informations, veuillez consulter [Groupes Auto Scaling combinant plusieurs types d'instances et options d'achat](ec2-auto-scaling-mixed-instances-groups.md).
1. Choisissez **Next** (Suivant) pour passer à l'étape suivante.
Vous pouvez également accepter le reste des valeurs par défaut, puis choisir **Skip to review** (Passer à la révision).
1. (Facultatif) Sur la page **Intégrer à d'autres services**, configurez les options suivantes, puis choisissez **Suivant** :
1. Pour l'**équilibrage** de charge, choisissez si vous souhaitez associer votre groupe Auto Scaling à un équilibreur de charge. Pour de plus amples informations, veuillez consulter [Elastic Load Balancing](autoscaling-load-balancer.md).
1. Pour les **options d'intégration de VPC Lattice**, choisissez si vous souhaitez utiliser VPC Lattice. Pour de plus amples informations, veuillez consulter [Gérez le flux de trafic avec un groupe cible VPC Lattice](ec2-auto-scaling-vpc-lattice.md).
1. Pour le décalage de **zone Amazon Application Recovery Controller (ARC), cochez la case pour activer le décalage** de zone. Pour de plus amples informations, veuillez consulter [Changement de zone du groupe Auto Scaling](ec2-auto-scaling-zonal-shift.md).
1. Si vous activez le changement de zone, pour le **comportement du contrôle de l'état**, sélectionnez Ignorer les éléments malsains ou Remplacer les éléments non sains. Pour de plus amples informations, veuillez consulter [Comment fonctionne le décalage de zone pour les groupes Auto Scaling](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works).
1. Sous **Contrôles de santé**, pour les **types de bilans de santé supplémentaires**, sélectionnez **Activer les bilans de santé Amazon EBS**. Pour de plus amples informations, veuillez consulter [Surveillez les instances Auto Scaling dont les volumes Amazon EBS sont altérés à l'aide de contrôles de santé](monitor-and-replace-instances-with-impaired-ebs-volumes.md).
1. Dans le champ **Période de grâce de la surveillance de l’état**, saisissez le délai en secondes. Ce délai correspond à la durée pendant laquelle Amazon EC2 Auto Scaling doit attendre avant de vérifier l'état de santé d'une instance après son entrée dans `InService` cet état. Pour de plus amples informations, veuillez consulter [Définir la période de grâce de la surveillance de l'état pour un groupe Auto Scaling](health-check-grace-period.md).
1. (Facultatif) Sur la page **Configurer la taille et le dimensionnement du groupe**, configurez les options suivantes, puis choisissez **Suivant** :
1. Dans **Taille du groupe**, pour la **Capacité souhaitée**, entrez le nombre initial d’instances à lancer.
1. Sous **Mise à l'****échelle, limites** de mise à l'échelle, si votre nouvelle valeur pour la **capacité souhaitée** **est supérieure à la capacité minimale** **souhaitée et à la capacité** **maximale souhaitée, la capacité** maximale souhaitée est automatiquement augmentée jusqu'à la nouvelle valeur de capacité souhaitée. Vous pouvez modifier ces limites si nécessaire. Pour de plus amples informations, veuillez consulter [Définissez des limites de mise à l’échelle pour votre groupe Auto Scaling](asg-capacity-limits.md).
1. Pour le **dimensionnement automatique**, indiquez si vous souhaitez créer une politique de dimensionnement de suivi des cibles. Vous pouvez également élaborer cette politique après avoir créé votre groupe Auto Scaling.
Si vous choisissez la **politique de dimensionnement de suivi des cibles**, suivez les instructions dans [Création d'une politique de suivi des cibles et d'échelonnement](policy_creating.md) pour créer la politique.
1. Sous **Politique de maintenance des instances**, indiquez si vous souhaitez créer une politique de maintenance des instances. Vous pouvez également élaborer cette politique après avoir créé votre groupe Auto Scaling. Pour créer une politique, suivez les instructions fournies dans [Définir une politique de maintenance des instances](set-instance-maintenance-policy.md).
1. Sous **Paramètres de capacité supplémentaire**, **Préférence de réservation de capacité**, indiquez si vous souhaitez utiliser une préférence de réservation de capacité. Pour de plus amples informations, veuillez consulter [Réservez des capacités dans des zones de disponibilité spécifiques avec des réservations de capacité](use-ec2-capacity-reservations.md).
1. Sous **Paramètres supplémentaires**, Protection **par évolutivité de l'instance, indiquez si vous souhaitez activer la protection** par évolutivité de l'instance. Pour de plus amples informations, veuillez consulter [Utiliser la protection évolutive de l'instance pour contrôler la fermeture de l'instance](ec2-auto-scaling-instance-protection.md).
1. Pour la **surveillance**, choisissez d'activer ou non la collecte des métriques de CloudWatch groupe. Ces métriques fournissent des mesures qui peuvent être des indicateurs d'un problème potentiel, comme le nombre d'instances en cours de résiliation ou le nombre d'instances en attente. Pour de plus amples informations, veuillez consulter [Surveillez CloudWatch les métriques de vos groupes et instances Auto Scaling](ec2-auto-scaling-cloudwatch-monitoring.md).
1. Pour le **préchauffage de l'instance par défaut**, sélectionnez cette option et choisissez le temps de préchauffage de votre application. Si vous créez un groupe Auto Scaling doté d'une politique de dimensionnement, la fonctionnalité de préchauffage de l'instance par défaut améliore les CloudWatch métriques Amazon utilisées pour le dimensionnement dynamique. Pour de plus amples informations, veuillez consulter [Définir la préparation par défaut d'instance d'un groupe Auto Scaling](ec2-auto-scaling-default-instance-warmup.md).
1. (Facultatif) Sur la page **Ajouter des notifications**, configurez la notification, puis choisissez **Suivant**. Pour de plus amples informations, veuillez consulter [Options de notification Amazon SNS pour Amazon EC2 Auto Scaling](ec2-auto-scaling-sns-notifications.md).
1. (Facultatif) Sur la page **Ajouter des balises**, choisissez **Ajouter une balise**, fournissez une clé de balise et une valeur pour chaque balise, puis choisissez **Suivant**. Pour de plus amples informations, veuillez consulter [Baliser des groupes et des instances Auto Scaling](ec2-auto-scaling-tagging.md).
1. Sur la page **Review**, sélectionnez **Create Auto Scaling group (Créer un groupe Auto Scaling)**.
**Pour créer un groupe Auto Scaling avec la ligne de commande**
Vous pouvez utiliser l'une des commandes suivantes :
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) (AWS CLI)
+ [Nouveau- ASAuto ScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
# Créer un groupe Auto Scaling avec l'Amazon EC2 Launch Wizard
La procédure suivante montre comment créer un groupe Auto Scaling en utilisant l'assistant de **Launch instance** (lancement d'instance) dans la console Amazon EC2. Cette option remplit automatiquement un modèle de lancement avec certains détails de configuration de l'assistant de** lancement d'instance**.
**Note**
L'assistant ne remplit pas le groupe Auto Scaling avec le nombre d'instances que vous spécifiez ; il remplit uniquement le modèle de lancement avec l'ID Amazon Machine Image (AMI) et le type d'instance. Utilisez l'assistant de **Create Auto Scaling group** (création de groupe Auto Scaling) pour spécifier le nombre d'instances à lancer.
Une AMI fournit les informations nécessaires à la configuration d'une instance. Lorsque vous avez besoin de plusieurs instances configurées de manière identique, il est possible de lancer plusieurs instances à partir d’une même AMI. Nous vous recommandons d'utiliser une AMI personnalisée sur laquelle votre application est déjà installée pour éviter que vos instances ne soient résiliées si vous redémarrez une instance appartenant à un groupe Auto Scaling. Pour utiliser une AMI personnalisée avec Amazon EC2 Auto Scaling, vous devez d'abord créer votre AMI à partir d'une instance personnalisée, puis utiliser l'AMI pour créer un modèle de lancement pour votre groupe Auto Scaling.
**Conditions préalables**
+ Vous devez avoir créé une AMI personnalisée Région AWS là où vous prévoyez de créer le groupe Auto Scaling. Pour plus d’informations, consultez [Create an AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html) dans le *Guide d’utilisation d’Amazon EC2*.
## Utiliser une AMI personnalisée comme modèle
Dans cette section, vous utilisez l’assistant de lancement Amazon EC2 pour remplir automatiquement un modèle de lancement avec votre AMI personnalisée. Vous pouvez également configurer le modèle de lancement à partir de zéro ou pour une description plus détaillée des paramètres que vous pouvez configurer dans votre modèle de lancement, consultez [Créer votre modèle de lancement (console)](create-launch-template.md#create-launch-template-for-auto-scaling).
**Pour utiliser une AMI personnalisée comme modèle**
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans la barre de navigation en haut de l'écran, le courant Région AWS est affiché. Sélectionnez une région dans laquelle vous souhaitez lancer votre groupe Auto Scaling.
1. Dans le panneau de navigation, choisissez **Instances**.
1. Choisissez **Launch instance** (Lancer une instance), puis effectuez les opérations suivantes :
1. Sous **Name and tags** (Nom et balises), laissez le champ **Name** (Nom) vide. Le nom ne fait pas partie des données utilisées pour créer un modèle de lancement.
1. Sous **Images de l'application et du système d'exploitation (Amazon Machine Image)**, choisissez **Parcourir davantage AMIs** pour parcourir le catalogue AMI complet.
1. Choisissez **Mon AMIs**, recherchez l'AMI que vous avez créée, puis sélectionnez **Sélectionner**.
1. Pour **Instance type** (Type d'Instance), choisissez un type d'instance.
**Note**
Choisissez le même type d'instance que celui que vous avez utilisé lorsque vous avez créé l'AMI ou un type plus puissant.
1. Sur le côté droit de l'écran, sous **Summary** (Récapitulatif), pour **Number of instances** (Nombre d'instances), saisissez le nombre de votre choix. Le numéro que vous saisissez ici n'est pas important. Vous indiquez le nombre d'instances que vous souhaitez lancer lorsque vous créez le groupe Auto Scaling.
Sous le champ **Number of instances** (Nombre d'instances), un message s'affiche indiquant **When launching more than 1 instance, consider EC2 Auto Scaling** (Lorsque vous lancez plus d'une instance, envisagez EC2 Auto Scaling).
1. Cliquez sur le texte du lien hypertexte **consider EC2 Auto Scaling** (envisagez EC2 Auto Scaling).
1. Dans la boîte de dialogue de confirmation **Launch into Auto Scaling Group** (Lancer dans le groupe Auto Scaling), choisissez **Continue** (Continuer) pour accéder à la page **Create launch template** (Créer un modèle de lancement) avec l'AMI et le type d'instance que vous avez sélectionnés dans l'assistant de lancement d'instance déjà remplis.
Après avoir choisi **Continue** (Continuer), la page **Create launch template** (Créer un modèle de lancement) s'ouvre. Procédez comme suit pour terminer la création d’un modèle de lancement.
**Pour créer un modèle de lancement**
1. Sous **Launch template name and description** (Nom et description du modèle de lancement), saisissez le nom et une description du nouveau modèle de lancement.
1. (Facultatif) Sous **Key pair (login)** (Paire de clés [connexion]), pour **Key pair name** (Nom de la paire de clés), choisissez le nom de la paire de clés précédemment créée à utiliser lors de la connexion aux instances, par exemple, en utilisant SSH.
1. (Facultatif) Sous **Network settings** (Paramètres réseau), pour **Security groups** (Groupes de sécurité), choisissez un ou plusieurs [groupes de sécurité](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html) précédemment créés.
1. (Facultatif) Sous **Configure storage** (Configurer le stockage), mettez à jour la configuration du stockage. La configuration de stockage par défaut est déterminée par l'AMI et le type d'instance.
1. Lorsque vous avez terminé de configurer le modèle de lancement, sélectionnez **Create launch template** (Créer un modèle de lancement).
1. Sur la page de confirmation, choisissez **Créer la configuration du lancement**.
## Créer un groupe Auto Scaling
**Note**
Le reste de cette rubrique décrit la procédure de base pour créer un groupe Auto Scaling. Pour plus de description des paramètres que vous pouvez configurer pour votre groupe Auto Scaling, consultez [Créer un groupe Auto Scaling avec un modèle de lancement](create-asg-launch-template.md).
Après avoir choisi **Create Auto Scaling group** (Créer un groupe Auto Scaling), l'assistant **Create Auto Scaling group** (Créer un groupe Auto Scaling) s'ouvre. Suivez cette procédure pour créer un groupe Auto Scaling.
**Pour créer un groupe Auto Scaling**
1. Dans la page **Choose launch template or configuration** (Choisir un modèle de lancement ou une configuration), entrez un nom pour le groupe Auto Scaling.
1. Le modèle de lancement que vous avez créé est déjà sélectionné pour vous.
Pour **Version du modèle de lancement**, indiquez si le groupe Auto Scaling utilise la version par défaut, la version la plus récente ou une version spécifique du modèle de lancement lors de l'évolutivité horizontale.
1. Choisissez **Next** (Suivant) pour passer à l'étape suivante.
1. Sur la page **Choisir les options de lancement d’instance**, si vous n’utilisez pas plusieurs types d’instance, vous pouvez ignorer la section **Exigences relatives au type d’instance** pour utiliser le type d’instance EC2 indiqué dans le modèle de lancement.
Pour utiliser plusieurs types d’instances, consultez [Groupes Auto Scaling combinant plusieurs types d'instances et options d'achat](ec2-auto-scaling-mixed-instances-groups.md).
1. Sous **Network** (Réseau), pour **VPC**, choisissez un VPC. Le groupe Auto Scaling doit être créé dans le même VPC que le groupe de sécurité que vous avez spécifié dans votre modèle de lancement.
**Astuce**
Si vous n'avez pas spécifié de groupe de sécurité dans votre modèle de lancement, vos instances sont lancées avec un groupe de sécurité par défaut du VPC que vous spécifiez. Par défaut, ce groupe de sécurité n'autorise pas le trafic entrant provenant de réseaux externes.
1. Pour **Availability Zones and subnets** (Zones de disponibilité et sous-réseaux), choisissez un ou plusieurs sous-réseaux dans le VPC spécifié.
1. Pour **la distribution par zone de disponibilité**, sélectionnez une stratégie de distribution. Pour de plus amples informations, veuillez consulter [Distribution des zones de disponibilité d’un groupe Auto Scaling](ec2-auto-scaling-availability-zone-balanced.md).
1. Choisissez deux fois **Next** (Suivant) pour aller à la page **Configurer la taille du groupe et les politiques de mise à l'échelle**.
1. Sous **Taille du groupe**, définissez la **capacité souhaitée** (nombre initial d’instances à lancer immédiatement après la création du groupe Auto Scaling).
1. Dans la section **Mise à l’échelle**, sous **Limites de mise à l’échelle**, si votre nouvelle valeur pour la **capacité souhaitée** est supérieure à la **capacité minimale souhaitée** et à la **capacité maximale souhaitée**, la **capacité maximale souhaitée** est automatiquement augmentée à la nouvelle valeur de capacité souhaitée. Vous pouvez modifier ces limites si nécessaire. Pour de plus amples informations, veuillez consulter [Définissez des limites de mise à l’échelle pour votre groupe Auto Scaling](asg-capacity-limits.md).
1. Choisissez **Skip to review** (Passer à la révision).
1. Sur la page **Vérifier**, sélectionnez **Créer un groupe Auto Scaling**.
## Étapes suivantes
Vous pouvez vérifier que le groupe Auto Scaling a été créé correctement en consultant l'historique des activités. Dans l'onglet **Activité**, sous **Historique de l'activité**, la colonne **Statut** indique si votre groupe Auto Scaling a réussi à lancer des instances. Si les instances ne sont pas lancées ou si elles sont lancées, mais sont aussitôt résiliées, consultez les rubriques suivantes pour connaître les causes et les résolutions possibles :
+ [Dépanner Amazon EC2 Auto Scaling : échecs de lancement d'instance EC2](ts-as-instancelaunchfailure.md)
+ [Résoudre les problèmes d'Amazon EC2 Auto Scaling : AMI](ts-as-ami.md)
+ [Résoudre les problèmes liés aux instances défectueuses dans Amazon EC2 Auto Scaling](ts-as-healthchecks.md)
Vous pouvez maintenant attacher un équilibreur de charge dans la même région que votre groupe Auto Scaling, si vous le souhaitez. Pour de plus amples informations, veuillez consulter [Utilisez Elastic Load Balancing pour répartir le trafic applicatif entrant dans votre groupe Auto Scaling](autoscaling-load-balancer.md).
# Groupes Auto Scaling combinant plusieurs types d'instances et options d'achat
Vous pouvez lancer et mettre automatiquement à l’échelle une flotte d’instances à la demande et d’instances Spot au sein d’un même groupe Auto Scaling. En plus de bénéficier de remises pour l'utilisation des instances Spot, vous pouvez utiliser les instances réservées ou les Savings Plans pour bénéficier de remises sur le tarif normal des instances à la demande. Ces facteurs vous permettent de réaliser des économies optimales sur les instances EC2 et vous font bénéficier de la mise à l’échelle et des performances souhaitées pour votre application.
Les instances Spot sont des capacités inutilisées disponibles à des prix très réduits par rapport au prix d'EC2 On-Demand. Les instances Spot constituent un choix économique si vous êtes flexible quant au moment où vos applications s’exécutent et à la possibilité de les interrompre. Ils peuvent être utilisés pour diverses applications flexibles et tolérantes aux pannes. Les exemples incluent les serveurs Web apatrides, les points de terminaison d'API, les applications de mégadonnées et d'analyse, les charges de travail conteneurisées, les CI/CD pipelines, le calcul haute performance et haut débit (HPC/HTC), les charges de travail de rendu et d'autres charges de travail flexibles.
Pour plus d'informations, consultez la section [Options d'achat d'instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html) dans le guide de l'*utilisateur Amazon EC2*.
**Topics**
+ [Vue d'ensemble de la configuration pour la création d'un groupe d'instances mixtes](mixed-instances-groups-set-up-overview.md)
+ [Stratégies d’allocation pour plusieurs types d’instances](allocation-strategies.md)
+ [Création d'un groupe d'instances mixtes à l'aide de la sélection du type d'instance basée sur les attributs](create-mixed-instances-group-attribute-based-instance-type-selection.md)
+ [Créer un groupe d’instances mixtes en choisissant manuellement les types d’instances](create-mixed-instances-group-manual-instance-type-selection.md)
+ [Configurer un groupe Auto Scaling pour utiliser les poids d'instance](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md)
+ [Utiliser plusieurs modèles de lancement](ec2-auto-scaling-mixed-instances-groups-launch-template-overrides.md)
# Vue d'ensemble de la configuration pour la création d'un groupe d'instances mixtes
Cette rubrique fournit une vue d'ensemble et les meilleures pratiques pour créer un groupe d'instances mixtes Auto Scaling.
**Topics**
+ [Présentation de](#mixed-instances-groups-overview)
+ [Flexibilité du type d’instance](#mixed-instances-group-instance-flexibility)
+ [Flexibilité des zones de disponibilité](#mixed-instances-group-az-flexibility)
+ [prix Spot max](#mixed-instances-group-spot-max-price)
+ [Rééquilibrage de capacité proactif](#use-capacity-rebalancing)
+ [Comportement de mise à l’échelle.](#mixed-instances-group-scaling-behavior)
+ [Disponibilité régionale des types d’instances](#setup-overview-regional-availability-of-instance-types)
+ [Ressources connexes](#setup-overview-related-resources)
+ [Limitations](#setup-overview-limitations)
## Présentation de
Pour créer un groupe d’instances mixtes, deux options s’offrent à vous :
+ [Sélection du type d'instance basée sur les attributs](create-mixed-instances-group-attribute-based-instance-type-selection.md) : définissez vos exigences de calcul pour choisir automatiquement vos types d'instances en fonction de leurs attributs d'instance spécifiques.
+ [Sélection manuelle du type d'instance](create-mixed-instances-group-manual-instance-type-selection.md) : choisissez manuellement les types d'instance adaptés à votre charge de travail.
------
#### [ Manual selection ]
Les étapes suivantes expliquent comment créer un groupe d’instances mixtes en choisissant manuellement des types d’instance :
1. Sélectionnez un modèle de lancement contenant les paramètres pour lancer une instance EC2. Les paramètres des modèles de lancement sont facultatifs, mais Amazon EC2 Auto Scaling ne peut pas lancer une instance si l'identifiant amilong ; (AMI) est absent du modèle de lancement.
1. Choisissez l’option pour remplacer le modèle de lancement.
1. Choisissez manuellement les types d’instances adaptés à votre charge de travail.
1. Spécifiez les pourcentages des instances à la demande et des instances Spot à lancer.
1. Choisissez les stratégies d'allocation qui déterminent la façon dont Amazon EC2 Auto Scaling satisfait les capacités à la demande et Spot des types d'instances possibles.
1. Choisissez les zones de disponibilité et les sous-réseaux VPC dans lesquels vous souhaitez lancer vos instances.
1. Indiquez la taille initiale du groupe (la capacité souhaitée), ainsi que la taille minimale et maximale du groupe.
Des remplacements sont nécessaires pour remplacer le type d’instance déclaré dans le modèle de lancement et utiliser plusieurs types d’instances intégrés dans la définition de ressources du groupe Auto Scaling. Pour plus d'informations sur les types d'instances disponibles, consultez la section [Types d'instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) dans le guide de l'*utilisateur Amazon EC2*.
Vous pouvez également configurer les paramètres facultatifs suivants pour chaque type d’instance :
+ `LaunchTemplateSpecification`— Vous pouvez attribuer un modèle de lancement différent à un type d'instance selon vos besoins. Cette option n’est actuellement pas disponible à partir de la console. Pour de plus amples informations, veuillez consulter [Utiliser plusieurs modèles de lancement](ec2-auto-scaling-mixed-instances-groups-launch-template-overrides.md).
+ `WeightedCapacity`— Vous décidez dans quelle mesure l'instance est prise en compte pour la capacité souhaitée par rapport au reste des instances de votre groupe. Si vous spécifiez une valeur `WeightedCapacity` pour un type d’instance, vous devez spécifier une valeur `WeightedCapacity` pour tous les types d’instance. Par défaut, chaque instance compte pour un dans la capacité souhaitée. Pour de plus amples informations, veuillez consulter [Configurer un groupe Auto Scaling pour utiliser les poids d'instance](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md).
------
#### [ Attribute-based selection ]
Pour permettre à Amazon EC2 Auto Scaling de choisir automatiquement vos types d’instances en fonction de leurs attributs d’instance spécifiques, suivez les étapes suivantes pour créer un groupe d’instances mixte en spécifiant vos besoins de calcul :
1. Sélectionnez un modèle de lancement contenant les paramètres pour lancer une instance EC2. Les paramètres des modèles de lancement sont facultatifs, mais Amazon EC2 Auto Scaling ne peut pas lancer une instance si l'identifiant amilong ; (AMI) est absent du modèle de lancement.
1. Choisissez l’option pour remplacer le modèle de lancement.
1. Spécifiez les attributs d'instance qui correspondent à vos besoins de calcul, tels que v CPUs et les exigences en matière de mémoire.
1. Spécifiez les pourcentages des instances à la demande et des instances Spot à lancer.
1. Choisissez les stratégies d'allocation qui déterminent la façon dont Amazon EC2 Auto Scaling satisfait les capacités à la demande et Spot des types d'instances possibles.
1. Choisissez les zones de disponibilité et les sous-réseaux VPC dans lesquels vous souhaitez lancer vos instances.
1. Indiquez la taille initiale du groupe (la capacité souhaitée), ainsi que la taille minimale et maximale du groupe.
Des remplacements sont nécessaires pour remplacer le type d’instance déclaré dans le modèle de lancement et utiliser un ensemble d’attributs d’instance qui décrivent vos exigences de calcul. Pour les attributs pris en charge, consultez [InstanceRequirements](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstanceRequirements.html)le manuel *Amazon EC2 Auto Scaling API Reference*. Vous pouvez également utiliser un modèle de lancement qui contient déjà la définition des attributs d’instance.
Vous pouvez également configurer le paramètre `LaunchTemplateSpecification` dans la structure de remplacement pour attribuer un modèle de lancement différent à un ensemble d’exigences d’instance selon les besoins. Cette option n’est actuellement pas disponible à partir de la console. Pour plus d'informations, consultez le [LaunchTemplateOverrides](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_LaunchTemplateOverrides.html)manuel *Amazon EC2 Auto Scaling API Reference*.
Par défaut, vous définissez le nombre d’instances pour qu’il corresponde à la capacité souhaitée de votre groupe Auto Scaling.
Vous pouvez également définir la valeur de la capacité souhaitée sur le nombre de v CPUs ou sur la quantité de mémoire. Pour ce faire, utilisez la propriété `DesiredCapacityType` dans le fonctionnement de l’API `CreateAutoScalingGroup` ou le champ déroulant **Type de capacité souhaitée** dans la AWS Management Console. Il s’agit d’une alternative utile aux [pondérations d’instance](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md).
------
## Flexibilité du type d’instance
Pour améliorer la disponibilité, déployez votre application sur plusieurs types d’instances. Il est recommandé d’utiliser plusieurs types d’instance pour satisfaire les exigences de capacité. Amazon EC2 Auto Scaling peut ainsi lancer un autre type d'instance si la capacité d'instance est insuffisante dans les zones de disponibilité que vous avez choisies.
Si la capacité des instances Spot est insuffisante, Amazon EC2 Auto Scaling poursuivra ses tentatives de lancement à partir d’autres pools d’instances Spot. (Les pools qu'il utilise sont déterminés par votre choix de types d'instances et de stratégie d'allocation.) Amazon EC2 Auto Scaling vous aide à tirer parti des économies réalisées grâce aux instances Spot en les lançant à la place des instances à la demande.
Nous vous recommandons d’être flexible sur au moins 10 types d’instance pour chaque charge de travail. Lorsque vous choisissez des types d’instance, ne vous limitez pas aux nouveaux types d’instance les plus populaires. Choisir des types d’instance de génération plus ancienne a tendance à entraîner moins d’interruptions Spot, car ils sont moins demandés par les clients à la demande.
## Flexibilité des zones de disponibilité
Nous vous recommandons fortement de répartir votre groupe Auto Scaling sur plusieurs zones de disponibilité. Avec plusieurs zones de disponibilité, vous pouvez concevoir des applications qui basculent automatiquement d’une zone à l’autre pour une plus grande résilience.
L’avantage supplémentaire est que vous pouvez accéder à un groupe de capacités Amazon EC2 plus important par rapport aux groupes d’une seule zone de disponibilité. Dans la mesure où la capacité fluctue en toute indépendance pour chaque type d’instance de chaque zone de disponibilité, il est souvent possible d’obtenir davantage de capacité de calcul lorsque l’on fait preuve de souplesse dans le choix à fois des types d’instances et de zones de disponibilité.
Pour plus d’informations sur l’utilisation des zones de disponibilité multiples, consultez [Exemple : répartir les instances dans les zones de disponibilité](auto-scaling-benefits.md#arch-AutoScalingMultiAZ).
## prix Spot max
Lorsque vous créez votre groupe Auto Scaling à l'aide du SDK AWS CLI ou d'un SDK, vous pouvez spécifier le `SpotMaxPrice` paramètre. Le paramètre `SpotMaxPrice` détermine le prix maximum que vous êtes prêt à payer pour une heure d’instance Spot.
Lorsque vous indiquez le paramètre `WeightedCapacity` dans vos remplacements (ou `"DesiredCapacityType": "vcpu"` ou `"DesiredCapacityType": "memory-mib"` au niveau du groupe), le prix maximum représente le prix unitaire maximum, et non le prix maximum pour une instance complète.
Nous vous recommandons fortement de ne pas indiquer de prix maximum. Votre application peut ne pas fonctionner si vous ne recevez pas d'Instances Spot, par exemple lorsque votre prix maximum est trop bas. Si vous ne spécifiez pas de prix maximum, la valeur par défaut est le prix à la demande. Vous payez uniquement le prix pour les instances Spot que vous lancez. Vous pouvez toujours bénéficier des remises importantes proposées par les instances Spot. Ces remises sont possibles en raison de la tarification stable des instances Spot qui est disponible grâce au [modèle de tarification Spot](https://aws.amazon.com/blogs/compute/new-amazon-ec2-spot-pricing/). Pour plus d'informations, consultez la section [Tarification et économies](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html#spot-pricing) dans le guide de l'*utilisateur Amazon EC2*.
## Rééquilibrage de capacité proactif
Si votre cas d’utilisation le permet, nous vous recommandons un rééquilibrage de la capacité. Le rééquilibrage des capacités vous aide à maintenir la disponibilité de votre charge de travail en remplaçant de manière proactive les instances ponctuelles susceptibles d'être interrompues.
Lorsque le rééquilibrage des capacités est activé, Amazon EC2 Auto Scaling tente de remplacer de manière proactive les instances Spot ayant reçu une recommandation de rééquilibrage des instances EC2. Cela permet de rééquilibrer votre charge de travail vers de nouvelles instances ponctuelles qui ne présentent pas un risque élevé d'interruption.
Pour de plus amples informations, veuillez consulter [Rééquilibrage des capacités dans Auto Scaling pour remplacer les instances ponctuelles à risque](ec2-auto-scaling-capacity-rebalancing.md).
## Comportement de mise à l’échelle.
Lorsque vous créez un groupe d’instances mixtes, il utilise des instances à la demande par défaut. Pour utiliser des instances Spot, vous devez modifier le pourcentage du groupe à lancer en tant qu’instances à la demande. Vous pouvez spécifier n'importe quel nombre compris entre 0 et 100 pour le pourcentage d'instances à la demande.
En option, vous pouvez également désigner un nombre de base d'instances à la demande pour commencer. Si vous procédez de la sorte, Amazon EC2 Auto Scaling attend le lancement des instances Spot jusqu’à ce que la capacité de base soit atteinte lorsque le groupe monte en puissance. Tout dépassement de la capacité de base utilise le pourcentage à la demande pour déterminer le nombre d'instances à la demande et le nombre d'instances ponctuelles à lancer.
Amazon EC2 Auto Scaling convertit le pourcentage en un nombre équivalent d'instances. Si le résultat est un nombre fractionnaire, il est arrondi à l’entier supérieur en faveur des instances à la demande.
Le tableau suivant montre le comportement du groupe Auto Scaling à mesure que la taille du groupe augmente et diminue.
**Exemple : comportement de mise à l'échelle**
| Options d’achat | La taille de groupe et le nombre total d’instances en cours d’exécution, toutes options d’achat confondues |
| --- |--- |
| | **10** | **20** | **30** | **40** |
| --- |--- |--- |--- |--- |
| **Exemple 1** : base de 10, 50/50 % à la demande/Spot | | | | |
| Instances à la demande (montant de base) | 10 | 10 | 10 | 10 |
| On-Demand instances | 0 | 5 | 10 | 15 |
| Instances Spot | 0 | 5 | 10 | 15 |
| **Exemple 2** : base de 0, 0/100 % à la demande/Spot | | | | |
| Instances à la demande (montant de base) | 0 | 0 | 0 | 0 |
| On-Demand instances | 0 | 0 | 0 | 0 |
| Instances Spot | 10 | 20 | 30 | 40 |
| **Exemple 3** : base de 0, 60/40 % à la demande/Spot | | | | |
| Instances à la demande (montant de base) | 0 | 0 | 0 | 0 |
| On-Demand instances | 6 | 12 | 18 | 24 |
| Instances Spot | 4 | 8 | 12 | 16 |
| **Exemple 4** : base de 0, 100/0 % à la demande/Spot | | | | |
| Instances à la demande (montant de base) | 0 | 0 | 0 | 0 |
| On-Demand instances | 10 | 20 | 30 | 40 |
| Instances Spot | 0 | 0 | 0 | 0 |
| **Exemple 5** : base de 12, 0/100 % à la demande/Spot | | | | |
| Instances à la demande (montant de base) | 10 | 12 | 12 | 12 |
| On-Demand instances | 0 | 0 | 0 | 0 |
| Instances Spot | 0 | 8 | 18 | 28 |
Lorsque la taille du groupe *augmente*, Amazon EC2 Auto Scaling tente d’équilibrer votre capacité uniformément entre les zones de disponibilité que vous avez indiquées. Ensuite, il lance des types d'instance en fonction de la stratégie d'allocation qui est spécifiée.
Lorsque la taille du groupe *diminue*, Amazon EC2 Auto Scaling identifie d’abord lequel des deux types (Spot ou à la demande) doit être résilié. Il essaye ensuite de résilier les instances de manière équilibrée dans les zones de disponibilité que vous avez indiquées. Cela favorise également la résiliation des instances d’une manière qui correspond le mieux à vos stratégies d’allocation. Pour plus d’informations sur les politiques de mise hors service, consultez la section [Configurer les politiques de résiliation pour Amazon EC2 Auto Scaling](ec2-auto-scaling-termination-policies.md).
## Disponibilité régionale des types d’instances
La disponibilité des types d'instances EC2 varie en fonction de vos Région AWS besoins. Par exemple, les types d’instance de la nouvelle génération peuvent ne pas encore être disponibles dans une région donnée. En raison des variations de disponibilité des instances d’une région à l’autre, vous pouvez rencontrer des problèmes lorsque vous effectuez des demandes par programmation si plusieurs types d’instances dans vos remplacements ne sont pas disponibles dans votre région. L’utilisation de plusieurs types d’instances qui ne sont pas disponibles dans votre région peut entraîner l’échec total de la demande. Pour résoudre le problème, effectuez de nouveau la demande avec différents types d’instance, en vous assurant que chaque type d’instance est disponible dans la région. Pour rechercher les types d'instances proposés par emplacement, utilisez la [describe-instance-type-offerings](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instance-type-offerings.html)commande. Pour plus d'informations, consultez la section [Trouver un type d'instance Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html) dans le guide de l'utilisateur *Amazon EC2*.
## Ressources connexes
Pour en savoir plus sur les meilleures pratiques relatives aux instances Spot, consultez la section [Meilleures pratiques pour EC2 Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-best-practices.html) dans le guide de l'*utilisateur Amazon EC2*.
## Limitations
Après avoir ajouté des remplacements à un groupe Auto Scaling à l'aide d'une [politique d'instances mixtes](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_MixedInstancesPolicy.html), vous pouvez mettre à jour les remplacements avec l'appel d'`UpdateAutoScalingGroup`API, mais pas les supprimer. Pour supprimer complètement les dérogations, vous devez d'abord changer de groupe Auto Scaling afin d'utiliser un modèle de lancement ou une configuration de lancement au lieu d'une politique d'instances mixtes. Ensuite, vous pouvez à nouveau ajouter une politique d'instances mixtes sans aucune dérogation.
# Stratégies d’allocation pour plusieurs types d’instances
Lorsque vous utilisez plusieurs types d’instance, vous gérez la façon dont Amazon EC2 Auto Scaling satisfait vos capacités à la demande et Spot des types d’instance possibles. Pour ce faire, vous devez définir des stratégies d’allocation.
Pour passer en revue les meilleures pratiques relatives à un groupe d'instances mixtes, consultez[Vue d'ensemble de la configuration pour la création d'un groupe d'instances mixtes](mixed-instances-groups-set-up-overview.md).
**Topics**
+ [Instances Spot](#spot-allocation-strategy)
+ [On-Demand instances](#on-demand-allocation-strategy)
+ [Comment les stratégies d'allocation fonctionnent avec les pondérations](#lowest-price-allocation-strategy)
## Instances Spot
Amazon EC2 Auto Scaling fournit les stratégies d’allocation suivantes pour les instances Spot :
`price-capacity-optimized` (recommandé)
La stratégie d'allocation optimisée en termes de prix et de capacité prend en compte à la fois le prix et la capacité afin de sélectionner les groupes d'instances Spot les moins susceptibles d'être interrompus et dont le prix est le plus bas possible.
Nous vous recommandons cette stratégie lorsque vous débutez. Pour plus d'informations, consultez la section [Présentation de la stratégie price-capacity-optimized d'allocation pour les instances Spot EC2](https://aws.amazon.com/blogs/compute/introducing-price-capacity-optimized-allocation-strategy-for-ec2-spot-instances/) AWS sur le blog.
`capacity-optimized`
Amazon EC2 Auto Scaling sollicite vos instances Spot du pool avec une capacité optimale pour le nombre d'instances qui sont lancées.
Avec les instances Spot, la tarification change lentement au fil du temps en fonction des tendances à long terme en matière d’offre et de demande. Cependant, la capacité fluctue en temps réel. La stratégie `capacity-optimized` lance automatiquement des Instances Spot dans les pools les plus disponibles en examinant les données de capacité en temps réel et en prédisant les instances les plus disponibles. Cela permet de minimiser les interruptions pour les charges de travail de nature à entraîner des coûts plus élevés associés au redémarrage du travail et aux points de contrôle. Pour donner à certains types d'instance une plus grande chance de démarrer en premier, utilisez `capacity-optimized-prioritized`.
`capacity-optimized-prioritized`
Vous définissez l'ordre des types d'instance dans la liste des remplacements de modèle de lancement de la priorité la plus élevée à la plus basse (du premier au dernier de la liste). Amazon EC2 Auto Scaling respecte les priorités relatives aux types d'instances dans la mesure du possible, mais optimise d'abord la capacité. C’est une bonne option pour les charges de travail pour lesquelles la possibilité de perturbation doit être minimisée, mais la priorité de certains types d’instances est également importante. Notez que si la stratégie d'allocation à la demande est définie sur `prioritized`, la même priorité est appliquée lors de l'exécution de la capacité à la demande.
`lowest-price` (non recommandé)
Nous ne recommandons pas `lowest-price` cette stratégie car c'est elle qui présente le risque d'interruption le plus élevé pour vos instances Spot.
Amazon EC2 Auto Scaling sollicite vos instances Spot en utilisant les groupes de prix les plus bas au sein d’une zone de disponibilité, à travers le nombre N de groupes d’instances Spot que vous spécifiez pour le paramètre **Groupes de prix les plus bas**. Par exemple, si vous spécifiez quatre types d'instances et quatre zones de disponibilité, votre groupe Auto Scaling a accès à un maximum de 16 pools d'instances Spot. (Quatre dans chaque zone de disponibilité.) Si vous spécifiez deux pools d'instances Spot (N=2) pour la stratégie d'allocation, votre groupe Auto Scaling peut puiser dans les deux pools les moins chers de chaque zone de disponibilité afin de répondre à votre capacité Spot.
La `lowest-price` stratégie n'est disponible que lorsque vous utilisez le AWS CLI.
Notez qu’Amazon EC2 Auto Scaling s’efforce de puiser les Instances Spot dans le nombre N de groupes que vous spécifiez. Cependant, si un pool manque de capacité Spot pour répondre à la capacité souhaitée, Amazon EC2 Auto Scaling continue à satisfaire la demande en puisant dans le pool le moins cher suivant. Pour atteindre la capacité souhaitée, vous pouvez recevoir des instances Spot de plus de groupes que votre nombre N spécifié. De même, si la majorité des pools ne disposent d'aucune capacité Spot, la totalité de la capacité souhaitée sera peut-être puisée à partir d'un nombre N de groupes inférieur à celui que vous avez spécifié.
**Note**
Si vous configurez vos instances Spot pour qu’elles soient lancées avec [AMD SEV-SNP](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sev-snp.html) activé, des frais d’utilisation horaires supplémentaires vous seront facturés, équivalant à 10 % du [taux horaire à la demande](https://aws.amazon.com/ec2/pricing/on-demand/) du type d’instance sélectionné. Si la stratégie d’allocation utilise le prix comme entrée, Amazon EC2 Auto Scaling n’inclut pas ces frais supplémentaires ; seul le prix Spot est utilisé.
## On-Demand instances
Amazon EC2 Auto Scaling fournit les stratégies d'allocation suivantes pour les instances à la demande :
`lowest-price`
Amazon EC2 Auto Scaling déploie automatiquement le type d'instance le moins cher dans chaque zone de disponibilité en fonction du prix actuel des instances à la demande.
Pour garantir que la capacité souhaitée est atteinte, vous pouvez recevoir des instances à la demande de plus d'un type d'instance dans chaque zone de disponibilité. Cela dépend de la capacité que vous demandez.
`prioritized`
Pour satisfaire la capacité à la demande, Amazon EC2 Auto Scaling détermine quel type d'instance utiliser en premier en se fondant sur les types d’instance dans la liste des remplacements du modèle de lancement. Par exemple, vous avez spécifié trois remplacements de modèle de lancement dans l'ordre suivant : `c5.large`, `c4.large` et `c3.large`. Lors du lancement de vos instances à la demande, le groupe Auto Scaling satisfait la capacité à la demande dans l’ordre suivant : `c5.large`, puis `c4.large`, enfin `c3.large`.
Tenez compte des éléments suivants lorsque vous gérez l'ordre de priorité de vos instances à la demande :
+ Vous pouvez payer votre utilisation à l'avance et bénéficier de réductions importantes sur les instances à la demande en utilisant des Savings Plans ou des instances réservées. Pour plus d'informations, consultez la page [Amazon EC2 pricing](https://aws.amazon.com/ec2/pricing/) (Tarification Amazon EC2).
+ Avec les instances réservées, la réduction par rapport à la tarification standard des instances à la demande s'applique si Amazon EC2 Auto Scaling lance les types d'instances correspondants. Cela signifie que si vous avez des instances réservées inutilisées pour `c4.large`, vous pouvez définir la priorité de vos types d'instance de manière à donner la priorité la plus élevée pour vos instances réservées à un type d'instance `c4.large`. Lorsqu'une instance `c4.large` est lancée, vous recevez la tarification des instances réservées.
+ Avec les Savings Plans, la réduction par rapport à la tarification standard des instances à la demande s'applique lorsque vous utilisez Amazon EC2 Instance Savings Plans ou Compute Savings Plans. Avec Savings Plans, vous bénéficiez d'une plus grande flexibilité lors de la hiérarchisation de vos types d'instances. Tant que vous utilisez des types d'instances couverts par vos Savings Plans, vous pouvez les définir dans n'importe quel ordre de priorité. Vous pouvez également modifier occasionnellement l'ordre complet de vos types d'instances, tout en continuant à bénéficier du tarif réduit Savings Plans. Pour en savoir plus sur les Savings Plans, consultez le [Guide de l’utilisateur des Savings Plans](https://docs.aws.amazon.com/savingsplans/latest/userguide/).
## Comment les stratégies d'allocation fonctionnent avec les pondérations
Lorsque vous spécifiez le `WeightedCapacity` paramètre dans vos overrides (`"DesiredCapacityType": "vcpu"`ou `"DesiredCapacityType": "memory-mib"` au niveau du groupe), les stratégies d'allocation fonctionnent exactement comme elles le font pour les autres groupes Auto Scaling.
Supposons que vous disposiez d'un groupe Auto Scaling avec plusieurs types d'instances contenant des quantités variables de CPUs v. Vous `lowest-price` les utilisez pour vos stratégies d'allocation au comptant et à la demande. Si vous choisissez d'attribuer des pondérations basées sur le nombre de vCPU de chaque type d'instance, Amazon EC2 Auto Scaling lance les types d'instance ayant le prix le plus bas selon les valeurs de pondération que vous avez attribuées (par exemple, par vCPU) au moment de l'exécution. S'il s'agit d'une instance Spot, cela signifie le prix Spot le plus bas par vCPU. S'il s'agit d'une Instance à la demande, cela signifie le prix à la demande le plus bas par vCPU.
Pour de plus amples informations, veuillez consulter [Configurer un groupe Auto Scaling pour utiliser les poids d'instance](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md).
# Création d'un groupe d'instances mixtes à l'aide de la sélection du type d'instance basée sur les attributs
Au lieu de choisir manuellement les types d’instance pour votre groupe d’instances mixtes, vous pouvez spécifier un ensemble d’attributs d’instance qui décrivent vos besoins en calcul. Lorsque Amazon EC2 Auto Scaling lance des instances, tous les types d'instance utilisés par le groupe Auto Scaling doivent correspondre à vos attributs d'instance requis. C'est ce qu'on appelle la *sélection de type d'instance basée sur des attributs*.
Cette approche est idéale pour les charges de travail et les cadres qui peuvent être flexibles quant aux types d'instance qu'ils utilisent, comme les conteneurs, le big data et le CI/CD.
Voici les avantages de la sélection du type d'instance basée sur les attributs :
+ **Flexibilité optimale pour les instances Spot** : Amazon EC2 Auto Scaling peut choisir parmi un large éventail de types d'instances pour le lancement d'instances Spot. Cela répond à la bonne pratique Spot d'être flexible sur les types d'instance, ce qui donne au service Amazon EC2 Spot une meilleure chance de trouver et d'allouer votre quantité requise de capacité de calcul.
+ **Utiliser facilement les bons types d’instances** – Avec autant de types d’instances disponibles, la recherche des types d’instances appropriés pour votre charge de travail peut prendre beaucoup de temps. Lorsque vous spécifiez des attributs d’instance, les types d’instance auront automatiquement les attributs requis pour votre charge de travail.
+ **Utilisation automatique de nouveaux types d'instances** : vos groupes Auto Scaling peuvent utiliser des types d'instances de nouvelle génération au fur et à mesure de leur publication. Les types d'instance de nouvelle génération sont automatiquement utilisés lorsqu'ils correspondent à vos besoins et s'alignent sur les stratégies d'allocation que vous choisissez pour votre groupe Auto Scaling.
**Topics**
+ [Fonctionnement de la sélection de type d’instance basée sur des attributs](#how-attribute-based-instance-type-selection-works)
+ [Protection des prix](#understand-price-protection)
+ [Protection des performances](#understand-performance-protection)
+ [Conditions préalables](#attribute-based-instance-type-selection-prerequisites)
+ [Création d'un groupe d'instances mixtes avec sélection du type d'instance basée sur les attributs (console)](#attribute-based-instance-type-selection-console)
+ [Création d'un groupe d'instances mixtes avec sélection du type d'instance basée sur les attributs ()AWS CLI](#attribute-based-instance-type-selection-aws-cli)
+ [Exemple de configuration](#attribute-based-instance-type-selection-example-configurations)
+ [Prévisualisez vos types d’instance](#attribute-based-instance-type-selection-preview)
+ [Ressources connexes](#attribute-based-instance-type-selection-related-resources)
## Fonctionnement de la sélection de type d’instance basée sur des attributs
Avec la sélection du type d'instance basée sur les attributs, au lieu de fournir une liste de types d'instances spécifiques, vous fournissez une liste des attributs d'instance dont vos instances ont besoin, tels que :
+ **Nombre de vCPU** : nombre minimum et maximum de v CPUs par instance.
+ **Mémoire : mémoire** minimale et maximale GiBs par instance.
+ **Stockage local** – S’il faut utiliser EBS ou des volumes de stockage d’instance pour le stockage local.
+ **Des performances de pointe** – S’il faut utiliser la famille d’instance T, y compris les types T4g, T3a, T3 et T2.
De nombreuses options sont disponibles pour définir les exigences de votre instance. Pour une description de chaque option et des valeurs par défaut, consultez [InstanceRequirements](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstanceRequirements.html)le manuel *Amazon EC2 Auto Scaling API* Reference.
Lorsque votre groupe Auto Scaling doit lancer une instance, il recherche les types d'instances qui correspondent aux attributs que vous avez spécifiés et qui sont disponibles dans cette zone de disponibilité. La stratégie d'allocation détermine ensuite le type d'instance correspondant à lancer. Par défaut, la sélection du type d'instance basée sur les attributs comporte une fonctionnalité de protection des prix activée pour empêcher votre groupe Auto Scaling de lancer des types d'instances dépassant vos seuils budgétaires.
Par défaut, vous utilisez le nombre d'instances comme unité de mesure lorsque vous définissez la capacité souhaitée de votre groupe Auto Scaling, ce qui signifie que chaque instance compte pour une unité.
Vous pouvez également définir la valeur de la capacité souhaitée sur le nombre de v CPUs ou sur la quantité de mémoire. Pour ce faire, utilisez le champ déroulant **Type de capacité souhaité** dans le champ AWS Management Console ou la `DesiredCapacityType` propriété dans l'opération `CreateAutoScalingGroup` ou `UpdateAutoScalingGroup` API. Amazon EC2 Auto Scaling lance ensuite le nombre d'instances nécessaires pour atteindre la capacité de vCPU ou de mémoire souhaitée. Par exemple, si vous utilisez v CPUs comme type de capacité souhaité et que vous utilisez des instances de 2 V CPUs chacune, une capacité souhaitée de 10 V CPUs lancera 5 instances. Il s’agit d’une alternative utile aux [pondérations d’instance](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md).
## Protection des prix
Grâce à la protection des prix, vous pouvez spécifier le prix maximum que vous êtes prêt à payer pour les instances EC2 lancées par votre groupe Auto Scaling. La protection des prix est une fonctionnalité qui empêche votre groupe Auto Scaling d'utiliser des types d'instances que vous jugeriez trop chers, même s'ils correspondent aux attributs que vous avez spécifiés.
La protection des prix est activée par défaut et comporte des seuils de prix distincts pour les instances à la demande et les instances ponctuelles. Lorsqu'Amazon EC2 Auto Scaling doit lancer de nouvelles instances, aucun type d'instance dont le prix est supérieur au seuil pertinent n'est lancé.
**Topics**
+ [Protection des prix à la demande](#on-demand-price-price-protection)
+ [Protection des prix au comptant](#spot-price-price-protection)
+ [Personnalisez la protection des prix](#customize-price-price-protection)
### Protection des prix à la demande
Pour les instances à la demande, vous définissez le prix maximum à la demande que vous êtes prêt à payer sous forme de pourcentage supérieur au prix à la demande identifié. Le prix à la demande identifié est le prix du type d'instance C, M ou R de génération actuelle le moins cher avec les attributs que vous avez spécifiés.
Si une valeur de protection des prix à la demande n'est pas explicitement définie, un prix à la demande maximum par défaut supérieur de 20 % au prix à la demande identifié sera utilisé.
### Protection des prix au comptant
Par défaut, Amazon EC2 Auto Scaling applique automatiquement une protection tarifaire optimale des instances Spot afin de sélectionner de manière cohérente un large éventail de types d'instances. Vous pouvez également définir vous-même la protection des prix manuellement. Toutefois, laisser Amazon EC2 Auto Scaling le faire à votre place peut améliorer les chances que votre capacité Spot soit atteinte.
Vous pouvez spécifier manuellement la protection des prix à l’aide de l’une des solutions suivantes. Si vous définissez manuellement la protection des prix, nous vous recommandons d’utiliser la première option.
+ **Pourcentage d'un *prix à la demande* identifié** : le prix à la demande identifié est le prix du type d'instance C, M ou R de génération actuelle le moins cher avec les attributs que vous avez spécifiés.
+ **Un pourcentage supérieur au *prix spot identifié : le prix*** spot identifié est le prix du type d'instance C, M ou R de génération actuelle le moins cher avec les attributs que vous avez spécifiés. Nous vous déconseillons d'utiliser cette option car les prix au comptant peuvent fluctuer et, par conséquent, votre seuil de protection contre les prix peut également fluctuer.
### Personnalisez la protection des prix
Vous pouvez personnaliser les seuils de protection des prix dans la console Amazon EC2 Auto Scaling ou à l'aide AWS CLI du SDKs ou.
+ Dans la console, utilisez les paramètres de **protection des prix à la demande** et de **protection des prix au comptant** dans **Attributs d'instance supplémentaires**.
+ Dans la [InstanceRequirements](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstanceRequirements.html)structure, pour spécifier le seuil de protection des prix des instances à la demande, utilisez la `OnDemandMaxPricePercentageOverLowestPrice` propriété. Pour spécifier le seuil de protection des prix de l'instance Spot, utilisez la propriété `MaxSpotPriceAsPercentageOfOptimalOnDemandPrice` ou la `SpotMaxPricePercentageOverLowestPrice` propriété.
Si vous définissez le **type de capacité souhaité** (`DesiredCapacityType`) sur **v CPUs** ou sur **Memory GiB**, la protection tarifaire s'applique en fonction du prix par vCPU ou par mémoire plutôt que du prix par instance.
Vous pouvez également désactiver la protection des prix. Pour indiquer qu’il n’y a aucun seuil de protection des prix, spécifiez une valeur de pourcentage élevée, telle que `999999`.
**Note**
Si aucun type d'instance C, M ou R de génération actuelle ne correspond aux attributs que vous avez spécifiés, la protection des prix reste applicable. Si aucune correspondance n'est trouvée, le prix identifié provient des types d'instances de la génération actuelle les moins chers ou, à défaut, des types d'instances de la génération précédente les moins chers, qui correspondent à vos attributs.
## Protection des performances
La *protection des performances* est une fonctionnalité qui garantit que votre groupe Auto Scaling utilise des types d'instances similaires ou supérieurs à une référence de performance spécifiée. Pour utiliser la protection des performances, vous devez spécifier une famille d’instances comme référence de référence. Les capacités de la famille d’instances spécifiée établissent le niveau de performance acceptable le plus bas. Lorsque Auto Scaling sélectionne des types d'instances, il prend en compte les attributs que vous avez spécifiés et la référence de performance. Les types d’instances inférieurs à la référence de performance sont automatiquement exclus de la sélection, même s’ils correspondent aux autres attributs que vous avez spécifiés. Cela garantit que tous les types d’instances sélectionnés offrent des performances similaires ou supérieures à la base de référence établie par la famille d’instances spécifiée. Auto Scaling utilise cette ligne de base pour guider la sélection du type d'instance, mais rien ne garantit que les types d'instance sélectionnés dépasseront toujours la référence pour chaque application.
Actuellement, cette fonctionnalité prend uniquement en charge les performances du processeur en tant que facteur de performance de référence. Les performances du processeur de la famille d'instances spécifiée servent de référence en matière de performances, garantissant que les types d'instances sélectionnés sont similaires ou supérieurs à cette référence. Les familles d’instances dotées des mêmes processeurs produisent les mêmes résultats de filtrage, même si les performances de leur réseau ou de leur disque sont différentes. Par exemple, si vous spécifiez l’une `c6in` ou l’autre `c6i` comme référence de référence, vous obtiendrez des résultats de filtrage basés sur les performances identiques, car les deux familles d’instances utilisent le même processeur CPU.
**Familles d’instances non prises en charge**
Les familles d’instances suivantes ne sont pas prises en charge pour la protection des performances :
+ `c1`
+ `g3` \$1 `g3s`
+ `hpc7g`
+ `m1` \$1 `m2`
+ `mac1` \$1 `mac2` \$1 `mac2-m1ultra` \$1 `mac2-m2` \$1 `mac2-m2pro`
+ `p3dn` \$1 `p4d` \$1 `p5`
+ `t1`
+ `u-12tb1` \$1 `u-18tb1` \$1 `u-24tb1` \$1 `u-3tb1` \$1 `u-6tb1` \$1 `u-9tb1` \$1 `u7i-12tb` \$1 `u7in-16tb` \$1 `u7in-24tb` \$1 `u7in-32tb`
Si vous activez la protection des performances en spécifiant une famille d’instances prise en charge, les types d’instances renvoyés excluront les familles d’instances non prises en charge ci-dessus.
**Exemple : définir une référence de performance du processeur**
Dans l’exemple suivant, l’instance doit être lancée avec des types d’instance dotés de cœurs de processeur aussi performants que la famille d’instances `c6i`. Cela filtrera les types d'instances dotés de processeurs moins performants, même s'ils répondent aux autres exigences d'instance que vous avez spécifiées, telles que le nombre de CPUs v. Par exemple, si les attributs d'instance que vous avez spécifiés incluent 4 V CPUs et 16 Go de mémoire, un type d'instance possédant ces attributs mais présentant des performances du processeur inférieures à celles `c6i` qui sera exclu de la sélection.
```
"BaselinePerformanceFactors": {
"Cpu": {
"References": [
{
"InstanceFamily": "c6i"
}
]
}
```
**Considérations**
Lorsque vous utilisez la protection des performances, tenez compte des points suivants :
+ Vous pouvez spécifier des types d'instance ou des attributs d'instance, mais pas les deux en même temps.
+ Vous pouvez spécifier un maximum de quatre structures `InstanceRequirements` dans une configuration de demande.
## Conditions préalables
+ Créer un modèle de lancement. Pour de plus amples informations, veuillez consulter [Créer un modèle de lancement pour un groupe Auto Scaling](create-launch-template.md).
+ Vérifiez que le modèle de lancement ne demande pas déjà des instances Spot.
## Création d'un groupe d'instances mixtes avec sélection du type d'instance basée sur les attributs (console)
Utilisez la procédure suivante pour créer un groupe d’instances mixtes à l’aide de la sélection de type d’instance basée sur des attributs. Pour vous aider à suivre les étapes de manière efficace, certaines sections facultatives sont ignorées.
Pour la plupart des charges de travail à usage général, il suffit de spécifier le nombre de v CPUs et de mémoire dont vous avez besoin. Pour les cas d'utilisation avancés, vous pouvez spécifier des attributs tels que le type de stockage, les interfaces réseau, le fabricant du CPU et le type d'accélérateur.
Pour consulter les meilleures pratiques relatives à un groupe d'instances mixtes, consultez[Vue d'ensemble de la configuration pour la création d'un groupe d'instances mixtes](mixed-instances-groups-set-up-overview.md).
**Pour créer un groupe d’instances mixtes**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Dans la barre de navigation en haut de l'écran, choisissez la même région Région AWS que celle utilisée lors de la création du modèle de lancement.
1. Choisissez **Create an Auto Scaling group** (Créer un groupe Auto Scaling).
1. Dans la page **Choisir un modèle de lancement ou une configuration**, dans **Nom du groupe Auto Scaling**, entrez un nom pour le groupe Auto Scaling.
1. Pour choisir votre modèle de lancement, procédez comme suit :
1. Dans **Launch template** (Modèle de lancement), choisissez un modèle de lancement existant.
1. Pour **Version du modèle de lancement**, indiquez si le groupe Auto Scaling utilise la version par défaut, la version la plus récente ou une version spécifique du modèle de lancement lors de l'évolutivité horizontale.
1. Vérifiez que votre modèle de lancement prend en charge toutes les options que vous envisagez d'utiliser, puis choisissez **Next** (Suivant).
1. Sur la page **Choisir les options de lancement d’instance**, procédez comme suit :
1. Pour **Instance type requirements** (Exigences en matière de type d'instance), sélectionnez **Override launch template** (Remplacer le modèle de lancement).
**Note**
Si vous avez choisi un modèle de lancement qui contient déjà un ensemble d’attributs d’instance, tels que des vCPU et de la mémoire, les attributs d’instance sont affichés. Ces attributs sont ajoutés aux propriétés du groupe Auto Scaling, que vous pouvez mettre à jour à tout moment sur la console Amazon EC2 Auto Scaling.
1. Sous **Spécifier les attributs de l'instance**, commencez par saisir votre v CPUs et vos besoins en mémoire.
+ Pour **v CPUs**, entrez le nombre minimum et maximum de v souhaitésCPUs. Pour ne définir aucune limite, sélectionnez **Aucun minimum**, **Aucun maximum**, ou les deux.
+ Pour **Memory (GiB)** (Mémoire (Gio)), saisissez la quantité minimale et maximale de mémoire souhaitée. Pour ne spécifier aucune limite, sélectionnez **No minimum** (Pas de minimum), **No maximum** (Pas de maximum), ou les deux.
1. (Facultatif) Pour **Additional instance attributes** (Attributs d’instance supplémentaires), vous pouvez éventuellement spécifier un ou plusieurs attributs pour exprimer vos exigences de calcul plus en détail. Chaque attribut supplémentaire ajoute des contraintes supplémentaires à votre demande.
1. Développez **Aperçu des types d'instances correspondants** pour afficher les types d'instance dotés des attributs que vous avez spécifiés.
1. Dans **Options d’achat d’instance**, pour **Distribution des instances**, spécifiez les pourcentages du groupe à lancer en tant qu’instances à la demande et en tant qu’instances Spot. Si votre application est sans état, tolérante aux pannes et peut gérer l’interruption d’une instance, vous pouvez spécifier un pourcentage plus élevé d’Instances Spot.
1. (Facultatif) Lorsque vous spécifiez un pourcentage pour les instances Spot, sélectionnez **Inclure la capacité de base à la demande**, puis spécifiez la quantité minimale de la capacité initiale du groupe Auto Scaling qui doit être remplie par des instances à la demande. Tout ce qui dépasse la capacité de base utilise les paramètres de **distribution des instances** pour déterminer le nombre d'instances à la demande et d'instances Spot à lancer.
1. Sous **Allocation strategies** (Stratégies d'allocation), le **Lowest price** (Prix le plus bas) est automatiquement sélectionné pour la **On-Demand allocation strategy** (Stratégie d'allocation à la demande) et ne peut pas être modifié.
1. Pour **Spot allocation strategy** (Stratégie d'allocation d'instances Spot), choisissez une stratégie d'allocation. **Price capacity optimized** (Capacité de prix optimisée) est sélectionné par défaut.
1. Dans **Rééquilibrage de la capacité**, choisissez d’activer ou de désactiver le Rééquilibrage de la capacité. Utiliser le rééquilibrage de la capacité pour répondre automatiquement quand vos instances Spot sont sur le point de se résilier à cause d’une interruption des instances Spot. Pour de plus amples informations, veuillez consulter [Rééquilibrage des capacités dans Auto Scaling pour remplacer les instances ponctuelles à risque](ec2-auto-scaling-capacity-rebalancing.md).
1. Sous **Network** (Réseau), pour **VPC**, choisissez un VPC. Le groupe Auto Scaling doit être créé dans le même VPC que le groupe de sécurité que vous avez spécifié dans votre modèle de lancement.
1. Pour **Availability Zones and subnets** (Zones de disponibilité et sous-réseaux), choisissez un ou plusieurs sous-réseaux dans le VPC spécifié. Utilisez les sous-réseaux dans plusieurs zones de disponibilité pour une haute disponibilité. Pour de plus amples informations, veuillez consulter [Considérations à prendre en compte lors du choix des sous-réseaux VPC](asg-in-vpc.md#as-vpc-considerations).
1. Appuyez sur **Suivant**, **Suivant**.
1. Pour l'étape **Configure group size and scaling policies** (Configurer la taille du groupe et les politiques de mise à l'échelle), procédez comme suit :
1. Si vous voulez que la capacité souhaitée soit mesurée en unités autres que des instances, choisissez l’option appropriée pour **Taille du groupe** et **Type de capacité souhaité**. **Les unités**CPUs, **v** et les **GiB de mémoire** sont pris en charge. Par défaut, Amazon EC2 Auto Scaling spécifie **Units** (Unités), ce qui se traduit par le nombre d'instances.
1. Définissez la **capacité souhaitée** en fonction de la taille initiale de votre groupe Auto Scaling.
1. Dans la section **Mise à l’échelle**, sous **Limites de mise à l’échelle**, si votre nouvelle valeur pour la **capacité souhaitée** est supérieure à la **capacité minimale souhaitée** et à la **capacité maximale souhaitée**, la **capacité maximale souhaitée** est automatiquement augmentée à la nouvelle valeur de capacité souhaitée. Vous pouvez modifier ces limites si nécessaire. Pour de plus amples informations, veuillez consulter [Définissez des limites de mise à l’échelle pour votre groupe Auto Scaling](asg-capacity-limits.md).
1. Choisissez **Skip to review** (Passer à la révision).
1. Sur la page **Vérifier**, sélectionnez **Créer un groupe Auto Scaling**.
## Création d'un groupe d'instances mixtes avec sélection du type d'instance basée sur les attributs ()AWS CLI
**Pour créer un groupe d’instances mixtes avec la ligne de commande**
Utilisez l’une des commandes suivantes :
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) (AWS CLI)
+ [Nouveau- ASAuto ScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
## Exemple de configuration
Pour créer un groupe Auto Scaling avec sélection du type d'instance basée sur les attributs à l'aide de AWS CLI, utilisez la commande suivante [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html).
Les attributs d'instance suivants sont spécifiés :
+ `VCpuCount`— Les types d'instance doivent avoir un minimum de quatre v CPUs et un maximum de huit CPUs v.
+ `MemoryMiB` : les types d'instance doivent avoir un minimum de 16 384 Mio de mémoire.
+ `CpuManufacturers` : les types d'instance doivent avoir un processeur fabriqué par Intel.
### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
Voici un exemple de fichier `config.json`.
```
{
"AutoScalingGroupName": "my-asg",
"DesiredCapacityType": "units",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Default"
},
"Overrides": [{
"InstanceRequirements": {
"VCpuCount": {"Min": 4, "Max": 8},
"MemoryMiB": {"Min": 16384},
"CpuManufacturers": ["intel"]
}
}]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 50,
"SpotAllocationStrategy": "price-capacity-optimized"
}
},
"MinSize": 0,
"MaxSize": 100,
"DesiredCapacity": 4,
"DesiredCapacityType": "units",
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
Pour définir la valeur de la capacité souhaitée sous la forme du nombre de v CPUs ou de la quantité de mémoire, spécifiez `"DesiredCapacityType": "vcpu"` ou `"DesiredCapacityType": "memory-mib"` dans le fichier. Le type de capacité souhaitée par défaut est `units`, qui définit la valeur de la capacité souhaitée comme le nombre d'instances.
### YAML
Vous pouvez également utiliser la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande suivante pour créer le groupe Auto Scaling. Cela fait référence à un fichier YAML comme seul paramètre de votre groupe Auto Scaling.
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
Voici un exemple de fichier `config.yaml`.
```
---
AutoScalingGroupName: my-asg
DesiredCapacityType: units
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceRequirements:
VCpuCount:
Min: 2
Max: 4
MemoryMiB:
Min: 2048
CpuManufacturers:
- intel
InstancesDistribution:
OnDemandPercentageAboveBaseCapacity: 50
SpotAllocationStrategy: price-capacity-optimized
MinSize: 0
MaxSize: 100
DesiredCapacity: 4
DesiredCapacityType: units
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
Pour définir la valeur de la capacité souhaitée sous la forme du nombre de v CPUs ou de la quantité de mémoire, spécifiez `DesiredCapacityType: vcpu` ou `DesiredCapacityType: memory-mib` dans le fichier. Le type de capacité souhaitée par défaut est `units`, qui définit la valeur de la capacité souhaitée comme le nombre d'instances.
Pour un exemple d'utilisation de plusieurs modèles de lancement avec une sélection de type d'instance basée sur les attributs, consultez. [Utiliser plusieurs modèles de lancement](ec2-auto-scaling-mixed-instances-groups-launch-template-overrides.md)
## Prévisualisez vos types d’instance
Vous pouvez prévisualiser les types d'instance qui correspondent à vos besoins de calcul sans les lancer et ajuster vos besoins si nécessaire. Lors de la création de votre groupe Auto Scaling dans la console Amazon EC2 Auto Scaling, une prévisualisation des types d'instance apparaît dans la section **Preview matching instance types** (Prévisualisation des types d'instance correspondants) sur la page **Choose instance launch options** (Choisir des options de lancement d'instance).
Vous pouvez également prévisualiser les types d'instances en effectuant un appel d'[GetInstanceTypesFromInstanceRequirements](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_GetInstanceTypesFromInstanceRequirements.html)API Amazon EC2 à l'aide du AWS CLI ou d'un SDK. Passez les paramètres `InstanceRequirements` dans la demande dans le format exact que vous utiliseriez pour créer ou mettre à jour un groupe Auto Scaling. Pour plus d'informations, consultez la section [Aperçu des types d'instances avec des attributs spécifiés](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-attribute-based-instance-type-selection.html#ec2fleet-get-instance-types-from-instance-requirements) dans le guide de l'*utilisateur Amazon EC2*.
## Ressources connexes
Pour en savoir plus sur la sélection du type d'instance basée sur les attributs, consultez la section Sélection du type d'[instance basée sur les attributs pour EC2 Auto Scaling et EC2 Fleet sur le blog](https://aws.amazon.com/blogs/aws/new-attribute-based-instance-type-selection-for-ec2-auto-scaling-and-ec2-fleet/). AWS
Vous pouvez déclarer une sélection de type d’instance basée sur les attributs lorsque vous créez un groupe Auto Scaling avec CloudFormation. Pour plus d’informations, consultez l’exemple d’extrait dans la section [Extraits de modèle de mise à l’échelle automatique](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-autoscaling.html#scenario-mixed-instances-group-template-examples) du *Guide de l’utilisateur CloudFormation *.
# Créer un groupe d’instances mixtes en choisissant manuellement les types d’instances
Cette rubrique explique comment lancer plusieurs types d’instances dans un seul groupe Auto Scaling en choisissant manuellement vos types d’instances.
Si vous préférez utiliser des attributs d’instance comme critères de sélection des types d’instance, consultez [Création d'un groupe d'instances mixtes à l'aide de la sélection du type d'instance basée sur les attributs](create-mixed-instances-group-attribute-based-instance-type-selection.md).
**Topics**
+ [Conditions préalables](#manual-instance-type-selection-prerequisites)
+ [Créer un groupe d’instances mixtes (console)](#manual-instance-type-selection-console)
+ [Créer un groupe d’instances mixtes (AWS CLI)](#manual-instance-type-selection-aws-cli)
+ [Exemples de configuration](#manual-instance-type-selection-example-configurations)
## Conditions préalables
+ Créer un modèle de lancement. Pour de plus amples informations, veuillez consulter [Créer un modèle de lancement pour un groupe Auto Scaling](create-launch-template.md).
+ Vérifiez que le modèle de lancement ne demande pas déjà des instances Spot.
## Créer un groupe d’instances mixtes (console)
Utilisez la procédure suivante pour créer un groupe d’instances mixtes en choisissant manuellement les types d’instance que votre groupe peut lancer. Pour vous aider à suivre les étapes de manière efficace, certaines sections facultatives sont ignorées.
Pour passer en revue les meilleures pratiques relatives à un groupe d'instances mixtes, consultez[Vue d'ensemble de la configuration pour la création d'un groupe d'instances mixtes](mixed-instances-groups-set-up-overview.md).
**Pour créer un groupe d’instances mixtes**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Dans la barre de navigation en haut de l'écran, choisissez la même région Région AWS que celle utilisée lors de la création du modèle de lancement.
1. Choisissez **Create an Auto Scaling group** (Créer un groupe Auto Scaling).
1. Dans la page **Choisir un modèle de lancement ou une configuration**, dans **Nom du groupe Auto Scaling**, entrez un nom pour le groupe Auto Scaling.
1. Pour choisir votre modèle de lancement, procédez comme suit :
1. Dans **Launch template** (Modèle de lancement), choisissez un modèle de lancement existant.
1. Pour **Version du modèle de lancement**, indiquez si le groupe Auto Scaling utilise la version par défaut, la version la plus récente ou une version spécifique du modèle de lancement lors de l'évolutivité horizontale.
1. Vérifiez que votre modèle de lancement prend en charge toutes les options que vous envisagez d'utiliser, puis choisissez **Next** (Suivant).
1. Sur la page **Choisir les options de lancement d’instance**, procédez comme suit :
1. Pour les **Exigences relatives au type d'instance**, choisissez **Override launch template** (Remplacer le modèle de lancement), puis **Manually add instance types** (Ajouter manuellement les types d'instance).
1. Choisissez vos types d'instance. Vous pouvez utiliser nos recommandations comme point de départ. **Family and generation flexible** (Famille et génération flexibles) est sélectionnée par défaut.
+ (Facultatif) Pour modifier l'ordre des types d'instances, utilisez les flèches. Si vous choisissez une stratégie d'allocation qui prend en charge la priorisation, l'ordre des types d'instance définit leur priorité de lancement.
+ Pour supprimer un type d'instance, choisissez **X**.
+ (Facultatif) Pour les cases de la colonne **Poids**, attribuez une pondération relative à chaque type d’instance. Pour ce faire, entrez le nombre d'unités qu'une instance de ce type compte par rapport à la capacité souhaitée du groupe. Cela peut s'avérer notamment utile si les types d'instance offrent des capacités différentes de vCPU, de mémoire, de stockage ou de bande passante du réseau. Pour de plus amples informations, veuillez consulter [Configurer un groupe Auto Scaling pour utiliser les poids d'instance](ec2-auto-scaling-mixed-instances-groups-instance-weighting.md).
Notez que si vous choisissez d’utiliser les recommandations de **Taille flexible**, tous les types d’instance qui font partie de cette section ont automatiquement une valeur de pondération. Si vous ne souhaitez pas spécifier de pondération, décochez les cases de la colonne **Weight** (Poids) pour tous les types d'instances.
1. Dans **Instance purchase options** (Options d'achat d'instance), pour **Instance distribution** (Distribution des instances), spécifiez les pourcentages du groupe à lancer en tant qu'instances à la demande et en tant qu'instances Spot, respectivement. Si votre application est sans état, tolérante aux pannes et peut gérer l’interruption d’une instance, vous pouvez spécifier un pourcentage plus élevé d’Instances Spot.
1. (Facultatif) Lorsque vous spécifiez un pourcentage pour les instances Spot, sélectionnez **Inclure la capacité de base à la demande**, puis spécifiez la quantité minimale de la capacité initiale du groupe Auto Scaling qui doit être remplie par des instances à la demande. Tout ce qui dépasse la capacité de base utilise les paramètres de **distribution des instances** pour déterminer le nombre d'instances à la demande et d'instances Spot à lancer.
1. Sous **Allocation strategies** (Stratégies d'allocation), pour **On-Demand allocation strategy** (Stratégie d'allocation à la demande), choisissez une stratégie d'allocation. Lorsque vous choisissez manuellement vos types d'instances, **Prioritized** (Priorisé) est sélectionné par défaut.
1. Pour **Spot allocation strategy** (Stratégie d'allocation d'instances Spot), choisissez une stratégie d'allocation. **Price capacity optimized** (Capacité de prix optimisée) est sélectionné par défaut.
Si vous choisissez **Capacité optimisée**, vous pouvez éventuellement cocher la case **Prioriser les types d’instances** pour permettre à Amazon EC2 Auto Scaling de choisir le type d’instance à lancer en premier en fonction de l’ordre dans lequel vos types d’instances sont répertoriés.
1. Dans **Rééquilibrage de la capacité**, choisissez d’activer ou de désactiver le Rééquilibrage de la capacité. Utiliser le rééquilibrage de la capacité pour répondre automatiquement quand vos instances Spot sont sur le point de se résilier à cause d’une interruption des instances Spot. Pour de plus amples informations, veuillez consulter [Rééquilibrage des capacités dans Auto Scaling pour remplacer les instances ponctuelles à risque](ec2-auto-scaling-capacity-rebalancing.md).
1. Sous **Network** (Réseau), pour **VPC**, choisissez un VPC. Le groupe Auto Scaling doit être créé dans le même VPC que le groupe de sécurité que vous avez spécifié dans votre modèle de lancement.
1. Pour **Availability Zones and subnets** (Zones de disponibilité et sous-réseaux), choisissez un ou plusieurs sous-réseaux dans le VPC spécifié. Utilisez les sous-réseaux dans plusieurs zones de disponibilité pour une haute disponibilité. Pour de plus amples informations, veuillez consulter [Considérations à prendre en compte lors du choix des sous-réseaux VPC](asg-in-vpc.md#as-vpc-considerations).
1. Appuyez sur **Suivant**, **Suivant**.
1. Pour l'étape **Configure group size and scaling policies** (Configurer la taille du groupe et les politiques de mise à l'échelle), procédez comme suit :
1. Dans **Taille du groupe**, pour la **Capacité souhaitée**, entrez le nombre initial d’instances à lancer.
Par défaut, la capacité souhaitée est exprimée en nombre d’instances. Si vous avez attribué des poids à vos types d'instances, vous devez convertir cette valeur dans la même unité de mesure que celle que vous avez utilisée pour attribuer des poids, telle que le nombre de CPUs v.
1. Dans la section **Mise à l’échelle**, sous **Limites de mise à l’échelle**, si votre nouvelle valeur pour la **capacité souhaitée** est supérieure à la **capacité minimale souhaitée** et à la **capacité maximale souhaitée**, la **capacité maximale souhaitée** est automatiquement augmentée à la nouvelle valeur de capacité souhaitée. Vous pouvez modifier ces limites si nécessaire. Pour de plus amples informations, veuillez consulter [Définissez des limites de mise à l’échelle pour votre groupe Auto Scaling](asg-capacity-limits.md).
1. Choisissez **Skip to review** (Passer à la révision).
1. Sur la page **Vérifier**, sélectionnez **Créer un groupe Auto Scaling**.
## Créer un groupe d’instances mixtes (AWS CLI)
**Pour créer un groupe d’instances mixtes avec la ligne de commande**
Utilisez l’une des commandes suivantes :
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) (AWS CLI)
+ [Nouveau- ASAuto ScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
## Exemples de configuration
Les exemples de configuration suivants montrent comment créer des instances mixtes à l’aide des différentes stratégies d’allocation Spot.
**Note**
Ces exemples montrent comment utiliser un fichier de configuration au format JSON ou YAML. Si vous utilisez AWS CLI la version 1, vous devez spécifier un fichier de configuration au format JSON. Si vous utilisez AWS CLI la version 2, vous pouvez spécifier un fichier de configuration au format YAML ou JSON.
**Topics**
+ [Exemple 1 : lancer des instances Spot à l'aide de la stratégie d'allocation `capacity-optimized`](#capacity-optimized-aws-cli)
+ [Exemple 2 : lancer des instances Spot à l'aide de la stratégie d'allocation `capacity-optimized-prioritized`](#capacity-optimized-prioritized-aws-cli)
+ [Exemple 3 : lancer des instances Spot à l'aide de la stratégie d'allocation `lowest-price` diversifiée sur deux pools](#lowest-price-aws-cli)
+ [Exemple 4 : Lancer instances Spot à l’aide de la stratégie d’allocation `price-capacity-optimized`](#price-capacity-optimized-aws-cli)
### Exemple 1 : lancer des instances Spot à l'aide de la stratégie d'allocation `capacity-optimized`
La [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande suivante crée un groupe Auto Scaling qui spécifie les éléments suivants :
+ Pourcentage du groupe à lancer en tant qu'instances à la demande (`0`) et nombre de base d'instances à la demande (`1`)
+ Types d'instance à lancer par ordre de priorité (`c5.large`, `c5a.large`, `m5.large`, `m5a.large`, `c4.large`, `m4.large`, `c3.large`, `m3.large`)
+ Les sous-réseaux dans lesquels lancer les instances (`subnet-5ea0c127`, `subnet-6194ea3b`, `subnet-c934b782`) Chacun d'eux correspond à une zone de disponibilité différente.
+ Modèle de lancement (`my-launch-template`) et version du modèle de lancement (`$Default`)
Lorsqu'Amazon EC2 Auto Scaling tente de satisfaire votre capacité à la demande, il lance d'abord le type d'instance `c5.large`. Les instances Spot proviennent du pool d'instances Spot optimal de chaque zone de disponibilité en fonction de la capacité d'instances Spot.
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
Le fichier `config.json` contient le contenu suivant.
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Default"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandBaseCapacity": 1,
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "capacity-optimized"
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
Vous pouvez également utiliser la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande suivante pour créer le groupe Auto Scaling. Cela fait référence à un fichier YAML comme seul paramètre de votre groupe Auto Scaling.
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
Le fichier `config.yaml` contient le contenu suivant.
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandBaseCapacity: 1
OnDemandPercentageAboveBaseCapacity: 0
SpotAllocationStrategy: capacity-optimized
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
### Exemple 2 : lancer des instances Spot à l'aide de la stratégie d'allocation `capacity-optimized-prioritized`
La [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande suivante crée un groupe Auto Scaling qui spécifie les éléments suivants :
+ Pourcentage du groupe à lancer en tant qu'instances à la demande (`0`) et nombre de base d'instances à la demande (`1`)
+ Types d'instance à lancer par ordre de priorité (`c5.large`, `c5a.large`, `m5.large`, `m5a.large`, `c4.large`, `m4.large`, `c3.large`, `m3.large`)
+ Les sous-réseaux dans lesquels lancer les instances (`subnet-5ea0c127`, `subnet-6194ea3b`, `subnet-c934b782`) Chacun d'eux correspond à une zone de disponibilité différente.
+ Modèle de lancement (`my-launch-template`) et version du modèle de lancement (`$Latest`)
Lorsqu'Amazon EC2 Auto Scaling tente de satisfaire votre capacité à la demande, il lance d'abord le type d'instance `c5.large`. Lorsqu'Amazon EC2 Auto Scaling tente de satisfaire votre capacité Spot, il implémente au mieux les priorités relatives aux types d'instances sur la base du meilleur effort. Cependant, il optimise d'abord la capacité.
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
Le fichier `config.json` contient le contenu suivant.
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandBaseCapacity": 1,
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "capacity-optimized-prioritized"
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
Vous pouvez également utiliser la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande suivante pour créer le groupe Auto Scaling. Cela fait référence à un fichier YAML comme seul paramètre de votre groupe Auto Scaling.
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
Le fichier `config.yaml` contient le contenu suivant.
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandBaseCapacity: 1
OnDemandPercentageAboveBaseCapacity: 0
SpotAllocationStrategy: capacity-optimized-prioritized
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
### Exemple 3 : lancer des instances Spot à l'aide de la stratégie d'allocation `lowest-price` diversifiée sur deux pools
La [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande suivante crée un groupe Auto Scaling qui spécifie les éléments suivants :
+ Pourcentage du groupe à lancer en tant qu'instances à la demande (`50`). (Cela ne spécifie pas de nombre de base d'instances à la demande pour commencer.)
+ Types d'instance à lancer par ordre de priorité (`c5.large`, `c5a.large`, `m5.large`, `m5a.large`, `c4.large`, `m4.large`, `c3.large`, `m3.large`)
+ Les sous-réseaux dans lesquels lancer les instances (`subnet-5ea0c127`, `subnet-6194ea3b`, `subnet-c934b782`) Chacun d'eux correspond à une zone de disponibilité différente.
+ Modèle de lancement (`my-launch-template`) et version du modèle de lancement (`$Latest`)
Lorsqu'Amazon EC2 Auto Scaling tente de satisfaire votre capacité à la demande, il lance d'abord le type d'instance `c5.large`. Pour votre capacité Spot, Amazon EC2 Auto Scaling tente de lancer les instances Spot uniformément sur les deux pools les moins chers de chaque zone de disponibilité.
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
Le fichier `config.json` contient le contenu suivant.
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 50,
"SpotAllocationStrategy": "lowest-price",
"SpotInstancePools": 2
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
Vous pouvez également utiliser la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande suivante pour créer le groupe Auto Scaling. Cela fait référence à un fichier YAML comme seul paramètre de votre groupe Auto Scaling.
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
Le fichier `config.yaml` contient le contenu suivant.
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandPercentageAboveBaseCapacity: 50
SpotAllocationStrategy: lowest-price
SpotInstancePools: 2
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
### Exemple 4 : Lancer instances Spot à l’aide de la stratégie d’allocation `price-capacity-optimized`
La [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande suivante crée un groupe Auto Scaling qui spécifie les éléments suivants :
+ Pourcentage du groupe à lancer en tant qu'instances à la demande (`30`). (Cela ne spécifie pas de nombre de base d'instances à la demande pour commencer.)
+ Types d'instance à lancer par ordre de priorité (`c5.large`, `c5a.large`, `m5.large`, `m5a.large`, `c4.large`, `m4.large`, `c3.large`, `m3.large`)
+ Les sous-réseaux dans lesquels lancer les instances (`subnet-5ea0c127`, `subnet-6194ea3b`, `subnet-c934b782`) Chacun d'eux correspond à une zone de disponibilité différente.
+ Modèle de lancement (`my-launch-template`) et version du modèle de lancement (`$Latest`)
Lorsqu'Amazon EC2 Auto Scaling tente de satisfaire votre capacité à la demande, il lance d'abord le type d'instance `c5.large`. Pour votre capacité Spot, Amazon EC2 Auto Scaling tente de lancer les instances Spot à partir des groupes d’instances Spot au prix le plus bas possible, mais également avec une capacité optimale pour le nombre d’instances que vous lancez.
#### JSON
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
Le fichier `config.json` contient le contenu suivant.
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "c5.large"
},
{
"InstanceType": "c5a.large"
},
{
"InstanceType": "m5.large"
},
{
"InstanceType": "m5a.large"
},
{
"InstanceType": "c4.large"
},
{
"InstanceType": "m4.large"
},
{
"InstanceType": "c3.large"
},
{
"InstanceType": "m3.large"
}
]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 30,
"SpotAllocationStrategy": "price-capacity-optimized"
}
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 3,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782"
}
```
#### YAML
Vous pouvez également utiliser la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande suivante pour créer le groupe Auto Scaling. Cela fait référence à un fichier YAML comme seul paramètre de votre groupe Auto Scaling.
```
aws autoscaling create-auto-scaling-group --cli-input-yaml file://~/config.yaml
```
Le fichier `config.yaml` contient le contenu suivant.
```
---
AutoScalingGroupName: my-asg
MixedInstancesPolicy:
LaunchTemplate:
LaunchTemplateSpecification:
LaunchTemplateName: my-launch-template
Version: $Default
Overrides:
- InstanceType: c5.large
- InstanceType: c5a.large
- InstanceType: m5.large
- InstanceType: m5a.large
- InstanceType: c4.large
- InstanceType: m4.large
- InstanceType: c3.large
- InstanceType: m3.large
InstancesDistribution:
OnDemandPercentageAboveBaseCapacity: 30
SpotAllocationStrategy: price-capacity-optimized
MinSize: 1
MaxSize: 5
DesiredCapacity: 3
VPCZoneIdentifier: subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782
```
# Configurer un groupe Auto Scaling pour utiliser les poids d'instance
Lorsque vous utilisez plusieurs types d'instances, vous pouvez spécifier le nombre d'unités à associer à chaque type d'instance, puis spécifier la capacité de votre groupe avec la même unité de mesure. Cette option de spécification de capacité est connue sous le nom de poids.
Supposons, par exemple, que vous exécutiez une application gourmande en ressources informatiques qui fonctionne le mieux avec au moins 8 V CPUs et 15 GiB de RAM. Si vous utilisez `c5.2xlarge` comme unité de base, l'un des types d'instance EC2 suivants répondrait aux besoins de votre application.
**Exemple de types d'instances**
| Type d’instance | vCPU | Mémoire (Gio) |
| --- | --- | --- |
| c5.2xlarge | 8 | 16 |
| c5.4xlarge | 16 | 32 |
| c5.12xlarge | 48 | 96 |
| c5.18xlarge | 72 | 144 |
| c5.24xlarge | 96 | 192 |
Par défaut, tous les types d’instances ont le même poids, quelle que soit leur taille. En d’autres termes, quelle que soit la taille du type d’instance lancé par Amazon EC2 Auto Scaling, chaque instance est comptabilisée de la même façon dans la capacité souhaitée du groupe Auto Scaling.
Cependant, avec les pondérations, vous attribuez une valeur numérique qui indique le nombre d'unités à associer à chaque type d'instance. Par exemple, si les instances sont de tailles différentes, une instance `c5.2xlarge` peut avoir un poids de 2, et une `c5.4xlarge` (qui est deux fois plus grande) peut avoir un poids de 4, et ainsi de suite. Ensuite, lorsqu’Amazon EC2 Auto Scaling redimensionne le groupe, ces pondérations se traduisent par le nombre d’unités que chaque instance compte pour votre capacité souhaitée.
Les pondérations ne changent pas les types d’instance qu’Amazon EC2 Auto Scaling choisit de lancer ; ce choix revient aux stratégies d’allocation. Pour de plus amples informations, veuillez consulter [Stratégies d’allocation pour plusieurs types d’instances](allocation-strategies.md).
**Important**
Pour configurer un groupe Auto Scaling afin qu'il atteigne la capacité souhaitée en utilisant le nombre de v CPUs ou la quantité de mémoire de chaque type d'instance, nous vous recommandons d'utiliser la sélection du type d'instance basée sur les attributs. La définition du `DesiredCapacityType` paramètre indique automatiquement le nombre d'unités à associer à chaque type d'instance en fonction de la valeur que vous avez définie pour ce paramètre. Pour de plus amples informations, veuillez consulter [Création d'un groupe d'instances mixtes à l'aide de la sélection du type d'instance basée sur les attributs](create-mixed-instances-group-attribute-based-instance-type-selection.md).
**Topics**
+ [Considérations](#weights-considerations)
+ [Comportements de poids des instances](#instance-weighting-behaviors)
+ [Configurer un groupe Auto Scaling pour utiliser des pondérations](configue-auto-scaling-group-to-use-weights.md)
+ [Exemple de prix Spot par heure d’unité](weights-spot-price-per-unit-hour-example.md)
## Considérations
Cette section aborde les principales considérations relatives à la mise en œuvre efficace des pondérations.
+ Choisissez quelques types d'instances qui répondent aux besoins de performance de votre application. Déterminez le poids que chaque type d'instance doit prendre en compte dans la capacité souhaitée de votre groupe Auto Scaling en fonction de ses capacités. Ces pondérations s'appliquent aux instances actuelles et futures.
+ Évitez les grandes plages de poids. Par exemple, ne spécifiez pas un poids de 1 pour un type d'instance lorsque le type d'instance le plus important suivant a un poids de 200. La différence entre les pondérations des plus petites et des plus grandes ne doit pas non plus être extrême. Les différences de poids extrêmes peuvent avoir un impact négatif sur l'optimisation des coûts et des performances.
+ Spécifiez la capacité souhaitée du groupe en unités et non en instances. Par exemple, si vous utilisez des pondérations basées sur le processeur virtuel, définissez le nombre de cœurs souhaité ainsi que le minimum et le maximum.
+ Définissez vos pondérations et la capacité souhaitée de sorte que cette dernière soit au moins deux à trois fois supérieure à votre pondération la plus importante.
Lorsque vous mettez à jour des groupes existants, tenez compte des points suivants :
+ Lorsque vous ajoutez des pondérations à un groupe existant, incluez des pondérations pour tous les types d'instances actuellement utilisés.
+ Lorsque vous ajoutez ou modifiez des poids, Amazon EC2 Auto Scaling lance ou arrête des instances pour atteindre la capacité souhaitée en fonction des nouvelles valeurs de pondération.
+ Si vous supprimez un type d'instance, les instances de ce type en cours d'exécution conservent leur dernier poids, même si elles ne sont plus définies.
## Comportements de poids des instances
Lorsque vous utilisez des pondérations d’instance, Amazon EC2 Auto Scaling se comporte de la manière suivante :
+ La capacité actuelle sera soit à la capacité désirée, soit au-dessus. La capacité actuelle peut dépasser la capacité souhaitée si les instances lancées dépassent les unités de capacité souhaitées restantes. Supposons que vous spécifiez deux types d'instance `c5.2xlarge` et `c5.12xlarge`, et que vous affectez des pondérations d'instance de 2 pour `c5.2xlarge` et de 12 pour `c5.12xlarge`. S’il reste cinq unités pour satisfaire la capacité souhaitée, et qu’Amazon EC2 Auto Scaling approvisionne une instance `c5.12xlarge`, la capacité souhaitée est dépassée de sept unités.
+ Lors du lancement d'instances, Amazon EC2 Auto Scaling donne la priorité à la distribution de la capacité entre les zones de disponibilité et au respect des stratégies d'allocation plutôt qu'au dépassement de la capacité souhaitée.
+ Amazon EC2 Auto Scaling peut dépasser la limite de capacité maximale afin de maintenir l'équilibre entre les zones de disponibilité, en utilisant vos stratégies d'allocation préférées. La limite stricte imposée par Amazon EC2 Auto Scaling est la capacité souhaitée plus votre poids le plus élevé.
# Configurer un groupe Auto Scaling pour utiliser des pondérations
Vous pouvez configurer un groupe Auto Scaling afin d’utiliser des pondérations, comme indiqué dans les exemples AWS CLI suivants. Pour des instructions sur l'utilisation de la console, consultez [Créer un groupe d’instances mixtes en choisissant manuellement les types d’instances](create-mixed-instances-group-manual-instance-type-selection.md).
**Pour configurer un nouveau groupe Auto Scaling afin d’utiliser des pondérations (AWS CLI)**
Utilisez la commande [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html). Par exemple, la commande suivante crée un nouveau groupe Auto Scaling et attribue des pondérations en spécifiant ce qui suit :
+ Pourcentage du groupe à lancer en tant qu'instances à la demande (`0`)
+ Stratégie d'allocation des instances Spot dans chaque zone de disponibilité (`capacity-optimized`)
+ Types d'instance à lancer par ordre de priorité (`m4.16xlarge`, `m5.24xlarge`)
+ Les poids d'instance qui correspondent à la différence de taille relative (vCPUs) entre les types d'instance (`16`,`24`)
+ Sous-réseaux dans lesquels lancer les instances (`subnet-5ea0c127`, `subnet-6194ea3b`, `subnet-c934b782`) chacun correspondant à une zone de disponibilité différente
+ Modèle de lancement (`my-launch-template`) et version du modèle de lancement (`$Latest`)
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
Le fichier `config.json` contient le contenu suivant.
```
{
"AutoScalingGroupName": "my-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"Overrides": [
{
"InstanceType": "m4.16xlarge",
"WeightedCapacity": "16"
},
{
"InstanceType": "m5.24xlarge",
"WeightedCapacity": "24"
}
]
},
"InstancesDistribution": {
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "capacity-optimized"
}
},
"MinSize": 160,
"MaxSize": 720,
"DesiredCapacity": 480,
"VPCZoneIdentifier": "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782",
"Tags": []
}
```
**Pour configurer un groupe Auto Scaling existant afin d’utiliser des pondérations (AWS CLI)**
Utilisez la commande [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html). Par exemple, la commande suivante attribue des pondérations aux types d’instances d’un groupe Auto Scaling existant en spécifiant ce qui suit :
+ Types d'instance à lancer par ordre de priorité (`c5.18xlarge`, `c5.24xlarge`, `c5.2xlarge`, `c5.4xlarge`)
+ Les poids d'instance qui correspondent à la différence de taille relative (vCPUs) entre les types d'instances (`18`,`24`,`2`,`4`)
+ Le nouveau, augmentation de la capacité désirée, qui est plus important que le pondération la plus importante
```
aws autoscaling update-auto-scaling-group --cli-input-json file://~/config.json
```
Le fichier `config.json` contient le contenu suivant.
```
{
"AutoScalingGroupName": "my-existing-asg",
"MixedInstancesPolicy": {
"LaunchTemplate": {
"Overrides": [
{
"InstanceType": "c5.18xlarge",
"WeightedCapacity": "18"
},
{
"InstanceType": "c5.24xlarge",
"WeightedCapacity": "24"
},
{
"InstanceType": "c5.2xlarge",
"WeightedCapacity": "2"
},
{
"InstanceType": "c5.4xlarge",
"WeightedCapacity": "4"
}
]
}
},
"MinSize": 0,
"MaxSize": 100,
"DesiredCapacity": 100
}
```
**Pour vérifier les pondérations à l’aide de la ligne de commande**
Utilisez l’une des commandes suivantes :
+ [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) (AWS CLI)
+ [Obtenez- ASAuto ScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
# Exemple de prix Spot par heure d’unité
Le tableau suivant compare le prix horaire des instances Spot dans différentes zones de disponibilité de la région USA Est (Virginie du Nord) avec le prix des instances à la demande dans la même région. Les prix affichés sont des exemples de prix et non des prix en réels. Ce sont vos coûts *par heure d'instance*.
**Exemple : prix Spot par heure d'instance**
| Type d’instance | us-east-1a | us-east-1b | us-east-1c | Tarification à la demande |
| --- | --- | --- | --- | --- |
| c5.2xlarge | \$10.180 | \$10.191 | \$10.170 | \$10.34 |
| c5.4xlarge | \$10.341 | \$10.361 | \$10.318 | \$10.68 |
| c5.12xlarge | \$10.779 | \$10.777 | \$10.777 | \$12.04 |
| c5.18xlarge | \$11.207 | \$11.475 | \$11.357 | \$13.06 |
| c5.24xlarge | \$11.555 | \$11.555 | \$11.555 | \$14.08 |
Avec les pondérations d’instance, vous pouvez évaluer vos coûts en fonction de ce que vous utilisez *par heure d’unité*. Vous pouvez déterminer le prix par heure d'unité en divisant le prix pour un type d'instance par le nombre d'unités qu'il représente. Pour les instances à la demande, le prix par heure d'unité est le même lors du déploiement d'un type d'instance que lors du déploiement d'une taille différente du même type d'instance. Par contre, le prix Spot par heure d'unité varie en fonction du groupe d'instances Spot.
L’exemple suivant montre comment le calcul du prix Spot par unité d’heure fonctionne avec les pondérations d’instance. Pour faciliter le calcul, supposons que vous souhaitez lancer des instances Spot uniquement dans la région `us-east-1a`. Le prix par heure unitaire est indiqué dans le tableau suivant.
**Exemple : prix au comptant par unité d'heure**
| Type d’instance | us-east-1a | Pondération de l’instance | Prix par heure d’unité |
| --- | --- | --- | --- |
| c5.2xlarge | \$10.180 | 2 | \$10.090 |
| c5.4xlarge | \$10.341 | 4 | \$10.085 |
| c5.12xlarge | \$10.779 | 12 | \$10.065 |
| c5.18xlarge | \$11.207 | 18 | \$10.067 |
| c5.24xlarge | \$11.555 | 24 | \$10.065 |
# Utiliser plusieurs modèles de lancement
Outre l’utilisation de plusieurs types d’instance, vous pouvez également vous servir de plusieurs modèles de lancement.
Par exemple, supposons que vous configuriez un groupe Auto Scaling pour les applications à forte intensité de calcul et que vous souhaitiez inclure une combinaison de types d’instances C5, C5a et C6g. Cependant, les instances C6g sont équipées d'un processeur AWS Graviton basé sur l'architecture Arm 64 bits, tandis que les instances C5 et C5a fonctionnent sur des processeurs Intel x86 64 bits. Les instances AMIs for C5 et C5a fonctionnent toutes les deux sur chacune de ces instances, mais pas sur les instances C6g. Pour résoudre ce problème, utilisez un modèle de lancement différent pour les instances C6g. Vous pouvez toujours utiliser le même modèle de lancement pour les instances C5 et C5a.
Cette section décrit les procédures d'utilisation du pour AWS CLI effectuer des tâches liées à l'utilisation de plusieurs modèles de lancement. Actuellement, cette fonction n'est disponible que si vous utilisez l'interface AWS CLI ou un kit SDK. Elle n'est pas disponible à partir de la console.
**Topics**
+ [Configurer un groupe Auto Scaling afin d’utiliser plusieurs modèles de lancement](#configue-auto-scaling-group-to-use-multiple-launch-templates)
+ [Ressources connexes](#multiple-launch-templates-related-resources)
## Configurer un groupe Auto Scaling afin d’utiliser plusieurs modèles de lancement
Vous pouvez configurer un groupe Auto Scaling afin d’utiliser plusieurs modèles de lancement, comme indiqué dans les exemples suivants.
**Pour configurer un nouveau groupe Auto Scaling afin d’utiliser plusieurs modèles de lancement (AWS CLI)**
Utilisez la commande [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html). Par exemple, la commande suivante crée un nouveau groupe Auto Scaling. Celui-ci spécifie les types d'instances `c5.large`, `c5a.large` et `c6g.large`, et définit un nouveau modèle de lancement pour le type d'instance `c6g.large` afin qu'une AMI appropriée soit utilisée pour lancer les instances Arm. Amazon EC2 Auto Scaling s'appuie sur l'ordre des types d'instances afin de déterminer le type d'instance à utiliser en premier pour satisfaire la capacité à la demande.
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
Le fichier `config.json` contient le contenu suivant.
```
{
"AutoScalingGroupName":"my-asg",
"MixedInstancesPolicy":{
"LaunchTemplate":{
"LaunchTemplateSpecification":{
"LaunchTemplateName":"my-launch-template-for-x86",
"Version":"$Latest"
},
"Overrides":[
{
"InstanceType":"c6g.large",
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template-for-arm",
"Version": "$Latest"
}
},
{
"InstanceType":"c5.large"
},
{
"InstanceType":"c5a.large"
}
]
},
"InstancesDistribution":{
"OnDemandBaseCapacity": 1,
"OnDemandPercentageAboveBaseCapacity": 50,
"SpotAllocationStrategy": "capacity-optimized"
}
},
"MinSize":1,
"MaxSize":5,
"DesiredCapacity":3,
"VPCZoneIdentifier":"subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782",
"Tags":[ ]
}
```
**Pour configurer un groupe Auto Scaling existant afin d’utiliser plusieurs modèles de lancement (AWS CLI)**
Utilisez la commande [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html). Par exemple, la commande suivante attribue le modèle de lancement intitulé `my-launch-template-for-arm` au type d’instance `c6g.large` du groupe Auto Scaling intitulé *`my-asg`*.
```
aws autoscaling update-auto-scaling-group --cli-input-json file://~/config.json
```
Le fichier `config.json` contient le contenu suivant.
```
{
"AutoScalingGroupName":"my-asg",
"MixedInstancesPolicy":{
"LaunchTemplate":{
"Overrides":[
{
"InstanceType":"c6g.large",
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template-for-arm",
"Version": "$Latest"
}
},
{
"InstanceType":"c5.large"
},
{
"InstanceType":"c5a.large"
}
]
}
}
}
```
**Pour configurer un nouveau groupe Auto Scaling afin d'utiliser plusieurs modèles de lancement avec sélection du type d'instance basée sur les attributs ()AWS CLI**
Utilisez la commande [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html). Par exemple, la commande suivante crée un nouveau groupe Auto Scaling en spécifiant un modèle de lancement pour les instances AWS Graviton avec une AMI ARM et un modèle de lancement supplémentaire pour les instances basées sur AMD ou Intel avec une AMI x86. Il utilise ensuite deux fois la [sélection d'instance basée sur les attributs](create-mixed-instances-group-attribute-based-instance-type-selection.md) pour sélectionner un large éventail de types d'instances pour chaque architecture de processeur. Vous pouvez ajouter une configuration similaire à un groupe Auto Scaling existant à l'aide de la [update-autoscaling-group](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/update-auto-scaling-group.html)commande.
```
aws autoscaling create-auto-scaling-group --cli-input-json file://~/config.json
```
Le fichier `config.json` contient le contenu suivant.
```
{
"AutoScalingGroupName":"my-asg",
"MixedInstancesPolicy":{
"LaunchTemplate":{
"LaunchTemplateSpecification":{
"LaunchTemplateName":"my-launch-template-for-arm",
"Version":"$Latest"
},
"Overrides":[
{
"InstanceRequirements": {
"VCpuCount": {"Min": 2},
"MemoryMiB": {"Min": 2048},
"CpuManufacturers": ["amazon-web-services"]
}
},
{
"InstanceRequirements": {
"VCpuCount": {"Min": 2},
"MemoryMiB": {"Min": 2048},
"CpuManufacturers": ["intel", "amd"]
},
"LaunchTemplateSpecification": {
"LaunchTemplateName": "my-launch-template-for-x86",
"Version": "$Latest"
}
}
]
},
"InstancesDistribution":{
"OnDemandPercentageAboveBaseCapacity": 0,
"SpotAllocationStrategy": "price-capacity-optimized"
}
},
"MinSize":1,
"MaxSize":10,
"DesiredCapacity":6,
"VPCZoneIdentifier":"subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782",
"Tags":[ ]
}
```
**Pour vérifier les modèles de lancement d'un groupe Auto Scaling**
Utilisez l’une des commandes suivantes :
+ [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) (AWS CLI)
+ [Obtenez- ASAuto ScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Get-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
## Ressources connexes
[Vous pouvez trouver un exemple de spécification de plusieurs modèles de lancement à l'aide de la sélection du type d'instance basée sur les attributs dans un CloudFormation modèle sur AWS re:Post.](https://repost.aws/articles/ARQeKDQX68TcqipYaaisl6bA/cloudformation-auto-scaling-group-sample-template-for-mixed-x86-intel-amd-and-aws-graviton-instances)
# Créer des groupes Auto Scaling à l’aide de configurations de lancement
**Important**
Limites:
Depuis **le 1er janvier 2023,** les nouveaux types d'instances Amazon EC2 ne sont plus pris en charge dans les configurations de lancement. Cela inclut la prise en charge de tous les types d'instances ajoutés à un Région AWS après le lancement initial de la région.
Les comptes créés le **1er juin 2023** ou après ne peuvent pas créer de nouvelles configurations de lancement à l'aide de la console.
Les comptes créés le **1er octobre 2024** ou après cette date ne peuvent pas créer de nouvelles configurations de lancement à l'aide d'aucune méthode (console AWS CLI, API ou CloudFormation).
Effectuez la migration vers les modèles de lancement pour vous assurer que vous n'avez pas besoin de créer de nouvelles configurations de lancement maintenant ou à l'avenir. Pour plus d’informations sur la migration de vos groupes Auto Scaling vers les modèles de lancement, consultez la section [Migrez vos groupes Auto Scaling pour lancer des modèles](migrate-to-launch-templates.md).
Si vous avez créé une configuration de lancement ou une instance EC2, vous pouvez créer un groupe Auto Scaling qui utilise la configuration de lancement comme modèle de configuration pour ses instances EC2. La configuration de lancement spécifie plusieurs informations, notamment l’identifiant d’AMI, le type d’instance, la paire de clés, les groupes de sécurité et le mappage de périphérique de stockage en mode bloc pour les instances. Pour plus d’informations sur la création des configurations de lancement, consultez la section [Créez une configuration de lancement](create-launch-config.md).
Vous devez disposer des autorisations nécessaires pour créer un groupe Auto Scaling. Vous devez également disposer des autorisations nécessaires pour créer un rôle lié à un service qu’Amazon EC2 Auto Scaling utilise pour effectuer les actions en votre nom, s’il n’existe pas encore. Pour obtenir des exemples de politiques IAM qu’un administrateur peut utiliser comme référence pour vous accorder des autorisations, consultez [Exemples de politiques basées sur l’identité](security_iam_id-based-policy-examples.md).
**Topics**
+ [Créer un groupe Auto Scaling à l'aide d'une configuration du lancement](create-asg-launch-configuration.md)
+ [Créez un groupe Auto Scaling à partir d'une instance existante à l'aide du AWS CLI](create-asg-from-instance.md)
# Créer un groupe Auto Scaling à l'aide d'une configuration du lancement
**Important**
Nous fournissons des informations sur les configurations de lancement pour les clients qui n'ont pas encore migré des configurations de lancement vers les modèles de lancement. Pour plus d’informations sur la migration de vos groupes Auto Scaling vers les modèles de lancement, consultez la section [Migrez vos groupes Auto Scaling pour lancer des modèles](migrate-to-launch-templates.md).
Lorsque vous créez un groupe Auto Scaling, vous devez indiquer les informations nécessaires pour configurer les instances Amazon EC2, les zones de disponibilité et les sous-réseaux VPC pour les instances, la capacité souhaitée et les limites de capacité minimale et maximale.
La procédure suivante montre comment créer un groupe Auto Scaling avec une configuration du lancement. Vous ne pouvez pas modifier une configuration du lancement après l'avoir créée, mais vous pouvez remplacer la configuration du lancement d'un groupe Auto Scaling. Pour de plus amples informations, veuillez consulter [Modifier la configuration du lancement pour un groupe Auto Scaling](change-launch-config.md).
**Conditions préalables**
+ Vous devez avoir créé une configuration du lancement. Pour de plus amples informations, veuillez consulter [Créez une configuration de lancement](create-launch-config.md).
**Pour créer un groupe Auto Scaling avec une configuration du lancement (console)**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Dans la barre de navigation en haut de l'écran, choisissez la même Région AWS que celle que vous avez utilisée lors de la création de la configuration de lancement.
1. Choisissez **Créer un groupe Auto Scaling**.
1. Dans la page **Choisir un modèle de lancement ou une configuration**, dans **Nom du groupe Auto Scaling**, entrez un nom pour le groupe Auto Scaling.
1. Pour choisir une configuration du lancement, procédez comme suit :
1. Pour **Launch template** (Modèle de lancement), choisissez **Switch to launch configuration** (Basculer vers la configuration du lancement).
1. Pour **Launch configuration (Configuration de lancement)**, choisissez une configuration du lancement existante.
1. Vérifiez que votre modèle de lancement prend en charge toutes les options que vous envisagez d'utiliser, puis choisissez **Next** (Suivant).
1. Sur la page **Configurer les options de lancement de l'instance**, sous **Network** (Réseau), pour **VPC**, choisissez un VPC. Le groupe Auto Scaling doit être créé dans le même VPC que le groupe de sécurité que vous avez spécifié dans votre configuration du lancement.
1. Pour **Availability Zones and subnets** (Zones de disponibilité et sous-réseaux), choisissez un ou plusieurs sous-réseaux dans le VPC spécifié. Utilisez les sous-réseaux dans plusieurs zones de disponibilité pour une haute disponibilité. Pour de plus amples informations, veuillez consulter [Considérations à prendre en compte lors du choix des sous-réseaux VPC](asg-in-vpc.md#as-vpc-considerations).
1. Choisissez **Suivant**.
Vous pouvez également accepter le reste des valeurs par défaut, puis choisir **Skip to review** (Passer à la révision).
1. (Facultatif) Sur la page **Configure advanced options (Configurer les option avancées)**, configurez les options suivantes, puis choisissez **Next (Suivant)** :
1. (Facultatif) Pour les **bilans de santé** et les **types de bilans de santé supplémentaires**, sélectionnez **Activer les bilans de santé Amazon EBS**. Pour de plus amples informations, veuillez consulter [Surveillez les instances Auto Scaling dont les volumes Amazon EBS sont altérés à l'aide de contrôles de santé](monitor-and-replace-instances-with-impaired-ebs-volumes.md).
1. (Facultatif) Dans le champ **Période de grâce de la surveillance de l’état**, saisissez le délai en secondes. Ce délai correspond à la durée pendant laquelle Amazon EC2 Auto Scaling doit attendre avant de vérifier l'état de santé d'une instance après son entrée dans `InService` cet état. Pour de plus amples informations, veuillez consulter [Définir la période de grâce de la surveillance de l'état pour un groupe Auto Scaling](health-check-grace-period.md).
1. Sous **Paramètres supplémentaires**, **Surveillance, indiquez** si vous souhaitez activer la collecte des métriques de CloudWatch groupe. Ces métriques fournissent des mesures qui peuvent être des indicateurs d'un problème potentiel, comme le nombre d'instances en cours de résiliation ou le nombre d'instances en attente. Pour de plus amples informations, veuillez consulter [Surveillez CloudWatch les métriques de vos groupes et instances Auto Scaling](ec2-auto-scaling-cloudwatch-monitoring.md).
1. Pour **Activer le préchauffage de l'instance par défaut**, sélectionnez cette option et choisissez le temps de préchauffage de votre application. Si vous créez un groupe Auto Scaling doté d'une politique de dimensionnement, la fonctionnalité de préchauffage de l'instance par défaut améliore les CloudWatch métriques Amazon utilisées pour le dimensionnement dynamique. Pour de plus amples informations, veuillez consulter [Définir la préparation par défaut d'instance d'un groupe Auto Scaling](ec2-auto-scaling-default-instance-warmup.md).
1. (Facultatif) Sur la page **Configure group size and scaling policies** (Configurer les politiques de taille de groupe et de mise à l'échelle), configurez les options suivantes, puis choisissez **Next** (Suivant) :
1. Dans **Taille du groupe**, pour la **Capacité souhaitée**, entrez le nombre initial d’instances à lancer.
1. Dans la section **Mise à l’échelle**, sous **Limites de mise à l’échelle**, si votre nouvelle valeur pour la **capacité souhaitée** est supérieure à la **capacité minimale souhaitée** et à la **capacité maximale souhaitée**, la **capacité maximale souhaitée** est automatiquement augmentée à la nouvelle valeur de capacité souhaitée. Vous pouvez modifier ces limites si nécessaire. Pour de plus amples informations, veuillez consulter [Définissez des limites de mise à l’échelle pour votre groupe Auto Scaling](asg-capacity-limits.md).
1. Pour le **dimensionnement automatique**, indiquez si vous souhaitez créer une politique de dimensionnement de suivi des cibles. Vous pouvez également élaborer cette politique après avoir créé votre groupe Auto Scaling.
Si vous choisissez la **politique de dimensionnement de suivi des cibles**, suivez les instructions dans [Création d'une politique de suivi des cibles et d'échelonnement](policy_creating.md) pour créer la politique.
1. Pour la **politique de maintenance des instances**, indiquez si vous souhaitez créer une politique de maintenance des instances. Vous pouvez également élaborer cette politique après avoir créé votre groupe Auto Scaling. Pour créer une politique, suivez les instructions fournies dans [Définir une politique de maintenance des instances](set-instance-maintenance-policy.md).
1. Sous **Instance scale-in protection** (Protection contre la diminution en charge des instances), choisissez si vous souhaitez activer la protection contre la diminution de la taille d'instance. Pour de plus amples informations, veuillez consulter [Utiliser la protection évolutive de l'instance pour contrôler la fermeture de l'instance](ec2-auto-scaling-instance-protection.md).
1. (Facultatif) Pour recevoir des notifications, dans **Add notification** (Ajouter une notification), configurez la notification, puis choisissez **Next** (Suivant). Pour de plus amples informations, veuillez consulter [Options de notification Amazon SNS pour Amazon EC2 Auto Scaling](ec2-auto-scaling-sns-notifications.md).
1. (Facultatif) Pour ajouter des balises, choisissez **Add tag** (Ajouter une balise), fournissez une clé de balise et une valeur pour chaque balise, puis choisissez **Next** (Suivant). Pour de plus amples informations, veuillez consulter [Baliser des groupes et des instances Auto Scaling](ec2-auto-scaling-tagging.md).
1. Sur la page **Review**, sélectionnez **Create Auto Scaling group (Créer un groupe Auto Scaling)**.
**Pour créer un groupe Auto Scaling avec la ligne de commande**
Vous pouvez utiliser l'une des commandes suivantes :
+ [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html) (AWS CLI)
+ [Nouveau- ASAuto ScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/New-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
# Créez un groupe Auto Scaling à partir d'une instance existante à l'aide du AWS CLI
**Important**
Nous fournissons des informations sur les configurations de lancement pour les clients qui n'ont pas encore migré des configurations de lancement vers les modèles de lancement. Pour plus d’informations sur la migration de vos groupes Auto Scaling vers les modèles de lancement, consultez la section [Migrez vos groupes Auto Scaling pour lancer des modèles](migrate-to-launch-templates.md).
Si c'est la première fois que vous créez un groupe Auto Scaling, nous vous recommandons d'utiliser la console pour créer un modèle de lancement à partir d'une instance EC2 existante. Ensuite, utilisez le modèle de lancement pour créer un groupe Auto Scaling. Pour cette procédure, veuillez consulter [Créer un groupe Auto Scaling avec l'Amazon EC2 Launch Wizard](create-asg-ec2-wizard.md).
La procédure suivante montre comment créer un groupe Auto Scaling en spécifiant une instance existante à utiliser comme base pour le lancement d'autres instances. Plusieurs paramètres sont nécessaires pour créer une instance EC2, tels que l'ID Amazon Machine Image (AMI), le type d'instance, la paire de clés et le groupe de sécurité. Toutes ces informations sont également utilisées par Amazon EC2 Auto Scaling pour lancer des instances en votre nom lorsqu'il y a un besoin de mise à l'échelle. Ces informations sont stockées soit dans un modèle de lancement, soit dans une configuration du lancement.
Lorsque vous utilisez une instance existante, Amazon EC2 Auto Scaling crée un groupe Auto Scaling qui lance les instances en fonction d'une configuration du lancement qui est créée en même temps. La nouvelle configuration du lancement porte le même nom que le groupe Auto Scaling, et elle inclut certains détails de configuration de l'instance identifiée.
Les détails de configuration suivants sont copiés de l'instance identifiée dans la configuration du lancement :
+ ID d’AMI
+ Type d’instance
+ Paire de clés
+ Groupes de sécurité
+ Type d'adresse IP (publique ou privée)
+ Profil d'instance IAM, le cas échéant
+ Surveillance (vrai ou faux)
+ Optimisé pour EBS (vrai ou faux)
+ Paramètre de location, en cas de lancement sur un VPC (partagé ou dédié)
+ ID du noyau et ID du disque RAM, le cas échéant
+ Données utilisateur, le cas échéant
+ Prix Spot (maximum)
Le sous-réseau VPC et la zone de disponibilité sont copiés depuis l’instance identifiée vers la propre définition de ressource du groupe Auto Scaling.
Si l'instance identifiée se trouve dans un groupe de placement, le nouveau groupe Auto Scaling lance des instances dans le même groupe de placement que l'instance identifiée. Comme les paramètres de configuration du lancement ne permettent pas de spécifier un groupe de placement, le groupe de placement est copié dans l'attribut `PlacementGroup` du nouveau groupe Auto Scaling.
Les détails de configuration suivants ne sont pas copiés de votre instance identifiée :
+ Stockage : les périphériques de bloc (volumes EBS et volumes de stockage d'instances) ne sont pas copiés à partir de l'instance identifiée. Au lieu de cela, le mappage de périphériques de stockage en mode bloc créé dans le cadre de la création de l'AMI détermine quels périphériques sont utilisés.
+ Nombre d'interfaces réseau : les interfaces réseau ne sont pas copiées à partir de votre instance identifiée. Au lieu de cela, Amazon EC2 Auto Scaling utilise ses paramètres par défaut pour créer une interface réseau, qui est l'interface réseau principale (eth0).
+ Options de métadonnées d'instance : les paramètres de métadonnées accessibles, de version des métadonnées et de limite de saut de réponse aux jetons ne sont pas copiés à partir de l'instance identifiée. Au lieu de cela, Amazon EC2 Auto Scaling utilise ses paramètres par défaut. Pour de plus amples informations, veuillez consulter [Configurer les options de métadonnées d’instance](create-launch-config.md#launch-configurations-imds).
+ Équilibreurs de charge : si l'instance identifiée est enregistrée avec un ou plusieurs équilibreurs de charge, les informations sur l'équilibreur de charge ne sont pas copiées sur l'équilibreur de charge ou l'attribut de groupe cible du nouveau groupe Auto Scaling.
+ Identifications : si l'instance identifiée possède des identifications, ces dernières ne sont pas copiées dans l'attribut `Tags` du nouveau groupe Auto Scaling.
## Conditions préalables
L'instance EC2 doit répondre aux critères suivants :
+ L'instance ne fait pas partie d'un autre groupe Auto Scaling.
+ L'instance a pour statut `running`.
+ L'AMI qui a été utilisée pour lancer l'instance doit toujours exister.
## Créer un groupe Auto Scaling à partir d'une instance EC2 (AWS CLI)
La procédure suivante expliquer comment utiliser une commande CLI pour créer un groupe Auto Scaling à partir d’une instance EC2.
Cette procédure n'ajoute pas l'instance au groupe Auto Scaling. Pour que l'instance soit attachée, vous devez exécuter [attachez des instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/attach-instances.html) une fois votre groupe Auto Scaling créé.
Avant de commencer, recherchez l'ID de l'instance EC2 avec la console Amazon EC2 ou la commande [describe-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-instances.html).
**Pour utiliser l’instance actuelle comme modèle**
+ Utilisez la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande suivante pour créer un groupe Auto Scaling à partir de l'instance `i-123456789abcdefg0` EC2. `my-asg-from-instance`
```
aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg-from-instance \
--instance-id i-123456789abcdefg0 --min-size 1 --max-size 2 --desired-capacity 2
```
**Pour vérifier que votre groupe Auto Scaling possède des instances lancées**
+ Utilisez la [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html)commande suivante pour vérifier que le groupe Auto Scaling a bien été créé.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg-from-instance
```
L'exemple de réponse suivant montre que la capacité souhaitée du groupe est 2, que le groupe possède 2 instances en cours d'exécution, et que la configuration du lancement est également nommée `my-asg-from-instance`.
```
{
"AutoScalingGroups":[
{
"AutoScalingGroupName":"my-asg-from-instance",
"AutoScalingGroupARN":"arn",
"LaunchConfigurationName":"my-asg-from-instance",
"MinSize":1,
"MaxSize":2,
"DesiredCapacity":2,
"DefaultCooldown":300,
"AvailabilityZones":[
"us-west-2a"
],
"LoadBalancerNames":[],
"TargetGroupARNs":[],
"HealthCheckType":"EC2",
"HealthCheckGracePeriod":0,
"Instances":[
{
"InstanceId":"i-34567890abcdef012",
"InstanceType":"t2.micro",
"AvailabilityZone":"us-west-2a",
"LifecycleState":"InService",
"HealthStatus":"Healthy",
"LaunchConfigurationName":"my-asg-from-instance",
"ProtectedFromScaleIn":false
},
{
"InstanceId":"i-012345abcdefg6789",
"InstanceType":"t2.micro",
"AvailabilityZone":"us-west-2a",
"LifecycleState":"InService",
"HealthStatus":"Healthy",
"LaunchConfigurationName":"my-asg-from-instance",
"ProtectedFromScaleIn":false
}
],
"CreatedTime":"2020-10-28T02:39:22.152Z",
"SuspendedProcesses":[ ],
"VPCZoneIdentifier":"subnet-0abc1234",
"EnabledMetrics":[ ],
"Tags":[ ],
"TerminationPolicies":[
"Default"
],
"NewInstancesProtectedFromScaleIn":false,
"ServiceLinkedRoleARN":"arn",
"TrafficSources":[]
}
]
}
```
**Pour afficher la configuration du lancement**
+ Utilisez la [describe-launch-configurations](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-launch-configurations.html)commande suivante pour afficher les détails de la configuration de lancement.
```
aws autoscaling describe-launch-configurations --launch-configuration-names my-asg-from-instance
```
Voici un exemple de sortie :
```
{
"LaunchConfigurations":[
{
"LaunchConfigurationName":"my-asg-from-instance",
"LaunchConfigurationARN":"arn",
"ImageId":"ami-234567890abcdefgh",
"KeyName":"my-key-pair-uswest2",
"SecurityGroups":[
"sg-12abcdefgh3456789"
],
"ClassicLinkVPCSecurityGroups":[ ],
"UserData":"",
"InstanceType":"t2.micro",
"KernelId":"",
"RamdiskId":"",
"BlockDeviceMappings":[ ],
"InstanceMonitoring":{
"Enabled":true
},
"CreatedTime":"2020-10-28T02:39:22.321Z",
"EbsOptimized":false,
"AssociatePublicIpAddress":true
}
]
}
```
**Pour résilier l'instance**
+ Vous pouvez résilier l'instance si vous n'en n'avez plus besoin. La commande [terminate-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/terminate-instances.html) suivant résilie l'instance`i-123456789abcdefg0`.
```
aws ec2 terminate-instances --instance-ids i-123456789abcdefg0
```
Après avoir résilié une instance Amazon EC2, vous ne pouvez pas la redémarrer. Une fois résiliée, ses données sont perdues et le volume ne peut être attaché à aucune instance. Pour en savoir plus sur la résiliation d'instances, consultez la section [Résiliation d'une instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#terminating-instances-console) dans le guide de l'*utilisateur Amazon EC2.*
# Lancer des instances de manière synchrone
Amazon EC2 Auto Scaling propose deux méthodes pour lancer des instances dans votre groupe Auto Scaling : le comportement de dimensionnement asynchrone et le provisionnement synchrone à l'aide de l'API. LaunchInstances
Avec le provisionnement synchrone, vous utilisez l' LaunchInstances API pour demander un nombre spécifique d'instances dans une zone de disponibilité donnée. Le provisionnement synchrone offre les avantages suivants :
+ Feedback immédiat sur la disponibilité des capacités dans des zones de disponibilité spécifiques
+ Contrôle précis des instances de zone de disponibilité lancées dans
+ Instance déterministe IDs pour une utilisation immédiate dans les systèmes d'orchestration
+ Décisions de dimensionnement en temps réel basées sur les contraintes de capacité réelles
+ Mise à l'échelle plus rapide en éliminant les temps d'attente pour les lancements asynchrones d'Auto Scaling
Avec Auto Scaling asynchrone, lorsque vous modifiez la capacité souhaitée ou lorsqu'une politique de dimensionnement se déclenche, Amazon EC2 Auto Scaling traite la demande de dimensionnement et lance les instances en arrière-plan. Vous devez surveiller les activités de dimensionnement ou décrire votre groupe Auto Scaling pour déterminer à quel moment les instances sont lancées avec succès.
**Note**
L' LaunchInstances API fonctionne uniquement avec les groupes Auto Scaling qui utilisent des modèles de lancement. Les groupes Auto Scaling qui utilisent des configurations de lancement ne sont pas pris en charge. Si votre groupe Auto Scaling utilise une configuration de lancement, vous devez migrer vers un modèle de lancement avant d'utiliser le provisionnement synchrone.
L' LaunchInstances API prend en charge les politiques relatives aux instances mixtes avec des options d'achat entièrement à la demande ou entièrement ponctuelles uniquement. Les politiques mixtes combinant à la fois des instances à la demande et des instances ponctuelles ne sont pas prises en charge.
Pour les groupes Auto Scaling couvrant plusieurs zones de disponibilité, vous devez spécifier la zone de disponibilité ou le sous-réseau cible. Pour les groupes mono-AZ, ce paramètre est facultatif.
## Provisionnement synchrone et dimensionnement asynchrone
### Provisionnement synchrone
Lorsque vous utilisez l' LaunchInstances API, Amazon EC2 Auto Scaling :
+ Tente immédiatement de lancer les instances demandées en utilisant CreateFleet
+ Attend de renvoyer CreateFleet l'instance IDs avant de répondre
+ Renvoie les informations relatives à IDs l'instance, aux types d'instances et à la zone de disponibilité en cas de réussite
+ Renvoie des codes d'erreur spécifiques et des informations sur les défaillances
+ Fournit un feedback immédiat, permettant de prendre des décisions de dimensionnement en temps réel
### Mise à l'échelle asynchrone
Lorsque vous utilisez des méthodes Auto Scaling asynchrones, telles que la modification de la capacité souhaitée ou l'utilisation de politiques de dimensionnement, Amazon EC2 Auto Scaling :
+ Met à jour la capacité souhaitée dans l'API mais ne renvoie pas les instances immédiatement
+ Planifie automatiquement les lancements d'instances dans les zones de disponibilité
+ Lance des instances via des flux de travail en arrière-plan
+ Répartit automatiquement la capacité entre plusieurs zones de disponibilité à des fins d'équilibre
+ Gère les échecs de lancement grâce à une logique de nouvelle tentative intégrée
Vous devez interroger les activités de dimensionnement ou décrire votre groupe Auto Scaling pour vérifier l'état des opérations de lancement.
## Limites et considérations
Lorsque vous utilisez le provisionnement synchrone, gardez à l'esprit les remarques et limites suivantes :
+ **État de l'instance après le lancement** : les instances renvoyées par l'API sont en attente. Ils peuvent toujours échouer lors des processus de flux de travail ou des accrochages du cycle de vie ultérieurs. Une réponse d'API réussie signifie qu'EC2 a accepté la demande de lancement et renvoyé les ID d'instance. Les instances ne sont pas automatiquement considérées comme entièrement prêtes pour les charges de travail et doivent suivre les processus de cycle de vie standard EC2 et Auto Scaling.
+ **Limitation des pools de chaleur** — Les groupes Auto Scaling avec des pools de chaleur ne sont actuellement pas pris en charge. Si vous tentez d'appeler l' LaunchInstances API sur un groupe Auto Scaling sur lequel un pool de chaleur est configuré, l'API effectue un démarrage à froid au lieu d'utiliser des instances de pool de chauffage et renvoie une UnsupportedOperation erreur. Pour plus d'informations sur les démarrages à froid, consultez [la section Limitations relatives aux piscines chaudes](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-warm-pools.html#warm-pools-limitations).
+ **Expiration de l'API et nouvelles tentatives** : si l' CreateFleet opération sous-jacente prend plus de temps que prévu, l'API peut expirer et renvoyer un jeton d'idempuissance. Vous pouvez réessayer de l'utiliser ClientToken pour suivre l'opération de lancement initiale ou utiliser describe-instances avec le jeton client pour vérifier les instances lancées.
+ **Contraintes liées aux zones de disponibilité** : si votre groupe Auto Scaling couvre plusieurs zones de disponibilité et que le rééquilibrage des zones de disponibilité est activé, le lancement synchrone des instances peut provoquer des conflits opérationnels :
+ Limitation d'une seule zone de disponibilité par appel : chaque appel d' LaunchInstances API ne peut cibler qu'une seule zone de disponibilité, même si votre groupe Auto Scaling couvre plusieurs zones.
+ Conflits de rééquilibrage AZ - Si le rééquilibrage AZ est activé dans votre groupe Auto Scaling, les appels séquentiels entre différents groupes AZs peuvent déclencher des lancements asynchrones supplémentaires, ce qui se traduit par un nombre d'instances supérieur à celui prévu. Envisagez de suspendre le rééquilibrage AZ pour un contrôle précis de la capacité. Pour de plus amples informations, veuillez consulter [Suspendre et reprendre les processus Amazon EC2 Auto Scaling](as-suspend-resume-processes.md).
+ **Scénarios de réussite partielle** — L'`LaunchInstances`API peut renvoyer un succès partiel si seule une partie de la capacité demandée est disponible, ce qui correspond au comportement normal d'EC2. L'API renvoie les instances lancées avec succès ainsi que les détails des erreurs en cas d'échec des lancements. Pour les cas d'utilisation nécessitant le lancement simultané de toutes les instances (comme les applications nécessitant toutes les instances dans la même zone de disponibilité pour une faible latence), vous devez mettre fin aux instances partiellement lancées et réessayer dans une autre zone de disponibilité. Tenez compte de ce comportement lors de la conception d'une logique de nouvelle tentative pour les charges de travail sensibles à la capacité.
+ **Pondérations d'instance** : si votre groupe Auto Scaling utilise des poids d'instance, le RequestedCapacity paramètre représente les unités de capacité pondérées, et non le nombre d'instances. Le nombre réel d'instances lancées dépend des types d'instances sélectionnés et de leurs poids configurés. EC2 Auto Scaling limite les lancements à 100 instances par appel d'API, quelle que soit la capacité pondérée demandée.
+ **Types d'instances mixtes** : l' LaunchInstances API utilise la politique d'instances mixtes existante de votre groupe Auto Scaling pour déterminer les types d'instances à lancer. L'API lance les instances en fonction de la stratégie d'allocation de votre groupe et des priorités relatives aux types d'instances.
# Lancement d'instances avec provisionnement synchrone
Vous pouvez utiliser l' LaunchInstances API pour lancer de manière synchrone un nombre spécifique d'instances dans votre groupe Auto Scaling. L'API lance des instances dans la zone de disponibilité ou le sous-réseau que vous spécifiez et renvoie immédiatement les informations relatives à l'instance IDs ou à l'erreur.
## Conditions préalables
Avant de pouvoir utiliser l' LaunchInstances API, vous devez disposer des éléments suivants :
+ Un groupe Auto Scaling qui utilise un modèle de lancement (les configurations de lancement ne sont pas prises en charge)
+ Vous devez disposer d'autorisations pour les actions IAM suivantes :
+ `autoscaling:LaunchInstances`
+ `ec2:CreateFleet`
+ `ec2:DescribeLaunchTemplateVersions`
## Lancer des instances avec un provisionnement synchrone
Vous pouvez lancer des instances avec un provisionnement synchrone via le. AWS CLI
### AWS CLI
Pour lancer des instances avec un provisionnement synchrone :
```
aws autoscaling launch-instances \
--auto-scaling-group-name group-name \
--requested-capacity number \
[--availability-zones zone-name] \
[--subnet-ids subnet-id] \
[--availability-zone-ids zone-id] \
[--retry-strategy none|retry-with-group-configuration] \
[--client-token token]
```
#### Exemples
**Lancement d'instances dans une zone de disponibilité spécifique**
```
aws autoscaling launch-instances \
--auto-scaling-group-name my-asg \
--requested-capacity 3 \
--availability-zones us-east-1a \
--retry-strategy retry-with-group-configuration
```
**Lancement d'instances dans un sous-réseau spécifique**
```
aws autoscaling launch-instances \
--auto-scaling-group-name my-asg \
--requested-capacity 2 \
--subnet-ids subnet-12345678 \
--retry-strategy none \
--client-token my-unique-token-123
```
#### Gestion des réponses
**Exemple de réponse réussie :**
```
{
"AutoScalingGroupName": "my-asg",
"ClientToken": "my-unique-token-123",
"Instances": [
{
"InstanceType": "m5.xlarge",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az1",
"SubnetId": "subnet-12345678",
"MarketType": "OnDemand",
"InstanceIds": ["i-0123456789abcdef0", "i-0fedcba9876543210"]
}
],
"Errors": []
}
```
**Exemple de réponse comportant des erreurs**
```
{
"AutoScalingGroupName": "my-asg",
"ClientToken": "my-unique-token-123",
"Instances": [],
"Errors": [
{
"InstanceType": "m5.large",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az1",
"SubnetId": "subnet-12345678",
"MarketType": "OnDemand",
"ErrorCode": "InsufficientInstanceCapacity",
"ErrorMessage": "There is not enough capacity to fulfill your request for instance type 'm5.large' in 'us-east-1a'"
}
]
}
```
## Gérer les échecs de lancement et les nouvelles tentatives
Lorsque l' LaunchInstances API rencontre des échecs, vous pouvez mettre en œuvre des stratégies de nouvelle tentative à l'aide de jetons d'idempotencie et de politiques de nouvelle tentative appropriées.
Vous pouvez utiliser le paramètre client-token pour réessayer les demandes. Vous pouvez également utiliser les stratégies de nouvelle tentative suivantes :
+ `RetryStrategy: none`(par défaut) - Si l'appel d'API échoue, la capacité souhaitée du groupe Auto Scaling reste inchangée et aucune nouvelle tentative automatique n'est effectuée.
+ `RetryStrategy: retry-with-group-configuration`- Si l'appel d'API échoue, la capacité souhaitée du groupe Auto Scaling est augmentée du montant demandé, et Auto Scaling réessaiera automatiquement de lancer des instances en utilisant la configuration et les processus standard du groupe.
Le comportement des nouvelles tentatives `RetryStrategy: retry-with-group-configuration` dépend du type d'échec :
+ **Erreurs de validation** : la capacité souhaitée n'est pas augmentée car l'opération ne peut pas se poursuivre. Par exemple, des paramètres non valides ou des configurations non prises en charge.
+ **Erreurs de capacité** : la capacité souhaitée est augmentée et Auto Scaling réessaiera de lancer des instances de manière asynchrone en utilisant les processus de dimensionnement habituels du groupe.
### Utilisation de jetons clients pour l'idempuissance
Le `client-token` paramètre garantit des opérations idempotentes et permet de réessayer en toute sécurité les demandes de lancement.
Comportements clés :
+ Les jetons clients ont une durée de vie de 8 heures à compter de la demande initiale
+ Une nouvelle tentative avec le même jeton client dans les 8 heures renvoie la réponse mise en cache au lieu de lancer de nouvelles instances
+ Après 8 heures, le même jeton client lancera une nouvelle opération de lancement
# Mettre à jour un groupe Auto Scaling
Vous pouvez mettre à jour la plupart des informations de votre groupe Auto Scaling. Vous ne pouvez pas mettre à jour le nom d'un groupe Auto Scaling ni le modifier Région AWS.
**Pour mettre à jour un groupe Auto Scaling (console)**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Choisissez votre groupe Auto Scaling pour afficher les informations le concernant, avec les onglets **Détails**, **Activité**, **Dimensionnement automatique**, **Gestion des instances**, **Surveillance** et **Actualisation des instances**.
1. Choisissez les onglets correspondant aux zones de configuration qui vous intéressent et mettez à jour les paramètres selon vos besoins. Pour chaque paramètre que vous modifiez, sélectionnez **Mettre à jour** pour enregistrer les modifications apportées à la configuration du groupe Auto Scaling.
+ Onglet **Détails**
Voici les paramètres généraux de votre groupe Auto Scaling. Vous pouvez les modifier et les gérer de la même manière que lors de la création d’un groupe Auto Scaling.
La section **Configurations avancées** contient certaines options qui ne sont pas disponibles lors de la création du groupe, telles que les [politiques de résiliation](ec2-auto-scaling-termination-policies.md), la [stabilisation](ec2-auto-scaling-scaling-cooldowns.md), les [processus d’interruption](as-suspend-resume-processes.md) et la [durée de vie maximale de l’instance](asg-max-instance-lifetime.md). Vous pouvez également afficher, mais pas modifier, le groupe de placement et le [rôle lié à un service](autoscaling-service-linked-role.md) du groupe Auto Scaling.
+ **Onglet Intégrations**
+ **Équilibrage de charge** — [Elastic Load Balancing](autoscaling-load-balancer.md)
Si le groupe est associé à des ressources Elastic Load Balancing, consultez [Ajouter une zone de disponibilitéEnlever une zone de disponibilité](as-add-az-console.md) avant de modifier les zones de disponibilité. Certaines restrictions relatives à l’équilibreur de charge peuvent vous empêcher d’appliquer les modifications apportées aux zones de disponibilité de votre groupe aux zones de disponibilité de votre équilibreur de charge.
+ [Options d'**intégration de VPC Lattice —** VPC Lattice](ec2-auto-scaling-vpc-lattice.md)
+ Déplacement de **zone ARC — Déplacement** de zone [du groupe Auto Scaling](ec2-auto-scaling-zonal-shift.md)
+ Onglet **Mise à l’échelle automatique**
+ Politiques de **dimensionnement dynamiques — Politiques** [de dimensionnement dynamiques](as-scale-based-on-demand.md)
+ Politiques de **dimensionnement prédictif — Politiques** [de dimensionnement prédictif](ec2-auto-scaling-predictive-scaling.md)
+ **Actions planifiées** — [Actions planifiées](ec2-auto-scaling-scheduled-scaling.md)
+ Onglet **Gestion des instances**
+ **Crochets Lifecycle — Crochets** [Lifecycle](lifecycle-hooks.md)
+ **Piscine chaude** — [Piscines chaudes](ec2-auto-scaling-warm-pools.md)
+ Onglet **Activité**
+ **Notifications d'activité — Notifications** [Amazon SNS](ec2-auto-scaling-sns-notifications.md)
+ Onglet **Surveillance**
+ Il n'y a qu'une seule option dans cet onglet, qui vous permet d'activer ou de désactiver la [collecte de métriques de CloudWatch groupe](ec2-auto-scaling-metrics.md).
**Pour mettre à jour un groupe Auto Scaling avec la ligne de commande**
Vous pouvez utiliser l'une des commandes suivantes :
+ [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) (AWS CLI)
+ [Mettre à jour- ASAuto ScalingGroup](https://docs.aws.amazon.com/powershell/latest/reference/items/Update-ASAutoScalingGroup.html) (AWS Tools for Windows PowerShell)
## Mise à jour des instances Auto Scaling
Si vous associez un nouveau modèle de lancement ou une configuration de lancement à un groupe Auto Scaling, toutes les nouvelles instances recevront la configuration mise à jour. Les instances existantes continuent à s’exécuter avec leur configuration initiale. Pour appliquer vos modifications aux instances existantes, vous disposez des options suivantes :
+ Lancer une actualisation d’instance pour remplacer les anciennes instances. Pour de plus amples informations, veuillez consulter [Utiliser une actualisation d'instance pour mettre à jour les instances d'un groupe Auto Scaling](asg-instance-refresh.md).
+ Attendez que les activités de mise à l’échelle remplacent progressivement des instances plus anciennes par des instances plus récentes, en fonction de vos [stratégies de résiliation](as-instance-termination.md).
+ Résiliez-les manuellement afin qu’elles soient remplacées par votre groupe Auto Scaling.
**Note**
Vous pouvez modifier les attributs d’instance suivants en les indiquant dans le modèle de lancement ou dans la configuration de lancement :
Amazon Machine Image (AMI)
périphériques de stockage en mode bloc
paire de clés
type d'instance
groupes de sécurité
données utilisateur
surveillance
Profil d'instance IAM
location de placement
kernel
ramdisk
si l’instance possède une adresse IP publique
la stratégie de distribution des zones de disponibilité
## Stratégie d'allocation des groupes et modifications de capacité d'Auto Scaling
Lorsque vous modifiez une stratégie d'allocation de groupe Auto Scaling, les instances existantes ne sont pas remplacées. Toutes les nouvelles instances lancées en raison d'événements de scale-out suivront la nouvelle stratégie d'allocation. Toute future ampleur des événements suivra la [politique de résiliation](ec2-auto-scaling-termination-policies.md) et utilisera la nouvelle stratégie d'allocation si la politique de résiliation est définie sur `Default` ou`AllocationStrategy`. Par exemple, si vous modifiez la stratégie d'allocation de `lowest-price` à`price-capacity-optimized`, il se peut qu'aucune instance ne soit résiliée, mais toutes les nouvelles instances seront lancées avec la nouvelle stratégie d'allocation. Les modifications de type d'instance n'affectent pas les instances existantes.
Lorsque vous modifiez certains paramètres tels que le [OnDemandBaseCapacity](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstancesDistribution.html)ou le [OnDemandPercentageAboveBaseCapacity](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_InstancesDistribution.html), Auto Scaling se rééquilibre automatiquement si le pourcentage d'instances à la demande et d'instances ponctuelles ne correspond pas aux nouvelles spécifications. Supposons, par exemple, qu'un groupe Auto Scaling soit `OnDemandPercentageAboveBaseCapacity` défini sur 50 % d'instances à la demande et 50 % d'instances ponctuelles. Ensuite, le nombre d'instances à la demande `OnDemandPercentageAboveBaseCapacity` est porté à 100 %. Le groupe Auto Scaling rééquilibrera de manière proactive en lançant de nouvelles instances à la demande et en mettant fin aux instances ponctuelles. La [politique de maintenance des instances](instance-maintenance-policy-overview-and-considerations.md) que vous avez définie détermine l'ordre des activités de lancement et de cessation.
# Baliser des groupes et des instances Auto Scaling
Une *balise* est une étiquette d'attribut personnalisée que vous attribuez ou attribuez à une AWS ressource. AWS Chaque balise se compose de deux parties :
+ Une clé d'identification (par exemple, `costcenter`, `environment` ou `project`)
+ Un champ facultatif appelé valeur d'identification (par exemple, `111122223333` ou `production`)
Les balises vous permettent d’effectuer les actions suivantes :
+ Suivez vos AWS coûts. Vous activez ces balises sur le AWS Billing and Cost Management tableau de bord. AWS utilise les balises pour classer vos coûts et vous fournir un rapport mensuel de répartition des coûts. Pour plus d’informations, veuillez consulter [Utilisation des étiquettes de répartition des coûts](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) dans le *AWS Billing Guide de l’utilisateur*.
+ Contrôlez l'accès aux groupes Auto Scaling basé sur des balises. Vous pouvez utiliser des conditions dans vos politiques IAM pour contrôler l'accès aux groupes Auto Scaling en fonction des balises de ce groupe Auto Scaling. Pour de plus amples informations, veuillez consulter [Balises pour la sécurité](tag-security.md).
+ Filtrez et recherchez des groupes Auto Scaling en fonction des balises que vous insérez. Pour de plus amples informations, veuillez consulter [Utilisation d'identifications pour filtrer les groupes Auto Scaling](use-tag-filters-aws-cli.md).
+ Identifiez et organisez vos AWS ressources. Beaucoup Services AWS prennent en charge le balisage. Vous pouvez donc attribuer le même tag aux ressources provenant de différents services pour indiquer que les ressources sont liées.
Vous pouvez baliser les groupes Auto Scaling nouveaux ou existants. Vous pouvez également propager les balises d'un groupe Auto Scaling aux instances EC2 qu'il lance.
Les balises ne sont pas propagées aux volumes Amazon EBS. Pour ajouter des balises aux volumes Amazon EBS, spécifiez les balises dans un modèle de lancement. Pour de plus amples informations, veuillez consulter [Créer un modèle de lancement pour un groupe Auto Scaling](create-launch-template.md).
Vous pouvez créer et gérer des balises via le AWS Management Console AWS CLI, ou SDKs.
**Topics**
+ [Limites d'utilisation et de dénomination des balises](#tag_restrictions)
+ [Cycle de vie de balisage d'instance EC2](#tag-lifecycle)
+ [Baliser vos groupes Auto Scaling](add-tags.md)
+ [Supprimer des balises](delete-tag.md)
+ [Balises pour la sécurité](tag-security.md)
+ [Contrôler l'accès aux balises](tag-permissions.md)
+ [Utilisation d'identifications pour filtrer les groupes Auto Scaling](use-tag-filters-aws-cli.md)
## Limites d'utilisation et de dénomination des balises
Les restrictions de base suivantes s'appliquent aux balises :
+ Le nombre maximum d’identifications par ressource est de 50.
+ Le nombre maximum de balises susceptibles d'être ajoutées ou supprimées avec un seul appel est de 25.
+ La longueur de clé maximale est de 128 caractères Unicode.
+ La longueur de valeur maximale est de 256 caractères Unicode.
+ Les clés et valeurs d’étiquette sont sensibles à la casse. La bonne pratique consiste à choisir une politique pour mettre des balises en majuscule et mettre en œuvre cette politique de manière cohérente sur tous les types de ressources.
+ N'utilisez pas le `aws:` préfixe dans les noms ou les valeurs de vos balises, car il est réservé à AWS l'usage. Vous ne pouvez pas modifier ou supprimer les noms ou valeurs des balises avec ce préfixe, et elles ne sont pas comptées dans vos balises par quota de groupe.
## Cycle de vie de balisage d'instance EC2
Si vous avez choisi de propager des balises vers vos instances EC2, celles-ci sont gérées comme suit :
+ Lorsqu'un groupe Auto Scaling lance des instances, il ajoute les balises aux instances lors de la création de ressources plutôt qu'après la création de la ressource.
+ Le groupe Auto Scaling ajoute automatiquement une identification aux instances avec une clé `aws:autoscaling:groupName` et une valeur du nom du groupe Auto Scaling.
+ Si vous spécifiez des balises d'instance dans votre modèle de lancement et que vous avez choisi de propager les balises de votre groupe à ses instances, toutes les balises sont fusionnées. Si la même clé d'identification est spécifiée pour une identification dans votre modèle de lancement et une identification dans votre groupe Auto Scaling, la valeur de l'identification du groupe est prioritaire.
+ Lorsque vous attachez des instances existantes, le groupe Auto Scaling ajoute les balises aux instances en remplaçant les anciennes balises par la même clé de balise. Il ajoute également une identification avec une clé de `aws:autoscaling:groupName` et une valeur du nom du groupe Auto Scaling.
+ Quand vous détachez une instance d'un groupe Auto Scaling, celui-ci ne supprime que la balise `aws:autoscaling:groupName`.
# Baliser vos groupes Auto Scaling
Lorsque vous ajoutez une balise au groupe Auto Scaling, vous pouvez spécifier si elle doit être ajoutée aux instances lancées dans le groupe Auto Scaling. Si vous modifiez une balise, la version mise à jour de la balise est ajoutée aux instances lancées dans le groupe Auto Scaling après le changement. Si vous créez ou modifiez une balise pour un groupe Auto Scaling, ces changements ne sont pas appliqués aux instances déjà en cours d'exécution dans le groupe Auto Scaling.
**Topics**
+ [Ajouter ou modifier des balises (console)](#add-tags-console)
+ [Ajouter ou modifier des balises (AWS CLI)](#add-tags-aws-cli)
## Ajouter ou modifier des balises (console)
**Pour étiqueter un groupe Auto Scaling lors de la création**
Lorsque vous utilisez la console Amazon EC2 pour créer un groupe Auto Scaling, vous pouvez spécifier les clés et les valeurs des balises sur la page **Add tags (Ajouter des balises)** de l'assistant Create Auto Scaling group (Créer un groupe Auto Scaling). Pour propager une balise aux instances lancées dans le groupe Auto Scaling, assurez-vous que vous conservez l'option **Tag new instances (Baliser les nouvelles instances)** pour cette balise sélectionnée. Sinon, vous pouvez la désactiver.
**Pour ajouter ou modifier des balises pour un groupe Auto Scaling existant**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Cochez la case située en regard du groupe Auto Scaling.
Un volet fractionné s'ouvre en bas de la page **Auto Scaling groups** (Groupes Auto Scaling).
1. Sous l'onglet **Details** (Détails) choisissez **Tags** (Balises), **Edit** (Modifier).
1. Pour modifier des identifications existantes, modifiez **Key (Clé)** et **Value (Valeur)**.
1. Pour ajouter une nouvelle identification, choisissez **Add tag (Ajouter une identification)** et modifiez **Key (Clé)** et **Value (Valeur)**. Vous pouvez continuer de sélectionner l'option **Tag New Instances (Baliser les nouvelles instances)** pour ajouter automatiquement la balise aux instances lancées dans le groupe Auto Scaling, sinon annulez sa sélection.
1. Lorsque vous avez fini d'ajouter des balises, choisissez **Update** (Mettre à jour).
## Ajouter ou modifier des balises (AWS CLI)
Les exemples suivants montrent comment utiliser le AWS CLI pour ajouter des balises lorsque vous créez des groupes Auto Scaling et pour ajouter ou modifier des balises pour des groupes Auto Scaling existants.
**Pour étiqueter un groupe Auto Scaling lors de la création**
Utilisez la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande pour créer un nouveau groupe Auto Scaling et ajouter une balise, par exemple**environment=production**, au groupe Auto Scaling. La balise est également ajoutée aux instances lancées dans le groupe Auto Scaling.
```
aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg \
--launch-configuration-name my-launch-config --min-size 1 --max-size 3 \
--vpc-zone-identifier "subnet-5ea0c127,subnet-6194ea3b,subnet-c934b782" \
--tags Key=environment,Value=production,PropagateAtLaunch=true
```
**Pour créer ou modifier des balises pour un groupe Auto Scaling existant**
Utilisez la commande [create-or-update-tags](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-or-update-tags.html) pour créer ou modifier une balise. Par exemple, la commande suivante ajoute les balises `Name=my-asg` et `costcenter=cc123`. Les balises sont également ajoutées aux instances lancées dans le groupe Auto Scaling après cette modification. Si une balise avec cette clé existe déjà, la balise existante est remplacée. La console Amazon EC2 associe le nom d'affichage de chaque instance avec le nom spécifié pour la clé `Name` (sensible à la casse).
```
aws autoscaling create-or-update-tags \
--tags ResourceId=my-asg,ResourceType=auto-scaling-group,Key=Name,Value=my-asg,PropagateAtLaunch=true \
ResourceId=my-asg,ResourceType=auto-scaling-group,Key=costcenter,Value=cc123,PropagateAtLaunch=true
```
### Décrire les balises d'un groupe Auto Scaling (AWS CLI)
Si vous souhaitez afficher les balises qui sont appliquées à un groupe Auto Scaling spécifique, vous pouvez utiliser l'une des commandes suivantes :
+ [describe-tags](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-tags.html) — Vous indiquez le nom de votre groupe Auto Scaling pour afficher la liste des balises du groupe spécifié.
```
aws autoscaling describe-tags --filters Name=auto-scaling-group,Values=my-asg
```
Voici un exemple de réponse.
```
{
"Tags": [
{
"ResourceType": "auto-scaling-group",
"ResourceId": "my-asg",
"PropagateAtLaunch": true,
"Value": "production",
"Key": "environment"
}
]
}
```
+ [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html)— Vous indiquez le nom de votre groupe Auto Scaling pour afficher les attributs du groupe spécifié, y compris les balises éventuelles.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name my-asg
```
Voici un exemple de réponse.
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg",
"AutoScalingGroupARN": "arn",
"LaunchTemplate": {
"LaunchTemplateId": "lt-0b97f1e282EXAMPLE",
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 1,
...
"Tags": [
{
"ResourceType": "auto-scaling-group",
"ResourceId": "my-asg",
"PropagateAtLaunch": true,
"Value": "production",
"Key": "environment"
}
],
...
}
]
}
```
# Supprimer des balises
Vous pouvez supprimer une balise associée au groupe Auto Scaling à tout moment.
**Topics**
+ [Supprimer des balises (console)](#delete-tag-console)
+ [Supprimer des balises (AWS CLI)](#delete-tag-aws-cli)
## Supprimer des balises (console)
**Pour supprimer une balise**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Activez la case à cocher en regard d'un groupe existant.
Un volet fractionné s'ouvre en bas de la page **Auto Scaling groups** (Groupes Auto Scaling).
1. Sous l'onglet **Details** (Détails) choisissez **Tags** (Balises), **Edit** (Modifier).
1. Choisissez **Remove** (Supprimer) en regard de la balise.
1. Choisissez **Mettre à jour**.
## Supprimer des balises (AWS CLI)
Utilisez la commande [delete-tags](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-tags.html) pour supprimer une balise. Par exemple, la commande suivante supprime une balise avec une clé `environment`.
```
aws autoscaling delete-tags --tags "ResourceId=my-asg,ResourceType=auto-scaling-group,Key=environment"
```
Vous devez préciser la clé de balise, mais pas la valeur. Si vous spécifiez une valeur et qu'elle est incorrecte, la balise n'est pas supprimée.
# Balises pour la sécurité
Utilisez des balises pour vérifier que le demandeur (tel qu'un utilisateur ou un rôle IAM) dispose des autorisations de créer, modifier ou supprimer des groupes Auto Scaling spécifiques. Fournissez des informations de balise dans l'élément de condition d'une politique IAM à l'aide des clés de condition suivantes :
+ Utilisez `autoscaling:ResourceTag/tag-key: tag-value` pour accorder (ou refuser) aux utilisateurs des actions sur des groupes Auto Scaling avec des balises spécifiques.
+ Utilisez `aws:RequestTag/tag-key: tag-value` pour exiger qu'une balise spécifique soit présente (ou non) dans une demande.
+ Utilisez `aws:TagKeys [tag-key, ...]` pour exiger que des clés de balise spécifiques soient présentes (ou non) dans une demande.
Par exemple, vous pouvez refuser l'accès à tous les groupes Auto Scaling qui incluent une balise avec la clé `environment` et la valeur `production`, comme illustré dans l'exemple suivant.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"autoscaling:CreateAutoScalingGroup",
"autoscaling:UpdateAutoScalingGroup",
"autoscaling:DeleteAutoScalingGroup"
],
"Resource": "*",
"Condition": {
"StringEquals": {"autoscaling:ResourceTag/environment": "production"}
}
}
]
}
```
------
Pour plus d’informations sur l’utilisation des clés de condition afin de contrôler l’accès aux groupes Auto Scaling, consultez [Fonctionnement d'Amazon EC2 Auto Scaling avec IAM](control-access-using-iam.md).
# Contrôler l'accès aux balises
Utilisez des balises pour vérifier que le demandeur (tel qu'un utilisateur ou un rôle IAM) dispose des autorisations d'ajouter, modifier ou supprimer des balises pour des groupes Auto Scaling.
L’exemple de politique IAM suivant donne l’autorisation principale de supprimer uniquement la balise avec la clé `temporary` des groupes Auto Scaling.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "autoscaling:DeleteTags",
"Resource": "*",
"Condition": {
"ForAllValues:StringEquals": { "aws:TagKeys": ["temporary"] }
}
}
]
}
```
------
Pour plus d’exemples de politiques IAM qui appliquent des contraintes sur les balises spécifiées pour les groupes Auto Scaling, consultez [Contrôler les clés de balise et les valeurs de balise pouvant être utilisées](security_iam_id-based-policy-examples.md#policy-example-tags).
**Note**
Même si vous disposez d'une politique qui empêche vos utilisateurs d'exécuter une opération d'étiquetage (ou d'annulation de désétiquetage) sur un groupe Auto Scaling, cela ne les empêche pas de modifier manuellement les identifications sur les instances après les avoir lancées. Pour des exemples qui contrôlent l'accès aux balises sur les instances EC2, consultez [Exemple : ressources de balisage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ExamplePolicies_EC2.html#iam-example-taggingresources) dans le guide de l'utilisateur *Amazon EC2*.
# Utilisation d'identifications pour filtrer les groupes Auto Scaling
Les exemples suivants vous montrent comment utiliser des filtres avec la [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html)commande pour décrire les groupes Auto Scaling dotés de balises spécifiques. Le filtrage par balises est limité au SDK AWS CLI ou à un SDK et n'est pas disponible depuis la console.
**Considérations relatives au filtrage**
+ Vous pouvez spécifier plusieurs filtres et plusieurs valeurs de filtre dans une seule requête.
+ Vous ne pouvez pas utiliser des caractères génériques avec les valeurs de filtre.
+ Les valeurs de filtre sont sensibles à la casse.
**Exemple : décrire les groupes Auto Scaling avec une paire clé-valeur d'identification spécifique**
La commande suivante montre comment filtrer les résultats pour n'afficher que les groupes Auto Scaling dont la paire clé/valeur d'identification est **`environment=production`**.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment Name=tag-value,Values=production
```
Voici un exemple de réponse.
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg",
"AutoScalingGroupARN": "arn",
"LaunchTemplate": {
"LaunchTemplateId": "lt-0b97f1e282EXAMPLE",
"LaunchTemplateName": "my-launch-template",
"Version": "$Latest"
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 1,
...
"Tags": [
{
"ResourceType": "auto-scaling-group",
"ResourceId": "my-asg",
"PropagateAtLaunch": true,
"Value": "production",
"Key": "environment"
}
],
...
},
... additional groups ...
]
}
```
Vous pouvez également spécifier des identifiants à l'aide d'un filtre `tag:`. Par exemple, la commande suivante montre comment filtrer les résultats pour n'afficher que les groupes Auto Scaling avec une paire clé et valeur d'identification de **`environment=production`**. Ce filtre est formaté comme suit : `Name=tag:,Values=`, avec **** et **** représentant une paire clé et valeur d'identification.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag:environment,Values=production
```
Vous pouvez également filtrer la AWS CLI sortie à l'aide de l'`--query`option. L'exemple suivant montre comment limiter la AWS CLI sortie de la commande précédente au nom du groupe, à la taille minimale, à la taille maximale et aux attributs de capacité souhaités uniquement.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag:environment,Values=production \
--query "AutoScalingGroups[].{AutoScalingGroupName: AutoScalingGroupName, MinSize: MinSize, MaxSize: MaxSize, DesiredCapacity: DesiredCapacity}"
```
Voici un exemple de réponse.
```
[
{
"AutoScalingGroupName": "my-asg",
"MinSize": 0,
"MaxSize": 10,
"DesiredCapacity": 1
},
... additional groups ...
]
```
Pour plus d'informations sur le filtrage, consultez la section [Filtrage AWS CLI de la sortie](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-filter.html) dans le *guide de AWS Command Line Interface l'utilisateur*.
**Exemple : décrire les groupes Auto Scaling dont les identifications correspondent à la clé d'identification spécifiée**
La commande suivante montre comment filtrer les résultats pour afficher uniquement les groupes Auto Scaling avec l'identification `environment`, quelle que soit la valeur de l'identification.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment
```
**Exemple : décrire les groupes d'Auto Scaling dont les identifications correspondent à l'ensemble des clés d'identification spécifiées**
La commande suivante montre comment filtrer les résultats pour afficher uniquement les groupes Auto Scaling avec des identifications pour `environment` et `project`, quelle que soit la valeur de l'identification.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment Name=tag-key,Values=project
```
**Exemple : décrire les groupes Auto Scaling dont les identifications correspondent à au moins une des clés d'identification spécifiées**
La commande suivante montre comment filtrer les résultats pour afficher uniquement les groupes Auto Scaling avec des identifications pour `environment` ou `project`, quelle que soit la valeur de l'identification.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-key,Values=environment,project
```
**Exemple : décrire les groupes Auto Scaling avec la valeur d'identification spécifiée**
La commande suivante montre comment filtrer les résultats pour afficher uniquement les groupes Auto Scaling dont la valeur de l'identification est `production`, quelle que soit la clé de l'identification.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-value,Values=production
```
**Exemple : décrire les groupes Auto Scaling avec l'ensemble des valeurs d'identification spécifiées**
La commande suivante montre comment filtrer les résultats pour afficher uniquement les groupes Auto Scaling dont l'identification est `production` et `development`, quelle que soit la clé d'identification.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-value,Values=production Name=tag-value,Values=development
```
**Exemple : décrire les groupes Auto Scaling dont les identifications correspondent à au moins une des valeurs d'identification spécifiées**
La commande suivante montre comment filtrer les résultats pour afficher uniquement les groupes Auto Scaling dont la valeur de l'identification est `production` ou `development`, quelle que soit la clé de l'identification.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag-value,Values=production,development
```
**Exemple : décrire les groupes d'Auto Scaling dont les identifications correspondent à plusieurs clés et valeurs d'identification**
Vous pouvez également combiner des filtres pour créer une logique AND et OR personnalisée pour effectuer un filtrage plus complexe.
La commande suivante montre comment filtrer les résultats pour afficher uniquement les groupes Auto Scaling avec un ensemble spécifique d'identifications. Une clé d'identification est `environment` AND la valeur de l'identification est (`production` OR `development`) AND l'autre clé d'identification est `costcenter` AND la valeur de l'identification est `cc123`.
```
aws autoscaling describe-auto-scaling-groups \
--filters Name=tag:environment,Values=production,development Name=tag:costcenter,Values=cc123
```
# Politiques de maintenance des instances
Vous pouvez configurer une politique de maintenance des instances pour votre groupe Auto Scaling afin de répondre à des exigences de capacité spécifiques lors d’événements entraînant le remplacement d’instances, tels que l’actualisation d’une instance ou le processus de surveillance de l’état.
Supposons que vous possédez un groupe Auto Scaling qui contient un petit nombre d’instances. Vous souhaitez éviter les perturbations potentielles liées à la résiliation puis au remplacement d’une instance lorsque les surveillances de l’état indiquent qu’une instance est défectueuse. Avec une politique de maintenance des instances, vous pouvez vous assurer qu’Amazon EC2 Auto Scaling lance d’abord une nouvelle instance, puis attend qu’elle soit complètement prête avant de résilier l’instance défectueuse.
Une politique de maintenance des instances vous aide également à minimiser les perturbations potentielles dans les cas où plusieurs instances sont remplacées en même temps. Vous définissez les paramètres de pourcentage minimal et maximal d’intégrité de la politique, et votre groupe Auto Scaling ne peut augmenter ou diminuer la capacité dans cette plage minimale-maximale que lors du remplacement d’instances. Une plage étendue augmente le nombre d’instances qui peuvent être remplacées en même temps.
**Topics**
+ [Politique de maintenance des instances pour le groupe Auto Scaling](instance-maintenance-policy-overview-and-considerations.md)
+ [Définir une politique de maintenance des instances pour votre groupe Auto Scaling](set-instance-maintenance-policy-on-group.md)
# Politique de maintenance des instances pour le groupe Auto Scaling
Cette rubrique fournit une vue d’ensemble des options disponibles et décrit les éléments à prendre en compte lorsque vous créez une politique de maintenance d’instance.
**Topics**
+ [Présentation de](#instance-maintenance-policy-overview)
+ [Concepts de base](#instance-maintenance-policy-core-concepts)
+ [Préparation d’instance](#instance-maintenance-policy-instance-warm-up)
+ [Période de grâce de surveillance de l'état](#instance-maintenance-policy-health-check-grace-period)
+ [Mettre à l’échelle votre groupe Auto Scaling](#instance-maintenance-policy-scaling-limits)
+ [Exemples de scénarios](#instance-maintenance-policy-scenarios)
## Présentation de
Lorsque vous créez une politique de maintenance des instances pour votre groupe Auto Scaling, la politique affecte les événements Amazon EC2 Auto Scaling qui entraînent le remplacement des instances. Cela se traduit par des comportements de remplacement plus cohérents au sein du même groupe Auto Scaling. Cela vous permet également d’optimiser la disponibilité ou le coût de votre groupe en fonction de vos besoins.
Les options de configuration suivantes sont disponibles dans la console :
+ **Lancer avant toute résiliation** : une nouvelle instance doit d’abord être mise en service avant qu’une instance existante puisse être résiliée. Cette approche est un bon choix pour les applications qui privilégient la disponibilité plutôt que les économies de coûts.
+ **Résilier et lancer** : les nouvelles instances sont mises en service en même temps que les instances existantes sont résiliées. Cette approche est un bon choix pour les applications qui privilégient les économies de coûts plutôt que la disponibilité. C’est également un bon choix pour les applications qui ne doivent pas libérer plus de capacité que ce qui est actuellement disponible, même lors du remplacement d’instances.
+ **Politique personnalisée** : cette option vous permet de configurer votre politique avec une plage minimale et maximale personnalisée pour la quantité de capacité que vous souhaitez mettre à disposition lors du remplacement d’instances. Cette approche peut vous aider à trouver le juste équilibre entre le coût et la disponibilité.
Par défaut, un groupe Auto Scaling n’a pas de politique de maintenance des instances, ce qui l’oblige à répondre aux événements de maintenance des instances avec les comportements par défaut. Les comportements par défaut sont décrits dans le tableau suivant.
**Comportements par défaut des événements de maintenance des instances**
| Événement | Description | Comportement par défaut |
| --- | --- | --- |
| Échec de la surveillance de l’état | Cela se produit automatiquement lorsque les instances échouent à leurs surveillances de l’état. Amazon EC2 Auto Scaling remplace les instances qui échouent à leurs surveillances de l’état. Pour comprendre les causes des échecs liés aux surveillances de l’état, consultez [Surveillance de l’état des instances dans un groupe Auto Scaling](ec2-auto-scaling-health-checks.md). | Résilier et lancer. |
| Actualisation d'instance | Se produit lorsque vous actualisez une instance. En fonction de votre configuration, une actualisation d’instance remplace les instances une par une, plusieurs à la fois ou toutes à la fois. Pour de plus amples informations, veuillez consulter [Utiliser une actualisation d'instance pour mettre à jour les instances d'un groupe Auto Scaling](asg-instance-refresh.md). | Résilier et lancer. |
| Durée de vie maximale de l'instance | Cela se produit automatiquement lorsque les instances atteignent la durée de vie maximale que vous indiquez pour votre groupe Auto Scaling. Amazon EC2 Auto Scaling remplace les instances qui atteignent leur durée de vie maximale. Pour de plus amples informations, veuillez consulter [Remplacer des instances Auto Scaling en fonction de la durée de vie maximale de l’instance](asg-max-instance-lifetime.md). | Résilier et lancer. |
| Rééquilibrage | Cela se produit automatiquement si des changements sous-jacents entraînent un déséquilibre du groupe. Amazon EC2 Auto Scaling rééquilibre le groupe dans les situations suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/instance-maintenance-policy-overview-and-considerations.html) | Lancer avant toute résiliation. Amazon EC2 Auto Scaling peut dépasser les limites de taille de votre groupe jusqu’à 10 % de sa *capacité maximale*. Toutefois, si vous utilisez le rééquilibrage de la capacité, il ne peut dépasser ces limites que de 10 % de la *capacité souhaitée.* |
Amazon EC2 Auto Scaling continuera à être résilié et lancé par défaut dans les situations suivantes. Par conséquent, lorsque l’une de ces situations se produit, la capacité de votre groupe peut être inférieure au seuil inférieur de votre politique de maintenance des instances.
+ Lorsqu’une instance est résiliée de façon inattendue, par exemple en raison d’une action humaine. Amazon EC2 Auto Scaling remplace les instances qui ne fonctionnent plus. Pour de plus amples informations, veuillez consulter [Surveillance de l'état Amazon EC2](health-checks-overview.md#instance-health-detection).
+ Lorsqu’Amazon EC2 redémarre, arrête ou retire une instance dans le cadre d’un événement planifié avant qu’Amazon EC2 Auto Scaling ne puisse lancer l’instance de remplacement. Pour plus d'informations sur ces événements, consultez la section [Événements planifiés pour vos instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html) dans le guide de l'*utilisateur Amazon EC2*.
+ Lorsque le service Amazon EC2 Spot initie une interruption d’instance Spot et qu’une instance Spot est ensuite résiliée de force.
Avec les instances Spot, si vous avez activé le rééquilibrage de la capacité sur votre groupe Auto Scaling, l’instance possède peut-être déjà une instance en attente provenant d’un autre groupe Spot que nous avons lancé avant de démarrer l’interruption Spot. Pour de plus amples informations sur le fonctionnement du rééquilibrage de la capacité, consultez [Rééquilibrage des capacités dans Auto Scaling pour remplacer les instances ponctuelles à risque](ec2-auto-scaling-capacity-rebalancing.md).
Cependant, étant donné que la disponibilité des instances Spot n’est pas garantie et qu’elles peuvent être résiliées moyennant un préavis d’interruption de deux minutes, le seuil inférieur de votre politique de maintenance des instances peut être dépassé si les instances sont interrompues avant le lancement de vos nouvelles instances.
## Concepts de base
Avant de commencer, familiarisez-vous avec les principaux concepts et termes suivants :
**Capacité souhaitée**
La *Capacité souhaitée* correspond à la capacité initiale du groupe Auto Scaling à sa création. Il s’agit également de la capacité que le groupe essaye de maintenir lorsqu’aucune condition de dimensionnement n’est attachée au groupe.
**Politique de maintenance des instances**
Une *politique de maintenance des instances* contrôle si une instance est d’abord mise en service avant qu’une instance existante ne soit résiliée en cas d’événements de maintenance de l’instance. Elle détermine également jusqu’où votre groupe Auto Scaling peut aller en dessous et au-dessus de la capacité souhaitée pour remplacer plusieurs instances en même temps.
**Pourcentage maximal d’intégrité**
Le *pourcentage maximal d’intégrité* est le pourcentage de la capacité souhaitée que votre groupe Auto Scaling peut atteindre lors du remplacement d’instances. Il représente le pourcentage maximal du groupe qui peut être en service et en bon état, ou en attente, pour assurer votre charge de travail. Dans la console, vous pouvez définir le pourcentage maximal d’intégrité lorsque vous utilisez l’option **Lancer avant toute résiliation** ou l’option **Politique personnalisée**. Les valeurs valides sont comprises entre 100 et 200 %.
**Pourcentage minimal d’intégrité**
Le *pourcentage minimal d’intégrité* est le pourcentage de la capacité souhaitée pour rester en service, en bon état et prête à être utilisée pour assurer votre charge de travail lors du remplacement d’instances. Une instance est considérée comme saine et prête à être utilisée une fois qu'elle a effectué avec succès son premier contrôle de santé et que le temps de préchauffage spécifié est écoulé. Dans la console, vous pouvez définir le pourcentage minimal d’intégrité lorsque vous utilisez l’option **Résilier et lancer** ou l’option **Politique personnalisée**. Les valeurs valides sont comprises entre 0 et 100 %.
Pour remplacer les instances plus rapidement, vous pouvez définir un faible pourcentage minimal d’intégrité. Toutefois, s’il n’y a pas suffisamment d’instances saines en cours d’exécution, cela peut réduire la disponibilité. Nous vous recommandons de sélectionner une valeur raisonnable afin de maintenir la disponibilité dans les situations où plusieurs instances doivent être remplacées.
## Préparation d’instance
Si vos instances ont besoin de temps pour s’initialiser une fois qu’elles sont entrées dans l’état `InService`, activez la préparation d’instance par défaut pour votre groupe Auto Scaling. Grâce à la préparation d’instance par défaut, vous pouvez empêcher que les instances ne soient prises en compte dans le calcul du pourcentage minimal d’intégrité avant qu’elles ne soient prêtes. Cela garantit qu’Amazon EC2 Auto Scaling prend en compte le temps nécessaire pour disposer d’une capacité suffisante pour assurer la charge de travail avant de résilier les instances existantes.
L'avantage supplémentaire est que vous pouvez améliorer les CloudWatch métriques Amazon utilisées pour le dimensionnement dynamique lorsque vous activez le préchauffage de l'instance par défaut. Si votre groupe Auto Scaling dispose de politiques de dimensionnement, lorsqu'il évolue, il utilise la même période de préchauffage par défaut pour éviter que les instances ne soient prises en compte dans CloudWatch les métriques avant la fin de leur initialisation.
Pour de plus amples informations, veuillez consulter [Définir la préparation par défaut d'instance d'un groupe Auto Scaling](ec2-auto-scaling-default-instance-warmup.md).
## Période de grâce de surveillance de l'état
Amazon EC2 Auto Scaling détermine si une instance est saine en fonction du statut des surveillances de l'état que votre groupe Auto Scaling utilise. Pour de plus amples informations, veuillez consulter [Surveillance de l’état des instances dans un groupe Auto Scaling](ec2-auto-scaling-health-checks.md).
Pour vous assurer que ces surveillances de l’état commencent le plus rapidement possible, ne définissez pas une période de grâce de la surveillance de l’état du groupe trop élevée, mais suffisamment élevée pour que vos surveillances de l’état Elastic Load Balancing déterminent si une cible est disponible pour traiter les demandes. Pour de plus amples informations, veuillez consulter [Définir la période de grâce de la surveillance de l'état pour un groupe Auto Scaling](health-check-grace-period.md).
## Mettre à l’échelle votre groupe Auto Scaling
Une politique de maintenance des instances s’applique uniquement aux événements de maintenance d’instance et n’empêche pas le redimensionnement manuel ou automatique du groupe.
Lorsque des politiques de mise à l’échelle ou des actions planifiées sont associées à votre groupe Auto Scaling, elles peuvent s’exécuter en parallèle pendant que les événements de maintenance des instances se produisent. Dans ce cas, elles peuvent augmenter ou diminuer la capacité souhaitée du groupe, mais uniquement dans les limites de dimensionnement que vous avez définies. Pour plus d’informations sur ces limites, consultez [Définissez des limites de mise à l’échelle pour votre groupe Auto Scaling](asg-capacity-limits.md).
## Exemples de scénarios
Dans un scénario typique, votre politique de maintenance des instances et la capacité souhaitée peuvent ressembler à ce qui suit :
+ Pourcentage minimal d’intégrité = 90 %
+ Pourcentage maximal d’intégrité = 120 %
+ Capacité souhaitée = 100
Lors d’un événement de maintenance d’instance, votre groupe Auto Scaling peut compter entre 90 et 120 instances. Après l’événement, le groupe compte à nouveau 100 instances.
Lorsque vous utilisez une politique de maintenance des instances avec un groupe Auto Scaling doté d’un groupe chaud, les pourcentages minimal et maximal d’intégrité sont appliqués séparément au groupe Auto Scaling et au groupe chaud.
Supposons qu’il s’agisse de votre configuration :
+ Pourcentage minimal d’intégrité = 90 %
+ Pourcentage maximal d’intégrité = 120 %
+ Capacité souhaitée = 100
+ Taille d’un groupe chaud = 10
Si vous lancez une actualisation d’instance pour recycler les instances du groupe, Amazon EC2 Auto Scaling remplace d’abord les instances du groupe Auto Scaling, puis les instances du groupe chaud. Alors qu’Amazon EC2 Auto Scaling travaille toujours au remplacement des instances du groupe Auto Scaling, le groupe peut compter entre 90 et 120 instances. Une fois la préparation du groupe terminée, Amazon EC2 Auto Scaling peut remplacer les instances du groupe chaud. Pendant ce temps, le groupe chaud peut compter entre 9 et 12 instances.
# Définir une politique de maintenance des instances pour votre groupe Auto Scaling
Vous pouvez créer une politique de maintenance des instances au moment de la création d’un groupe Auto Scaling. Vous pouvez également la créer pour les groupes existants.
En définissant une politique de maintenance des instances pour votre groupe Auto Scaling, vous n’avez plus à indiquer de valeurs pour les paramètres de pourcentage minimal et maximal d’intégrité de la fonction d’actualisation des instances, sauf si vous souhaitez remplacer la politique de maintenance des instances.
Dans la console, Amazon EC2 Auto Scaling fournit des options pour vous aider à démarrer.
**Topics**
+ [Définir une politique de maintenance des instances](set-instance-maintenance-policy.md)
+ [Supprimer une politique de maintenance des instances](remove-instance-maintenance-policy.md)
# Définir une politique de maintenance des instances
Pour définir une politique de maintenance des instances pour un groupe Auto Scaling, appliquez l’une des méthodes suivantes :
------
#### [ Console ]
**Pour définir une politique de maintenance des instances pour un nouveau groupe (console)**
1. Suivez les instructions de la rubrique [Créer un groupe Auto Scaling avec un modèle de lancement](create-asg-launch-template.md) et terminez chaque étape de la procédure, jusqu’à l’étape 11.
1. Sur la page **Configurer la taille du groupe et les politiques de mise à l’échelle**, pour la **capacité souhaitée**, saisissez le nombre initial d’instances à lancer.
1. Dans la section **Mise à l’échelle**, sous **Limites de mise à l’échelle**, si votre nouvelle valeur pour la **capacité souhaitée** est supérieure à la **capacité minimale souhaitée** et à la **capacité maximale souhaitée**, la **capacité maximale souhaitée** est automatiquement augmentée à la nouvelle valeur de capacité souhaitée. Vous pouvez modifier ces limites si nécessaire.
1. Pour le **dimensionnement automatique**, indiquez si vous souhaitez créer une politique de dimensionnement de suivi des cibles. Vous pouvez également élaborer cette politique après avoir créé votre groupe Auto Scaling.
Si vous choisissez la **politique de dimensionnement de suivi des cibles**, suivez les instructions dans [Création d'une politique de suivi des cibles et d'échelonnement](policy_creating.md) pour créer la politique.
1. Dans la section **Politique de maintenance des instances**, choisissez l’une des options disponibles :
+ **Lancer avant toute résiliation** : une nouvelle instance doit d’abord être mise en service avant qu’une instance existante puisse être résiliée. Il s’agit d’un bon choix pour les applications qui privilégient la disponibilité plutôt que les économies de coûts.
+ **Résilier et lancer** : les nouvelles instances sont mises en service en même temps que les instances existantes sont résiliées. Il s’agit d’un bon choix pour les applications qui privilégient les économies de coûts plutôt que la disponibilité. C’est également un bon choix pour les applications qui ne doivent pas libérer plus de capacité que ce qui est actuellement disponible.
+ **Politique personnalisée** : cette option vous permet de configurer votre politique avec une plage minimale et maximale personnalisée pour la quantité de capacité que vous souhaitez mettre à disposition lors du remplacement d’instances. Cela peut vous aider à trouver le juste équilibre entre le coût et la disponibilité.
1. Pour **Définir un pourcentage d’intégrité**, saisissez des valeurs pour l’un ou les deux champs suivants. Les champs activés varient en fonction de l’option que vous avez choisie à l’étape précédente.
+ **Min** : définit le pourcentage minimal d’intégrité requis pour procéder au remplacement des instances.
+ **Max** : définit le pourcentage maximal d’intégrité possible lors du remplacement d’instances.
1. Développez la section **Afficher la capacité pendant les remplacements en fonction de la capacité souhaitée** pour confirmer comment les valeurs **Min** et **Max** s’appliquent à votre groupe. Les valeurs exactes utilisées dépendent de la valeur de capacité souhaitée, qui changera si le groupe est mis à l’échelle.
1. Poursuivez en effectuant les étapes de la section [Créer un groupe Auto Scaling avec un modèle de lancement](create-asg-launch-template.md).
------
#### [ AWS CLI ]
**Pour définir une politique de maintenance des instances pour un nouveau groupe (AWS CLI)**
Ajoutez l'`--instance-maintenance-policy`option à la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande. L’exemple suivant définit une politique de maintenance des instances pour un nouveau groupe Auto Scaling intitulé `my-asg`.
```
aws autoscaling create-auto-scaling-group \
--launch-template LaunchTemplateName=my-launch-template,Version='1' \
--auto-scaling-group-name my-asg \
--min-size 1 \
--max-size 10 \
--desired-capacity 5 \
--default-instance-warmup 20 \
--instance-maintenance-policy '{
"MinHealthyPercentage": 90,
"MaxHealthyPercentage": 120
}' \
--vpc-zone-identifier "subnet-5e6example,subnet-613example,subnet-c93example"
```
------
------
#### [ Console ]
**Pour définir une politique de maintenance des instances pour un groupe existant (console)**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Dans la barre de navigation située en haut de l'écran, choisissez l' Région AWS dans laquelle vous avez créé votre groupe Auto Scaling.
1. Cochez la case située en regard du groupe Auto Scaling.
Un volet fractionné s’ouvre en bas de la page.
1. Dans l’onglet **Détails**, choisissez **Politique de maintenance des instances**, puis **Modifier**.
1. Pour définir une politique de maintenance des instances pour le groupe, choisissez l’une des options disponibles :
+ **Lancer avant toute résiliation** : une nouvelle instance doit d’abord être mise en service avant qu’une instance existante puisse être résiliée. Il s’agit d’un bon choix pour les applications qui privilégient la disponibilité plutôt que les économies de coûts.
+ **Résilier et lancer** : les nouvelles instances sont mises en service en même temps que les instances existantes sont résiliées. Il s’agit d’un bon choix pour les applications qui privilégient les économies de coûts plutôt que la disponibilité. C’est également un bon choix pour les applications qui ne doivent pas libérer plus de capacité que ce qui est actuellement disponible.
+ **Politique personnalisée** : cette option vous permet de configurer votre politique avec une plage minimale et maximale personnalisée pour la quantité de capacité que vous souhaitez mettre à disposition lors du remplacement d’instances. Cela peut vous aider à trouver le juste équilibre entre le coût et la disponibilité.
1. Pour **Définir un pourcentage d’intégrité**, saisissez des valeurs pour l’un ou les deux champs suivants. Les champs activés varient en fonction de l’option que vous avez choisie à l’étape précédente.
+ **Min** : définit le pourcentage minimal d’intégrité requis pour procéder au remplacement des instances.
+ **Max** : définit le pourcentage maximal d’intégrité possible lors du remplacement d’instances.
1. Développez la section **Afficher la capacité pendant les remplacements en fonction de la capacité souhaitée** pour confirmer comment les valeurs **Min** et **Max** s’appliquent à votre groupe. Les valeurs exactes utilisées dépendent de la valeur de capacité souhaitée, qui changera si le groupe est mis à l’échelle.
1. Choisissez **Mettre à jour**.
------
#### [ AWS CLI ]
**Pour définir une politique de maintenance des instances pour un groupe existant (AWS CLI)**
Ajoutez l'`--instance-maintenance-policy`option à la [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)commande. L’exemple suivant définit une politique de maintenance des instances pour le groupe Auto Scaling indiqué.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \
--instance-maintenance-policy '{
"MinHealthyPercentage": 90,
"MaxHealthyPercentage": 120
}'
```
------
# Supprimer une politique de maintenance des instances
Si vous souhaitez arrêter d’utiliser une politique de maintenance des instances dans votre groupe Auto Scaling, vous pouvez la supprimer.
------
#### [ Console ]
**Pour supprimer une politique de maintenance des instances (console)**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Dans la barre de navigation située en haut de l'écran, choisissez l' Région AWS dans laquelle vous avez créé votre groupe Auto Scaling.
1. Cochez la case située en regard du groupe Auto Scaling.
Un volet fractionné s’ouvre en bas de la page.
1. Dans l’onglet **Détails**, choisissez **Politique de maintenance des instances**, puis **Modifier**.
1. Choisissez **Aucune politique de maintenance des instances**.
1. Choisissez **Mettre à jour**.
------
#### [ AWS CLI ]
**Pour supprimer une politique de maintenance des instances (AWS CLI)**
Ajoutez l'`--instance-maintenance-policy`option à la [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)commande. L’exemple suivant supprime la politique de maintenance des instances du groupe Auto Scaling indiqué.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \
--instance-maintenance-policy '{
"MinHealthyPercentage": -1,
"MaxHealthyPercentage": -1
}'
```
------
# Hooks de cycle de vie Amazon EC2 Auto Scaling
Amazon EC2 Auto Scaling vous permet d'ajouter des hooks de cycle de vie à vos groupes Auto Scaling. Ces hooks vous permettent de créer des solutions qui sont informées des événements du cycle de vie des instances Auto Scaling, puis d'exécuter une action personnalisée sur les instances lorsque l'événement du cycle de vie correspondant se produit. Un hook de cycle de vie fournit à l'action de cycle de vie un délai (défini par défaut sur une heure) pour attendre que l'action se termine avant que l'instance ne passe à l'état suivant.
Exemple d'utilisation de hooks de cycle de vie avec des instances Auto Scaling :
+ Lorsqu'un événement de montée en puissance se produit, l'instance nouvellement lancée termine sa séquence de démarrage et passe à un état d'attente. Pendant que l'instance est en attente, elle exécute un script pour télécharger et installer les packages logiciels nécessaires à votre application afin d'être entièrement prête pour commencer à recevoir du trafic. Au terme de l'installation du logiciel, le script envoie la commande **complete-lifecycle-action** pour poursuivre le processus.
+ Lorsqu'un événement de scale-in se produit, un hook du cycle de vie suspend l'instance avant qu'elle ne soit résiliée et vous envoie une notification via Amazon. EventBridge Lorsque l'instance est en état d'attente, vous pouvez appeler une AWS Lambda fonction ou vous connecter à l'instance pour télécharger des journaux ou d'autres données avant que l'instance ne soit complètement arrêtée.
Les hooks de cycle de vie sont souvent utilisés pour déterminer à quel moment les instances sont enregistrées auprès d'Elastic Load Balancing. En ajoutant un hook de cycle de vie de lancement à votre groupe Auto Scaling, vous pouvez vérifier que vos scripts d'amorçage se sont déroulés avec succès et que les applications présentes sur les instances sont prêtes à accepter le trafic avant d'être enregistrées auprès de l'équilibreur de charge à la fin du hook de cycle de vie.
**Topics**
+ [Disponibilité des hooks de cycle de vie](#lifecycle-hooks-availability)
+ [Considérations et restrictions](#lifecycle-hook-considerations)
+ [Ressources connexes](#lifecycle-hook-related-resources)
+ [Comment fonctionnent les hooks du cycle de vie dans les groupes Auto Scaling](lifecycle-hooks-overview.md)
+ [Vous préparer à ajouter un hook de cycle de vie](prepare-for-lifecycle-notifications.md)
+ [Contrôlez la rétention des instances grâce aux politiques de cycle de vie des instances](instance-lifecycle-policy.md)
+ [Récupérer l'état du cycle de vie cible](retrieving-target-lifecycle-state-through-imds.md)
+ [Ajoutez des hooks de cycle de vie à votre groupe Auto Scaling](adding-lifecycle-hooks.md)
+ [Réaliser une action du cycle de vie dans un groupe Auto Scaling](completing-lifecycle-hooks.md)
+ [Tutoriel : Utiliser les métadonnées de l'instance pour récupérer l'état du cycle de vie](tutorial-lifecycle-hook-instance-metadata.md)
+ [Didacticiel : configurer un hook de cycle de vie qui appelle une fonction Lambda](tutorial-lifecycle-hook-lambda.md)
## Disponibilité des hooks de cycle de vie
Le tableau suivant répertorie les hooks de cycle de vie disponibles en fonction des différents scénarios.
| Événement | Lancement ou résiliation d'instance¹ | [Durée de vie maximale de l'instance](asg-max-instance-lifetime.md) : instances de remplacement | [Actualisation d'instance](asg-instance-refresh.md) : instances de remplacement | [Rééquilibrage de la capacité](ec2-auto-scaling-capacity-rebalancing.md) : instances de remplacement | [Groupes d'instances pré-initialisées](ec2-auto-scaling-warm-pools.md) : instances entrant et sortant du groupe d'instances pré-initialisées |
| --- | --- | --- | --- | --- | --- |
| Lancement d'une instance | ✓ | ✓ | ✓ | ✓ | ✓ |
| Résiliation d'une instance | ✓ | ✓ | ✓ | ✓ | ✓ |
¹ S’applique à tous les lancements et toutes les résiliations, qu’ils/elles soient initié(e)s automatiquement ou manuellement, par exemple lorsque vous appelez les opérations `SetDesiredCapacity` ou `TerminateInstanceInAutoScalingGroup`. Ne s'applique pas lorsque vous attachez ou détachez des instances, placez des instances en mode veille ou sortez des instances du mode veille, ou supprimez le groupe avec l'option Forcer la suppression.
## Considérations et restrictions relatives aux hooks de cycle de vie
Lorsque vous utilisez des hooks de cycle de vie, tenez compte des remarques et limitations suivantes :
+ Amazon EC2 Auto Scaling fournit son propre cycle de vie pour faciliter la gestion des groupes Auto Scaling. Ce cycle de vie se distingue de celui des autres instances EC2. Pour de plus amples informations, veuillez consulter [Cycle de vie d'une instance Amazon EC2 Auto Scaling](ec2-auto-scaling-lifecycle.md). Les instances d'un groupe d'instances pré-initialisées ont également leur propre cycle de vie, tel que décrit dans [Transitions de l'état du cycle de vie pour les instances dans un groupe d'instances pré-initialisées](warm-pool-instance-lifecycle.md#lifecycle-state-transitions).
+ Par défaut, les hooks du cycle de vie des résiliations fonctionnent au mieux. Si un raccordement au cycle de vie de résiliation arrive à expiration ou est abandonné, Amazon EC2 Auto Scaling met immédiatement fin à l'instance. Vous pouvez combiner les hooks du cycle de vie de résiliation avec une politique de cycle de vie des instances pour la rétention des instances. Pour de plus amples informations, veuillez consulter [Contrôlez la rétention des instances grâce aux politiques de cycle de vie des instances](instance-lifecycle-policy.md).
+ Vous pouvez utiliser des hooks de cycle de vie avec des instances Spot, mais un hook de cycle de vie n'empêche pas la résiliation d'une instance lorsque la capacité requise n'est plus disponible, ce qui peut arriver à tout moment avec un préavis d'interruption de deux minutes. Pour plus d'informations, consultez la section [Interruptions des instances Spot](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-interruptions.html) dans le *guide de l'utilisateur Amazon EC2*. Cependant, vous pouvez activer le rééquilibrage des capacités pour remplacer de manière proactive les instances Spot qui ont reçu une recommandation de rééquilibrage du service Amazon EC2 Spot, un signal envoyé lorsqu'une instance Spot présente un risque élevé d'interruption. Pour de plus amples informations, veuillez consulter [Rééquilibrage des capacités dans Auto Scaling pour remplacer les instances ponctuelles à risque](ec2-auto-scaling-capacity-rebalancing.md).
+ Les instances peuvent rester en état d'attente pour une durée limitée. Le délai d'expiration par défaut pour un hook de cycle de vie est d'une heure (délai de pulsation). Il existe également un délai d'attente global spécifiant la durée maximale de conservation d'une instance en état d'attente. Le délai d'attente global est de 48 heures ou de 100 fois le délai de pulsation, la valeur la plus faible étant retenue.
+ À la fin du hook de cycle de vie, le résultat est abandonner ou continuer. Si une instance est en cours de lancement, Continuer indique que les actions ont abouti et qu’Amazon EC2 Auto Scaling peut mettre l’instance en service. Sinon, ABANDONNER indique que les actions personnalisées ont échoué et que nous pouvons résilier et remplacer l’instance. Si une instance est en cours de résiliation, les paramètres Abandonner et Continuer permettent tous les deux de résilier l’instance. Cependant, le paramètre Abandonner met fin aux actions restantes, notamment les autres hooks de cycle de vie, tandis que le paramètre Continuer permet aux autres hooks de cycle de vie d'aller jusqu'à leur terme.
+ Amazon EC2 Auto Scaling limite la vitesse de lancement des instances si les hooks de cycle de vie échouent systématiquement. Assurez-vous donc de tester et de corriger toute erreur permanente dans vos actions de cycle de vie.
+ La création et la mise à jour de hooks de cycle de vie à l'aide du AWS CLI CloudFormation, ou d'un SDK fournissent des options non disponibles lors de la création d'un hook de cycle de vie à partir du AWS Management Console. Par exemple, le champ permettant de spécifier l'ARN d'une rubrique SNS ou d'une file d'attente SQS n'apparaît pas dans la console, car Amazon EC2 Auto Scaling envoie déjà des événements à Amazon. EventBridge Ces événements peuvent être filtrés et redirigés vers AWS des services tels que Lambda, Amazon SNS et Amazon SQS selon les besoins.
+ Vous pouvez ajouter plusieurs hooks de cycle de vie à un groupe Auto Scaling lors de sa création, en appelant l'[CreateAutoScalingGroup](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CreateAutoScalingGroup.html)API à l'aide du AWS CLI CloudFormation, ou d'un SDK. Toutefois, chaque hook doit avoir la même cible de notification et le même rôle IAM, s'il est spécifié. Pour créer des hooks de cycle de vie avec différentes cibles de notification et différents rôles, créez les hooks de cycle de vie un par un dans des appels séparés à l'[PutLifecycleHook](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_PutLifecycleHook.html)API.
+ Si vous ajoutez un hook de cycle de vie pour le lancement d’une instance, la période de grâce de la surveillance de l’état commence dès que l’instance atteint l’état `InService`. Pour de plus amples informations, veuillez consulter [Définir la période de grâce de la surveillance de l'état pour un groupe Auto Scaling](health-check-grace-period.md).
**Considérations relatives à la mise à l'échelle**
+ Les politiques de dimensionnement dynamique s'adaptent en fonction des données CloudWatch métriques, telles que le processeur et les E/S réseau, qui sont agrégées sur plusieurs instances. Lors d’une montée en puissance, Amazon EC2 Auto Scaling ne comptabilise pas immédiatement une nouvelle instance dans les métriques d’instance agrégées du groupe Auto Scaling. Il attend que l’instance atteigne l’état `InService` et que la préparation d’instance soit terminée. Pour plus d’informations, consultez [Considérations sur les performances de la mise à l’échelle](ec2-auto-scaling-default-instance-warmup.md#scaling-performance-considerations) dans la rubrique de préparation d’instance par défaut.
+ À grande échelle, les métriques d'instance agrégées peuvent ne pas refléter instantanément la suppression d'une instance en cours de résiliation. Celle-ci cesse d'être comptabilisée dans les métriques d'instance agrégées du groupe peu après le début du workflow de résiliation d'Amazon EC2 Auto Scaling.
+ Dans la plupart des cas où des hooks de cycle de vie sont appelés, les activités de mise à l’échelle dues à des politiques de mise à l’échelle simple sont suspendues jusqu’à ce que les actions du cycle de vie soient terminées et que le temps de stabilisation ait expiré. Si vous définissez un intervalle long pour le temps de stabilisation, la reprise de la mise à l'échelle prendra plus de temps. Pour plus d’informations, consultez [Les hooks de cycle de vie peuvent entraîner des retards supplémentaires.](ec2-auto-scaling-scaling-cooldowns.md#cooldowns-lifecycle-hooks) dans la rubrique de stabilisation. En général, nous vous déconseillons d’utiliser des politiques de mise à l’échelle simples si vous pouvez plutôt utiliser des politiques de mise à l’échelle d’étape ou de suivi des cibles.
## Ressources connexes
Pour une vidéo de présentation, voir [AWS re:Invent 2018 : Capacity Management Made Easy with Amazon EC2](https://youtu.be/PideBMIcwBQ?t=469) Auto Scaling on. *YouTube*
Nous fournissons quelques extraits de modèles JSON et YAML que vous pouvez utiliser pour comprendre comment déclarer les hooks du cycle de vie dans vos CloudFormation modèles de pile. Pour plus d'informations, consultez la [AWS::AutoScaling::LifecycleHook](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-autoscaling-lifecyclehook.html)référence dans le *guide de AWS CloudFormation l'utilisateur*.
Vous pouvez également consulter notre [GitHubréférentiel](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) pour télécharger des exemples de modèles et de scripts de données utilisateur pour les hooks du cycle de vie.
Pour des exemples d’utilisation des hooks de cycle de vie, consultez les articles de blog suivants.
+ [Création d’un système de sauvegarde pour les instances dimensionnées à l’aide de l’exécution de commande Lambda et Amazon EC2](https://aws.amazon.com/blogs/compute/building-a-backup-system-for-scaled-instances-using-aws-lambda-and-amazon-ec2-run-command/)
+ [Exécutez le code avant de résilier une instance EC2 AutoScaling](https://aws.amazon.com/blogs/infrastructure-and-automation/run-code-before-terminating-an-ec2-auto-scaling-instance/).
# Comment fonctionnent les hooks du cycle de vie dans les groupes Auto Scaling
Une instance Amazon EC2 passe par différents états depuis son lancement jusqu'à sa résiliation. Vous pouvez créer des actions personnalisées correspondant aux réactions de votre groupe Auto Scaling lorsqu’une instance passe à un état d’attente à cause d’un hook de cycle de vie.
L'illustration suivante montre les transitions entre les états des instances d'Auto Scaling lorsque vous utilisez des hooks de cycle de vie pour effectuer une mise à l'échelle externe et une mise à l'échelle interne.
![\[Les transitions entre les états d'une instance Auto Scaling lorsque vous utilisez des hooks de cycle de vie pour effectuer une mise à l'échelle horizontale ou interne.\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/images/how-lifecycle-hooks-work.png)
Comme représenté dans le schéma précédent :
1. Le groupe Auto Scaling répond à un événement de montée en puissance et entame le processus de lancement d'une instance.
1. Le hook de cycle de vie met l'instance en attente (état `Pending:Wait`), puis exécute une action personnalisée.
L'instance reste dans un état d'attente jusqu'à ce que vous terminiez l'action du cycle de vie ou que le délai d'expiration se termine. Par défaut, l'instance reste en attente pendant une heure, puis le groupe Auto Scaling poursuit le processus de lancement (`Pending:Proceed`). Si vous avez besoin de plus de temps, vous pouvez redémarrer le délai d'attente en enregistrant une pulsation. Si vous terminez l'action du cycle de vie alors que l'action personnalisée est terminée et que le délai d'attente n'a pas encore expiré, le groupe Auto Scaling poursuit le processus de lancement.
1. L'instance passe à l'état `InService` et la période de grâce de surveillance de l'état commence. Cependant, avant que l'instance n'affiche l'état `InService`, si le groupe Auto Scaling est associé à un équilibreur de charge Elastic Load Balancing, l'instance est enregistrée auprès de l'équilibreur de charge et celui-ci commence à vérifier son état. Au terme de la période de grâce de surveillance de l'état, Amazon EC2 Auto Scaling commence à vérifier l'état de l'instance.
1. Le groupe Auto Scaling répond à un événement de mise à l'échelle horizontale et entame le processus de résiliation de l'instance. Si le groupe Auto Scaling est utilisé avec Elastic Load Balancing, l'instance en cours de résiliation est d'abord désenregistrée de l'équilibreur de charge. Si Connection Draining est activé pour l'équilibreur de charge, l'instance cesse d'accepter de nouvelles connexions et attend que les connexions existantes soient drainées avant de finaliser le processus de désenregistrement.
1. Le hook de cycle de vie met l'instance en attente (état `Terminating:Wait`), puis exécute une action personnalisée.
L'instance reste en attente jusqu'à ce que vous ayez finalisé l'action de cycle de vie, ou jusqu'à ce que le délai d'attente (défini par défaut sur une heure) soit écoulé. Une fois l'exécution du hook de cycle de vie finalisée ou le délai d'attente écoulé, l'instance passe à l'état suivant (`Terminating:Proceed`).
1. L'instance est résiliée.
**Important**
Les instances d'un groupe d'instances pré-initialisées ont également leur propre cycle de vie avec des états d'attente correspondants, tel que décrit dans [Transitions de l'état du cycle de vie pour les instances dans un groupe d'instances pré-initialisées](warm-pool-instance-lifecycle.md#lifecycle-state-transitions).
## Transitions d'état du cycle de vie pour les instances en cours de remplacement du volume racine
Le schéma suivant montre la transition entre les états des instances Auto Scaling lorsque vous utilisez des hooks de cycle de vie pour remplacer le volume racine :
![\[Les transitions entre les états d'une instance Auto Scaling lorsque vous utilisez des hooks de cycle de vie pour remplacer le volume racine.\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/images/root-volume-replacement-lifecycle-states.png)
Comme représenté dans le schéma précédent :
1. Le groupe Auto Scaling répond à une actualisation d'instance et sélectionne une instance pour le remplacement du volume racine. L'instance entre dans l'`ReplacingRootVolume`état. Si l'instance est enregistrée auprès d'un équilibreur de charge, elle est désenregistrée de l'équilibreur de charge.
1. Le hook de cycle de vie met l'instance en attente (état `ReplacingRootVolume:Wait`), puis exécute une action personnalisée. L'instance reste dans un état d'attente jusqu'à ce que vous terminiez l'action du cycle de vie ou que le délai d'expiration se termine. Si vous terminez l'action du cycle de vie alors que l'action personnalisée est terminée et que le délai d'expiration n'est pas encore expiré, la période prend fin et le groupe Auto Scaling poursuit le processus de remplacement du volume racine.
1. L'instance termine le remplacement de son volume racine et entre dans l'`RootVolumeReplaced`état.
1. L'instance entre dans l'`Pending`état.
1. Le hook de cycle de vie met l'instance en attente (état `Pending:Wait`), puis exécute une action personnalisée. L'instance reste en état d'attente soit jusqu'à ce que vous ayez terminé l'action du cycle de vie, soit jusqu'à la fin du délai d'expiration. Une fois l'exécution du hook de cycle de vie finalisée ou le délai d'attente écoulé, l'instance passe à l'état suivant (`Pending:Proceed`).
1. L'instance entre dans l'`InService`état. Toutefois, avant que l'instance n'atteigne `InService` cet état, si le groupe Auto Scaling est associé à un équilibreur de charge Elastic Load Balancing, l'instance est enregistrée auprès de l'équilibreur de charge.
# Vous préparer à ajouter un hook de cycle de vie à un groupe Auto Scaling
Avant d'ajouter un hook de cycle de vie à votre groupe Auto Scaling, assurez-vous que votre cible de notification ou votre script de données utilisateur est correctement configuré.
+ Pour exécuter un script de données utilisateur afin d'effectuer des actions personnalisées sur vos instances lors de leur lancement, vous n'avez pas besoin de configurer de cible de notification. Cependant, vous devez déjà avoir créé le modèle de lancement ou la configuration de lancement qui spécifie votre script de données utilisateur et les avoir associés à votre groupe Auto Scaling. Pour plus d'informations sur les scripts de données utilisateur, consultez la section [Exécuter des commandes sur votre instance Linux au lancement](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) dans le guide de l'*utilisateur Amazon EC2*.
+ Pour signaler à Amazon EC2 Auto Scaling que l'action du cycle de vie est terminée, vous devez ajouter [CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html)l'appel d'API au script, et vous devez créer manuellement un rôle IAM avec une politique qui autorise les instances Auto Scaling à appeler cette API. Votre modèle de lancement ou votre configuration de lancement doit spécifier ce rôle à l'aide d'un profil d'instance IAM qui est attaché à vos instances Amazon EC2 lors du lancement. Pour plus d’informations, consultez [Réaliser une action du cycle de vie dans un groupe Auto Scaling](completing-lifecycle-hooks.md) et [Rôle IAM pour les applications qui s'exécutent sur des instances Amazon EC2](us-iam-role.md).
+ Pour permettre à Lambda de signaler à Amazon EC2 Auto Scaling une fois l'action du cycle de vie terminée, vous devez ajouter l'appel d'[CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html)API au code de fonction. Vous devez également avoir attaché une politique IAM au rôle d'exécution de la fonction pour accorder à Lambda l'autorisation de terminer les actions de cycle de vie. Pour de plus amples informations, veuillez consulter [Didacticiel : configurer un hook de cycle de vie qui appelle une fonction Lambda](tutorial-lifecycle-hook-lambda.md).
+ Pour utiliser un service tel qu'Amazon SNS ou Amazon SQS pour effectuer une action personnalisée, vous devez déjà avoir créé la rubrique SNS ou la file d'attente SQS et disposer de son Amazon Resource Name (ARN). Vous devez également avoir déjà créé le rôle IAM qui donne à Amazon EC2 Auto Scaling l'accès à votre rubrique SNS ou cible SQS et avoir prêt son ARN. Pour de plus amples informations, veuillez consulter [Configurer une cible de notification pour les notifications de cycle de vie](#lifecycle-hook-notification-target).
**Note**
Par défaut, lorsque vous ajoutez un hook de cycle de vie dans la console, Amazon EC2 Auto Scaling envoie des notifications d'événements liés au cycle de vie à Amazon EventBridge. L'utilisation EventBridge d'un script de données utilisateur est une bonne pratique recommandée. Pour créer un hook de cycle de vie qui envoie des notifications directement à Amazon SNS, Amazon SQS, AWS Lambda ou utilisez AWS CLI le AWS CloudFormation, ou un SDK pour ajouter le hook de cycle de vie.
## Configurer une cible de notification pour les notifications de cycle de vie
Vous pouvez ajouter des hooks de cycle de vie à un groupe Auto Scaling pour exécuter des actions personnalisées lorsqu'une instance entre en état d'attente. Vous pouvez choisir un service cible pour effectuer ces actions en fonction de votre approche de développement préférée.
Il existe quatre approches différentes pour mettre en œuvre des cibles de notification pour les hooks du cycle de vie :
+ **Amazon EventBridge** — Recevez les notifications et effectuez les actions que vous souhaitez.
+ **Amazon Simple Notification Service (Amazon SNS**) — Créez une rubrique pour publier des notifications. Les clients peuvent s'abonner à la rubrique SNS et recevoir les messages publiés à l'aide d'un protocole pris en charge.
+ **Amazon Simple Queue Service (Amazon SQS**) : échangez des messages via un modèle de sondage.
+ **AWS Lambda**— Invoquez une fonction Lambda qui exécute l'action souhaitée.
Comme bonne pratique, nous vous recommandons d’utiliser EventBridge. Les notifications envoyées à Amazon SNS et Amazon SQS contiennent les mêmes informations que celles auxquelles Amazon EC2 Auto Scaling envoie. EventBridge Auparavant EventBridge, la pratique standard consistait à envoyer une notification à SNS ou SQS et à intégrer un autre service à SNS ou SQS pour effectuer des actions programmatiques. Aujourd'hui, vous EventBridge offre davantage d'options pour les services que vous pouvez cibler et facilite la gestion des événements à l'aide d'une architecture sans serveur.
N'oubliez pas que si vous avez un script de données utilisateur dans votre modèle de lancement ou configuration de lancement qui configure vos instances lors de leur lancement, vous n'avez pas besoin de notification pour effectuer des actions personnalisées sur vos instances.
Les procédures suivantes expliquent comment configurer votre cible de notification.
**Topics**
+ [Acheminez les notifications vers Lambda en utilisant EventBridge](#cloudwatch-events-notification)
+ [Recevoir des notifications à l'aide d'Amazon SNS](#sns-notifications)
+ [Recevoir des notifications à l'aide d'Amazon SQS](#sqs-notifications)
+ [Acheminer les notifications AWS Lambda directement vers](#lambda-notification)
+ [Exemple de message de notification](#notification-message-example)
**Important**
La EventBridge règle, la fonction Lambda, la rubrique Amazon SNS et la file d'attente Amazon SQS que vous utilisez avec les hooks du cycle de vie doivent toujours se trouver dans la même région que celle dans laquelle vous avez créé votre groupe Auto Scaling.
### Acheminez les notifications vers Lambda en utilisant EventBridge
Vous pouvez configurer une EventBridge règle pour appeler une fonction Lambda lorsqu'une instance entre dans un état d'attente. Amazon EC2 Auto Scaling envoie une notification EventBridge d'événement concernant le cycle de vie de l'instance en cours de lancement ou d'arrêt, ainsi qu'un jeton que vous pouvez utiliser pour contrôler l'action du cycle de vie. Pour obtenir des exemples de ces événements, consultez [Référence de l'événement Amazon EC2 Auto Scaling](ec2-auto-scaling-event-reference.md).
**Note**
Lorsque vous utilisez la règle AWS Management Console pour créer un événement, la console ajoute automatiquement les autorisations IAM nécessaires pour EventBridge autoriser l'appel de votre fonction Lambda. Si vous créez une règle d'événement à l'aide de l' AWS CLI, vous devez explicitement accorder cette autorisation.
Pour plus d'informations sur la création de règles d'événements dans la EventBridge console, consultez la section [Création de EventBridge règles Amazon qui réagissent aux événements](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html) dans le *guide de EventBridge l'utilisateur Amazon*.
– ou –
Pour obtenir un tutoriel d'introduction destiné aux utilisateurs de la console, consultez la rubrique [Didacticiel : configurer un hook de cycle de vie qui appelle une fonction Lambda](tutorial-lifecycle-hook-lambda.md). Ce didacticiel explique comment créer une fonction Lambda simple qui écoute les événements de lancement et les enregistre dans un CloudWatch journal des journaux.
**Pour créer une EventBridge règle qui invoque une fonction Lambda**
1. Créez une fonction Lambda à l'aide de la [console Lambda](https://console.aws.amazon.com/lambda/home#/functions) et notez son Amazon Resource Name (ARN). Par exemple, `arn:aws:lambda:region:123456789012:function:my-function`. Vous avez besoin de l'ARN pour créer une EventBridge cible. Pour plus d'informations, consultez [Prise en main de Lambda](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html) dans le *Guide du développeur AWS Lambda *.
1. Pour créer une règle qui correspond aux événements de lancement d'une instance, utilisez la commande [put-rule](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/events/put-rule.html) suivante.
```
aws events put-rule --name my-rule --event-pattern file://pattern.json --state ENABLED
```
L'exemple suivant illustre le fichier `pattern.json` correspondant à une action de cycle de vie de lancement d'instance. Remplacez le texte **italics**par le nom de votre groupe Auto Scaling.
```
{
"source": [ "aws.autoscaling" ],
"detail-type": [ "EC2 Instance-launch Lifecycle Action" ],
"detail": {
"AutoScalingGroupName": [ "my-asg" ]
}
}
```
Si la commande s'exécute correctement, elle EventBridge répond avec l'ARN de la règle. Notez cet ARN. Vous devrez le saisir au cours de l'étape 4.
Pour créer une règle qui correspond à d'autres événements, modifiez le modèle d'événement. Pour de plus amples informations, veuillez consulter [EventBridge À utiliser pour gérer les événements Auto Scaling](automating-ec2-auto-scaling-with-eventbridge.md).
1. Pour spécifier la fonction Lambda à utiliser comme cible pour la règle, utilisez la commande [put-targets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/events/put-targets.html) suivante :
```
aws events put-targets --rule my-rule --targets Id=1,Arn=arn:aws:lambda:region:123456789012:function:my-function
```
Dans la commande précédente, *my-rule* il s'agit du nom que vous avez spécifié pour la règle à l'étape 2, et la valeur du `Arn` paramètre est l'ARN de la fonction que vous avez créée à l'étape 1.
1. Pour ajouter des autorisations permettant à la règle d'invoquer votre fonction Lambda cible, utilisez la commande [add-permission](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/add-permission.html) Lambda suivante. Cette commande fait confiance au principal de EventBridge service (`events.amazonaws.com`) et étend les autorisations à la règle spécifiée.
```
aws lambda add-permission --function-name my-function --statement-id my-unique-id \
--action 'lambda:InvokeFunction' --principal events.amazonaws.com --source-arn arn:aws:events:region:123456789012:rule/my-rule
```
Dans la commande précédente :
+ *my-function*est le nom de la fonction Lambda que vous souhaitez que la règle utilise comme cible.
+ *my-unique-id*est un identifiant unique que vous définissez pour décrire l'instruction dans la politique de fonction Lambda.
+ `source-arn`est l'ARN de la EventBridge règle.
Si la commande s'exécute correctement, vous recevez une sortie similaire à ce qui suit.
```
{
"Statement": "{\"Sid\":\"my-unique-id\",
\"Effect\":\"Allow\",
\"Principal\":{\"Service\":\"events.amazonaws.com\"},
\"Action\":\"lambda:InvokeFunction\",
\"Resource\":\"arn:aws:lambda:us-west-2:123456789012:function:my-function\",
\"Condition\":
{\"ArnLike\":
{\"AWS:SourceArn\":
\"arn:aws:events:us-west-2:123456789012:rule/my-rule\"}}}"
}
```
La valeur `Statement` est une version de la chaîne JSON correspondant à l'instruction ajoutée à la politique de la fonction Lambda.
1. Une fois que vous avez suivi ces instructions, passez à [Ajoutez des hooks de cycle de vie à votre groupe Auto Scaling](adding-lifecycle-hooks.md) qui est l'étape suivante.
### Recevoir des notifications à l'aide d'Amazon SNS
Vous pouvez utiliser Amazon SNS pour configurer une cible de notification (une rubrique SNS) permettant de recevoir des notifications lorsqu'une action de cycle de vie se produit. Amazon SNS envoie ensuite les notifications aux destinataires abonnés. Aucune notification publiée dans la rubrique n'est envoyée aux destinataires tant que l'abonnement n'est pas confirmé.
**Pour configurer des notifications à l'aide d'Amazon SNS**
1. Créez une rubrique Amazon SNS à l'aide de la [console Amazon SNS](https://console.aws.amazon.com/sns/) ou de la commande [create-topic](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sns/create-topic.html) suivante. Assurez-vous que la rubrique se trouve dans la même région que le groupe Auto Scaling que vous utilisez. Pour plus d'informations, consultez [Prise en main d'Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) dans le *Guide du développeur Amazon Simple Notification Service*.
```
aws sns create-topic --name my-sns-topic
```
1. Notez l'Amazon Resource Name (ARN) de la rubrique, par exemple `arn:aws:sns:region:123456789012:my-sns-topic`. Celui-ci est nécessaire pour créer le hook de cycle de vie.
1. Créez un rôle de service IAM pour accorder à Amazon EC2 Auto Scaling l'autorisation d'accès à votre cible de notification Amazon SNS.
**Pour accorder à Amazon EC2 Auto Scaling l'autorisation d'accès à votre rubrique SNS**
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Dans le panneau de navigation de gauche, sélectionnez **Roles** (Rôles).
1. Sélectionnez **Create role** (Créer un rôle).
1. Pour **Select trusted entity** (Sélectionner une entité de confiance), choisissez **service AWS **.
1. Pour votre cas d'utilisation, sous **Use cases for other AWS services** (Cas d'utilisation sez **EC2 Auto Scaling** puis **EC2 Auto Scaling Notification Access** (Notification d'accès EC2 Auto Scaling).
1. Cliquez deux fois sur **Next** (Suivant) pour aller à la page **Name, review, and create** (Nommer, vérifier et créer).
1. Pour **Role Name** (Nom du rôle), saisissez un nom pour votre rôle (par exemple **my-notification-role**), puis sélectionnez **Create Role** (Créer un rôle).
1. Sur la page **Roles** (Rôles), choisissez le rôle que vous venez de créer pour ouvrir la page **Summary** (Récapitulatif). Notez l'**ARN** du rôle. Par exemple, `arn:aws:iam::123456789012:role/my-notification-role`. Celui-ci est nécessaire pour créer le hook de cycle de vie.
1. Une fois que vous avez suivi ces instructions, passez à [Ajouter des hooks de cycle de vie (AWS CLI)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-aws-cli) qui est l'étape suivante.
### Recevoir des notifications à l'aide d'Amazon SQS
Vous pouvez utiliser Amazon SQS pour configurer une cible de notification permettant de recevoir des messages lorsqu'une action de cycle de vie se produit. Un consommateur de file d'attente doit alors interroger une file d'attente SQS pour agir sur ces notifications.
**Important**
Les files d'attente FIFO ne sont pas compatibles avec des hooks de cycle de vie.
**Pour configurer des notifications à l'aide d'Amazon SQS**
1. Créez une file d'attente Amazon SQS à l'aide de la [console Amazon SQS](https://console.aws.amazon.com/sqs/). Assurez-vous que la file d'attente se trouve dans la même région que le groupe Auto Scaling que vous utilisez. Pour plus d'informations, consultez [Prise en main d'Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-getting-started.html) dans le *Guide du développeur Amazon Simple Queue Service*.
1. Notez l'ARN de la file d'attente, par exemple `arn:aws:sqs:us-west-2:123456789012:my-sqs-queue`. Celui-ci est nécessaire pour créer le hook de cycle de vie.
1. Créez un rôle de service IAM pour accorder à Amazon EC2 Auto Scaling l'autorisation d'accès à votre cible de notification Amazon SQS.
**Pour accorder à Amazon EC2 Auto Scaling l'autorisation d'accès à votre file d'attente SQS**
1. Ouvrez la console IAM à l’adresse [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. Dans le panneau de navigation de gauche, sélectionnez **Roles** (Rôles).
1. Sélectionnez **Create role** (Créer un rôle).
1. Pour **Select trusted entity** (Sélectionner une entité de confiance), choisissez **service AWS **.
1. Pour votre cas d'utilisation, sous **Use cases for other AWS services** (Cas d'utilisation sez **EC2 Auto Scaling** puis **EC2 Auto Scaling Notification Access** (Notification d'accès EC2 Auto Scaling).
1. Cliquez deux fois sur **Next** (Suivant) pour aller à la page **Name, review, and create** (Nommer, vérifier et créer).
1. Pour **Role Name** (Nom du rôle), saisissez un nom pour votre rôle (par exemple **my-notification-role**), puis sélectionnez **Create Role** (Créer un rôle).
1. Sur la page **Roles** (Rôles), choisissez le rôle que vous venez de créer pour ouvrir la page **Summary** (Récapitulatif). Notez l'**ARN** du rôle. Par exemple, `arn:aws:iam::123456789012:role/my-notification-role`. Celui-ci est nécessaire pour créer le hook de cycle de vie.
1. Une fois que vous avez suivi ces instructions, passez à [Ajouter des hooks de cycle de vie (AWS CLI)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-aws-cli) qui est l'étape suivante.
### Acheminer les notifications AWS Lambda directement vers
Vous pouvez utiliser une fonction Lambda comme cible de notification lorsqu'une action du cycle de vie se produit.
**Pour acheminer les notifications AWS Lambda directement vers**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) sur la console Lambda.
1. Choisissez la fonction Lambda que vous souhaitez.
Si vous souhaitez créer une nouvelle fonction Lambda, voir [Créer la fonction Lambda](lambda-custom-termination-policy.md#lambda-custom-termination-policy-create-function)
1. Cliquez sur l'onglet **Configuration**, puis sur **Autorisations**.
1. Faites défiler l'écran jusqu'à **Resource-based policy (Politique basée sur des ressources)** puis choisissez **Add permissions (Ajouter des autorisations)**. Une politique basée sur des ressources est utilisée pour accorder des autorisations pour appeler votre fonction au principal qui est spécifié dans la politique. Dans ce cas, le principal sera le [rôle lié au service Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-service-linked-role.html) associée au groupe Auto Scaling.
1. Dans **Policy statement (Déclaration de politique)**, configurez vos autorisations :
1. Sélectionnez **Compte AWS**.
1. Pour **Principal **, saisissez l'ARN du rôle lié au service appelant, par exemple, **arn:aws:iam:::role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling**.
1. Pour **Action**, choisissez **lambda : InvokeFunction**.
1. Pour **Statement ID (ID de l'instruction)**, saisissez un ID d'instruction unique, tel que **AllowInvokeByAutoScaling**.
1. Choisissez **Save** (Enregistrer).
1. Une fois que vous avez suivi ces instructions, passez à [Ajouter des hooks de cycle de vie (AWS CLI)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-aws-cli) qui est l'étape suivante.
### Exemple de message de notification
Cette section fournit un exemple de notification pour Amazon SNS, Amazon SQS et. AWS Lambda
Lorsque l'instance est en état d'attente, un message est publié sur Amazon SNS, Amazon SQS et sur la cible de notification. AWS Lambda
Le message comprend les informations suivantes :
+ `Origin`— Endroit d'où provient une instance EC2.
+ `Destination`— Un endroit où une instance EC2 est destinée.
+ `LifecycleActionToken` : jeton de l'action de cycle de vie.
+ `AccountId`— L' Compte AWS identifiant.
+ `AutoScalingGroupName` : nom du groupe Auto Scaling.
+ `LifecycleHookName` : nom du hook de cycle de vie.
+ `EC2InstanceId` : ID de l'instance EC2.
+ `LifecycleTransition` : type du hook de cycle de vie.
+ `NotificationMetadata` : métadonnées de notification.
Voici un exemple de message de notification.
```
Service: AWS Auto Scaling
Time: 2021-01-19T00:36:26.533Z
RequestId: 18b2ec17-3e9b-4c15-8024-ff2e8ce8786a
Origin: EC2
Destination: AutoScalingGroup
LifecycleActionToken: 71514b9d-6a40-4b26-8523-05e7ee35fa40
AccountId: 123456789012
AutoScalingGroupName: my-asg
LifecycleHookName: my-hook
EC2InstanceId: i-0598c7d356eba48d7
LifecycleTransition: autoscaling:EC2_INSTANCE_LAUNCHING
NotificationMetadata: hook message metadata
```
#### Exemple de message de notification de test
Lorsque vous ajoutez pour la première fois un hook de cycle de vie, un message de notification de test est publié sur la cible de notification. Voici un exemple de message de notification de test.
```
Service: AWS Auto Scaling
Time: 2021-01-19T00:35:52.359Z
RequestId: 18b2ec17-3e9b-4c15-8024-ff2e8ce8786a
Event: autoscaling:TEST_NOTIFICATION
AccountId: 123456789012
AutoScalingGroupName: my-asg
AutoScalingGroupARN: arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:042cba90-ad2f-431c-9b4d-6d9055bcc9fb:autoScalingGroupName/my-asg
```
**Note**
Pour des exemples d'événements proposés par Amazon EC2 Auto Scaling EventBridge à, [Référence de l'événement Amazon EC2 Auto Scaling](ec2-auto-scaling-event-reference.md) consultez.
# Contrôlez la rétention des instances grâce aux politiques de cycle de vie des instances
Les politiques de cycle de vie des instances fournissent une protection contre les interruptions d'Amazon EC2 Auto Scaling lorsqu'une action du cycle de vie de résiliation est abandonnée. Contrairement aux seuls crochets relatifs au cycle de vie, les politiques de cycle de vie des instances sont conçues pour garantir que les instances passent à un état conservé lorsque les procédures d'arrêt progressives ne se terminent pas correctement.
## Quand utiliser les politiques de cycle de vie des instances
Utilisez les politiques de cycle de vie des instances lorsque l'arrêt progressif de votre application n'est pas facultatif mais obligatoire et que les arrêts échoués nécessitent une intervention manuelle. Cas d’utilisation courants :
+ Applications dynamiques qui doivent terminer la persistance des données avant de s'arrêter.
+ Applications nécessitant des périodes de vidange prolongées pouvant dépasser le délai d'expiration maximal du cycle de vie du crochet, qui est de 48 heures.
+ Charges de travail traitant des données sensibles dont l'échec ou le nettoyage incomplet peuvent entraîner la perte ou la corruption des données.
+ Services critiques pour lesquels un arrêt brutal a un impact sur la disponibilité.
Pour plus d'informations sur la manière de gérer correctement la résiliation d'une instance, consultez[Concevez vos applications pour gérer avec élégance la résiliation des instances](gracefully-handle-instance-termination.md).
## Comment les politiques de cycle de vie des instances fonctionnent avec les hooks du cycle de vie de résiliation
Les politiques de cycle de vie des instances fonctionnent en combinaison avec les hooks du cycle de vie de résiliation, et non en remplacement. Le processus se déroule en plusieurs étapes :
1. **Les actions du cycle de vie de résiliation sont exécutées.** Lorsqu'Amazon EC2 Auto Scaling sélectionne une instance à résilier, vos hooks du cycle de vie de résiliation sont invoqués et l'instance entre dans l'état requis pour commencer à exécuter `Terminating:Wait` les actions du cycle de vie de résiliation.
1. **Une tentative d'arrêt gracieuse commence.** Votre application, qu'elle s'exécute sur l'instance ou via un plan de contrôle, reçoit la notification des actions de fin du cycle de vie et lance des procédures d'arrêt progressives, telles que la vidange des connexions, l'achèvement des travaux en cours ou le transfert de données.
1. **Les actions du cycle de vie de résiliation sont terminées.** Une action du cycle de vie de résiliation peut aboutir `CONTINUE` ou en `ABANDON` résulter.
1. **La politique de cycle de vie de l'instance évalue la situation.** Si aucune politique de cycle de vie d'instance n'est configurée, l'instance passe immédiatement à la résiliation, même si l'action du cycle de vie de résiliation a été menée à bien avec `ABANDON` résultat. Avec une politique de cycle de vie d'instance configurée pour conserver les instances `TerminateHookAbandon` actives, l'instance passe à un état conservé si l'action de résiliation du cycle de vie s'est terminée avec `ABANDON` résultat.
1. **Les instances conservées attendent une action manuelle.** Les instances dans les états conservés continuent de faire l'objet de frais Amazon EC2 standard. Ces instances ne sont pas prises en compte dans la capacité souhaitée de votre groupe Auto Scaling. Auto Scaling lance donc des instances de remplacement pour maintenir la taille souhaitée. Les fonctionnalités d'Auto Scaling telles que l'actualisation des instances et la durée de vie maximale des instances ignoreront également les instances conservées. Cela vous permet d'effectuer les procédures de nettoyage manuellement, de récupérer des données ou de rechercher les raisons de l'échec de l'arrêt automatique avant de mettre fin manuellement à l'instance.
1. **La résiliation manuelle se produit.** Après avoir effectué les actions nécessaires sur l'instance conservée, vous devez appeler l'`TerminateInstanceInAutoScalingGroup`API pour mettre fin à l'instance.
# Configurer la rétention des instances
Configurez votre groupe Amazon EC2 Auto Scaling pour conserver les instances lorsque les actions du cycle de vie de résiliation échouent.
Pour utiliser les politiques de cycle de vie des instances dans votre groupe Auto Scaling, vous devez également configurer un hook de cycle de vie de terminaison. Si vous configurez une politique de cycle de vie d'instance mais que vous n'avez aucun hook de cycle de vie de résiliation, la politique n'a aucun effet. Les politiques relatives au cycle de vie des instances ne s'appliquent que lorsque les actions du cycle de vie de résiliation sont abandonnées, et non lorsqu'elles aboutissent au `CONTINUE` résultat escompté.
Les politiques de cycle de vie des instances utilisent des déclencheurs de rétention pour déterminer quand conserver une instance. Le `TerminateHookAbandon` déclencheur entraîne la rétention dans plusieurs scénarios :
+ Lorsque vous appelez explicitement l'[ CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html)API avec le `ABANDON` résultat.
+ Lorsqu'une action du cycle de vie de résiliation avec un résultat par défaut `ABANDON` expire parce que le délai d'expiration du rythme cardiaque est atteint sans qu'un battement de cœur ne soit reçu.
+ Lorsque le délai global est atteint lors d'une action du cycle de vie de résiliation dont le résultat `ABANDON` par défaut est de 48 heures ou 100 fois le délai d'expiration du rythme cardiaque, la valeur la plus courte étant retenue
------
#### [ Console ]
**Pour configurer la rétention des instances**
1. Ouvrez la console Amazon EC2 Auto Scaling
1. Créez votre groupe Auto Scaling (la politique de cycle de vie de l'instance est définie par défaut sur Terminate)
1. Accédez à la page des détails de votre groupe Auto Scaling et choisissez l'onglet **Instance Management**
1. Dans **Politique de cycle de vie des instances pour les hooks de cycle** de vie, choisissez **Retain**
1. Créez vos crochets relatifs au cycle de vie des résiliations avec :
+ Transition du cycle de vie définie sur **Instance terminate**
+ Le résultat par défaut est défini sur **Abandon**
------
#### [ AWS CLI ]
**Pour configurer la rétention des instances**
Utilisez la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande avec une politique de cycle de vie de l'instance :
```
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-asg \
--launch-template LaunchTemplateName=my-template,Version='$Latest' \
--min-size 1 \
--max-size 3 \
--desired-capacity 2 \
--vpc-zone-identifier subnet-12345678 \
--instance-lifecycle-policy file://lifecycle-policy.json
```
Contenu du fichier lifecycle-policy.json :
```
{
"RetentionTriggers": {
"TerminateHookAbandon": "retain"
}
}
```
**Pour ajouter un hook de cycle de vie de résiliation**
Utilisez la commande [put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html) :
```
aws autoscaling put-lifecycle-hook \
--lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
--default-result ABANDON \
--heartbeat-timeout 300
```
------
# Gérer les instances conservées
Surveillez et contrôlez les instances Amazon EC2 qui ont été déplacées vers un état conservé. Utilisez CloudWatch des métriques pour suivre les instances conservées, puis mettez fin manuellement aux instances conservées après avoir effectué vos actions personnalisées.
Les instances conservées ne sont pas prises en compte dans le calcul de la capacité souhaitée par votre groupe Amazon EC2 Auto Scaling. Lorsqu'une instance passe à l'état conservé, Auto Scaling lance une instance de remplacement pour conserver la capacité souhaitée. Supposons, par exemple, que votre groupe Auto Scaling ait une capacité souhaitée de 10. Lorsqu'une instance entre dans `Terminating:Retained` cet état, Auto Scaling lance une instance de remplacement pour maintenir la capacité souhaitée de 10. Vous avez désormais 11 instances en cours d'exécution au total : 10 dans votre groupe actif plus 1 instance conservée. Les frais standard d'Amazon EC2 pour les 11 instances s'appliqueront jusqu'à ce que vous mettiez manuellement fin à l'instance conservée.
## État du cycle de vie des instances conservées
Découvrez comment les instances passent d'un état à l'autre du cycle de vie lorsque les politiques de cycle de vie des instances sont utilisées. Les instances suivent un chemin spécifique depuis la résiliation normale jusqu'à la résiliation finale en passant par la rétention.
*Lorsque la rétention est déclenchée, les instances passent par les états suivants :*
1. `Terminating`- Début de la terminaison normale
1. `Terminating:Wait`- Lifecycle Hook s'exécute
1. `Terminating:Proceed`- Les actions du cycle de vie se terminent (qu'elles aient réussi ou échoué)
1. `Terminating:Retained`- Le crochet échoue, l'instance est conservée pour une intervention manuelle
Les instances Warm Pool suivent des chemins d'état de cycle de vie différents en fonction du scénario :
*Instances redimensionnées dans le pool de chaleur :*
1. `Warmed:Pending`- La transition normale vers une piscine chaude commence
1. `Warmed:Pending:Wait`- Lifecycle Hook s'exécute
1. `Warmed:Pending:Proceed`- Les actions du cycle de vie se terminent (qu'elles aient réussi ou échoué)
1. `Warmed:Pending:Retained`- Le crochet échoue, l'instance est conservée pour une intervention manuelle
*Instances en cours de résiliation depuis le pool de chaleur :*
1. `Warmed:Terminating`- Début de la terminaison normale
1. `Warmed:Terminating:Wait`- Lifecycle Hook s'exécute
1. `Warmed:Terminating:Proceed`- Les actions du cycle de vie se terminent (qu'elles aient réussi ou échoué)
1. `Warmed:Terminating:Retained`- Le crochet échoue, l'instance est conservée pour une intervention manuelle
## Surveillez les instances conservées
Étant donné que les instances Amazon EC2 conservées entraînent des coûts et nécessitent une intervention manuelle, leur surveillance est essentielle. Amazon EC2 Auto Scaling fournit CloudWatch plusieurs métriques pour suivre les instances conservées.
Activez les métriques de groupe pour suivre les instances conservées :
```
aws autoscaling enable-metrics-collection \
--auto-scaling-group-name my-asg \
--metrics GroupTerminatingRetainedInstances
```
Les indicateurs disponibles sont les suivants :
+ `GroupTerminatingRetainedInstances`indique le nombre d'instances dans l'`Terminating:Retained`état.
+ `GroupTerminatingRetainedCapacity`indique les unités de capacité représentées par les instances dans l'`Terminating:Retained`état.
+ `WarmPoolTerminatingRetainedCapacity`suit les instances conservées qui se terminent depuis le pool de chaleur.
+ `WarmPoolPendingRetainedCapacity`suit le retour des instances conservées dans le pool de chaleur.
Vous pouvez également vérifier les activités de dimensionnement de votre groupe Amazon EC2 Auto Scaling pour comprendre pourquoi les instances ont été conservées. Recherchez les activités de résiliation accompagnées de messages indiquant `StatusCode: Cancelled` les raisons du statut indiquant les défaillances des crochets pendant le cycle de vie :
```
aws autoscaling describe-scaling-activities \
--auto-scaling-group-name my-asg
```
Nous vous recommandons de créer des CloudWatch alarmes sur ces métriques afin de vous avertir lorsque les instances entrent dans un état conservé. Cela vous permet de suivre les implications financières et de ne pas oublier de nettoyer les instances qui nécessitent une intervention manuelle.
## Mettre fin aux instances conservées
Après avoir effectué vos actions personnalisées, mettez fin à vos instances conservées en appelant l'[ TerminateInstanceInAutoScalingGroup](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_TerminateInstanceInAutoScalingGroup.html)API :
```
aws autoscaling terminate-instance-in-auto-scaling-group \
--instance-id i-1234567890abcdef0 \
--no-should-decrement-desired-capacity
```
# Récupérer l'état du cycle de vie cible via des métadonnées d'instance
Chaque instance Auto Scaling que vous lancez connaît plusieurs états de cycle de vie. Pour invoquer des actions personnalisées dans une instance pour agir sur des transitions d’état du cycle de vie spécifiques, vous devez récupérer l’état du cycle de vie cible via des métadonnées de l’instance.
Par exemple, vous pourriez avoir besoin d’un mécanisme pour détecter la résiliation d’une instance à l’intérieur de l’instance afin d’exécuter du code sur l’instance avant qu’elle ne soit résiliée. Vous pouvez le faire en écrivant du code qui interroge l’état du cycle de vie d’une instance directement à partir de celle-ci. Vous pouvez ensuite ajouter un hook de cycle de vie au groupe Auto Scaling pour que l’instance continue de fonctionner jusqu’à ce que votre code informe la commande **complete-lifecycle-action** de continuer.
Le cycle de vie de l'instance Auto Scaling comporte deux états stables primaires (`InService` et `Terminated`) et deux états stables secondaires (`Detached` et `Standby`). Si vous utilisez un groupe d'instances pré-initialisées, le cycle de vie comporte quatre états stables supplémentaires : `Warmed:Hibernated`, `Warmed:Running`, `Warmed:Stopped` et `Warmed:Terminated`.
Lorsqu'une instance se prépare à passer à l'un des états stables précédents, Amazon EC2 Auto Scaling met à jour la valeur de l'élément de métadonnées d'instance `autoscaling/target-lifecycle-state`. Pour obtenir l’état du cycle de vie cible depuis l’instance, vous devez utiliser le service de métadonnées d’instance pour le récupérer à partir des métadonnées de l’instance.
**Note**
Les *métadonnées de l'instance* sont des données relatives à une instance Amazon EC2 que les applications peuvent utiliser pour demander des informations sur l'instance. Le *service des métadonnées d’instance* est un composant sur instance que le code local utilise pour accéder aux métadonnées d’instance. Le code local peut inclure des scripts de données utilisateur ou des applications exécutées sur l'instance.
Le code local peut accéder aux métadonnées d'une instance en cours d'exécution en utilisant l'une des deux méthodes suivantes : service de métadonnées d'instance version 1 (IMDSv1) ou service de métadonnées d'instance version 2 (IMDSv2). IMDSv2utilise des requêtes orientées session et atténue plusieurs types de vulnérabilités susceptibles d'être utilisées pour tenter d'accéder aux métadonnées de l'instance. Pour en savoir plus sur ces deux méthodes, consultez la section [Utilisation IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) dans le guide de l'*utilisateur Amazon EC2*.
------
#### [ IMDSv2 ]
```
[ec2-user ~]$ TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" -v http://169.254.169.254/latest/meta-data/autoscaling/target-lifecycle-state
```
------
#### [ IMDSv1 ]
```
[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/autoscaling/target-lifecycle-state
```
------
Voici un exemple de sortie.
```
InService
```
L'état du cycle de vie cible est l'état vers lequel l'instance est en transition. L'état actuel du cycle de vie correspond à l'état dans lequel se trouve l'instance. Ils peuvent être identiques une fois l'action du cycle de vie terminée et que l'instance a terminé sa transition vers l'état du cycle de vie cible. Vous ne pouvez pas récupérer l'état actuel du cycle de vie de l'instance à partir des métadonnées de l'instance.
Amazon EC2 Auto Scaling a commencé à générer l'état du cycle de vie cible le 10 mars 2022. Si votre instance passe à l'un des états du cycle de vie cible après cette date, l'élément d'état du cycle de vie cible est présent dans les métadonnées de l'instance. Sinon, il n'est pas présent et vous recevez une erreur HTTP 404.
Pour plus d'informations sur la récupération des métadonnées d'instance, consultez la section [Récupérer les métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html) dans le guide de l'*utilisateur Amazon EC2*.
Pour obtenir un tutoriel qui vous montre comment créer un hook de cycle de vie avec une action personnalisée dans un script de données utilisateur utilisant l'état du cycle de vie cible, reportez-vous à la section [Tutoriel : utilisation de scripts de données et de métadonnées d'instance pour récupérer l'état du cycle de vie](tutorial-lifecycle-hook-instance-metadata.md).
**Important**
Pour que vous puissiez invoquer une action personnalisée dès que possible, votre code local doit fréquemment interroger IMDS et réessayer en cas d’erreur.
# Ajoutez des hooks de cycle de vie à votre groupe Auto Scaling
Pour mettre vos instances Auto Scaling en état d'attente et effectuer des actions personnalisées sur celles-ci, vous pouvez ajouter des hooks de cycle de vie à votre groupe Auto Scaling. Les actions personnalisées sont exécutées au lancement des instances ou avant qu'elles ne se terminent. Les instances restent dans un état d'attente jusqu'à ce que vous terminiez l'action du cycle de vie ou que le délai d'expiration se termine.
Après avoir créé un groupe Auto Scaling à partir du AWS Management Console, vous pouvez y ajouter un ou plusieurs hooks de cycle de vie, jusqu'à un total de 50 hooks de cycle de vie. Vous pouvez également utiliser le AWS CLI CloudFormation, ou un SDK pour ajouter des hooks de cycle de vie à un groupe Auto Scaling lors de sa création.
Par défaut, lorsque vous ajoutez un hook de cycle de vie dans la console, Amazon EC2 Auto Scaling envoie des notifications d'événements liés au cycle de vie à Amazon EventBridge. L'utilisation EventBridge d'un script de données utilisateur est une bonne pratique recommandée. Pour créer un hook de cycle de vie qui envoie des notifications directement à Amazon SNS, Amazon SQS, AWS Lambda ou vous pouvez utiliser [put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html)la commande, comme indiqué dans les exemples de cette rubrique.
**Topics**
+ [Ajouter des hooks de cycle de vie (console)](#adding-lifecycle-hooks-console)
+ [Ajouter des hooks de cycle de vie (AWS CLI)](#adding-lifecycle-hooks-aws-cli)
## Ajouter des hooks de cycle de vie (console)
Procédez comme suit pour ajouter des hooks de cycle de vie à votre groupe Auto Scaling. Pour ajouter des hooks de cycle de vie pour la montée en puissance (lancement d’instances) et la mise à l’échelle horizontale (résiliation d’instances ou renvois dans le groupe chaud), vous devez créer deux hooks distincts.
Avant de commencer, confirmez que vous avez configuré une action personnalisée, selon vos besoins, comme décrit dans [Vous préparer à ajouter un hook de cycle de vie à un groupe Auto Scaling](prepare-for-lifecycle-notifications.md).
**Pour ajouter un hook de cycle de vie destiné à la montée en puissance**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Cochez la case située en regard de votre groupe Auto Scaling. Un volet fractionné s'ouvre en bas de la page.
1. Sous l'onglet **Instance management** (Gestion des instances) dans **Lifecycle hooks** (Hooks du cycle de vie), choisissez **Create lifecycle hook** (Créer un hook de cycle de vie.
1. Pour définir un hook de cycle de vie pour la montée en puissance (lancement d’instances), procédez comme suit :
1. Pour le **Lifecycle Hook Name** (Nom du hook de cycle de vie), spécifiez un nom pour le hook de cycle de vie.
1. Dans le champ **Lifecycle transition** (Transition du cycle de vie), choisissez **Instance launch** (Lancement d'instance).
1. Pour **Délai de pulsation**, spécifiez la durée (en secondes) pendant laquelle les instances doivent rester en état d’attente lors de l’évolutivité horizontale avant l’expiration du hook. La plage est comprise entre `30` et `7200` secondes. La définition d’une longue période de délai d’attente donne plus de temps à votre action personnalisée pour aboutir. Ensuite, si vous terminez avant la fin du délai imparti, envoyez la [complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html)commande pour permettre à l'instance de passer à l'état suivant.
1. Pour **Default result** (Résultat par défaut), définissez l'action à entreprendre lorsque le délai d'attente du hook de cycle de vie est écoulé ou qu'un échec inattendu se produit. Vous pouvez choisir d’**ABANDONNER** ou de **CONTINUER**.
+ Si vous sélectionnez **CONTINUER**, le groupe Auto Scaling peut exécuter n’importe quel hook de cycle de vie, puis mettre l’instance en service.
+ Si vous choisissez **ABANDONNER**, le groupe Auto Scaling interrompt les actions restantes et résilie immédiatement l’instance.
1. (Facultatif) Dans le champ **Métadonnées de notification**, spécifiez les informations supplémentaires que vous souhaitez inclure lorsque Amazon EC2 Auto Scaling envoie un message à la cible de notification.
1. Choisissez **Créer**.
**Pour ajouter un hook de cycle de vie destiné à la mise à l’échelle horizontale**
1. Choisissez **Créer un hook de cycle de vie** pour continuer là où vous vous êtes arrêté après la création d’un hook de cycle de vie destiné à la montée en puissance.
1. Pour définir un hook de cycle de vie pour la mise à l’échelle horizontale (instances résiliées ou revenant à un groupe chaud), procédez comme suit :
1. Pour le **Lifecycle Hook Name** (Nom du hook de cycle de vie), spécifiez un nom pour le hook de cycle de vie.
1. Dans le champ **Transition du cycle de vie**, choisissez **Résiliation d'instance**.
1. Pour **Délai de pulsation**, spécifiez la durée (en secondes) pendant laquelle les instances doivent rester en état d’attente lors de l’évolutivité horizontale avant l’expiration du hook. Nous recommandons un court délai d'attente de deux `30` à `120` secondes, en fonction du temps dont vous avez besoin pour effectuer les tâches finales, telles que l'extraction des journaux EC2. CloudWatch
1. Dans le champ **Default result** (Résultat par défaut), spécifiez l'action que le groupe Auto Scaling doit entreprendre lorsque le délai d'attente est écoulé ou qu'un échec inattendu se produit. Les paramètres **ABANDON** (ABANDONNER) et **CONTINUE** (CONTINUER) permettent tous les deux de résilier l'instance.
+ Si vous choisissez **CONTINUE** (CONTINUER), le groupe Auto Scaling peut exécuter toutes les actions restantes, comme les hooks de cycle de vie, avant la résiliation.
+ Si vous choisissez **ABANDONNER**, le groupe Auto Scaling résilie immédiatement l’instance.
1. (Facultatif) Dans le champ **Métadonnées de notification**, spécifiez les informations supplémentaires que vous souhaitez inclure lorsque Amazon EC2 Auto Scaling envoie un message à la cible de notification.
1. Choisissez **Créer**.
## Ajouter des hooks de cycle de vie (AWS CLI)
Vous pouvez créer et mettre à jour des hooks du cycle de vie avec la commande [put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html).
Pour exécuter une action sur l'augmentation de la taille des instances, utilisez la commande suivante.
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_LAUNCHING
```
Pour exécuter une action sur la diminution de la taille des instances, ajoutez plutôt la commande suivante.
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING
```
Pour recevoir des notifications à l'aide d'Amazon SNS ou d'Amazon SQS, ajoutez les options `--notification-target-arn` et `--role-arn`. Pour recevoir des notifications en utilisant AWS Lambda, ajoutez le`--notification-target-arn`.
L'exemple suivant crée un hook de cycle de vie qui spécifie une rubrique SNS nommée `my-sns-topic` comme cible de notification.
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg \
--lifecycle-transition autoscaling:EC2_INSTANCE_TERMINATING \
--notification-target-arn arn:aws:sns:region:123456789012:my-sns-topic \
--role-arn arn:aws:iam::123456789012:role/my-notification-role
```
La rubrique reçoit une notification test avec la paire clé-valeur suivante.
```
"Event": "autoscaling:TEST_NOTIFICATION"
```
Par défaut, la [put-lifecycle-hook](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-lifecycle-hook.html)commande crée un hook du cycle de vie avec un délai d'expiration de `3600` quelques secondes (une heure).
Pour modifier le délai de pulsation d'un hook de cycle de vie existant, ajoutez le paramètre `--heartbeat-timeout`, comme illustré dans l'exemple suivant.
```
aws autoscaling put-lifecycle-hook --lifecycle-hook-name my-termination-hook \
--auto-scaling-group-name my-asg --heartbeat-timeout 120
```
Si une instance est déjà en état d'attente, vous pouvez empêcher l'expiration du cycle de vie du hook en enregistrant un battement de cœur à l'aide de la commande [record-lifecycle-action-heartbeat](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/record-lifecycle-action-heartbeat.html)CLI. Cela prolonge le délai d'attente de la valeur d'attente spécifiée lorsque vous créez le hook de cycle de vie. Si vous terminez avant la fin du délai imparti, vous pouvez envoyer la commande [complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html)CLI pour permettre à l'instance de passer à l'état suivant. Pour plus d’informations et d’exemples, consultez [Réaliser une action du cycle de vie dans un groupe Auto Scaling](completing-lifecycle-hooks.md).
# Réaliser une action du cycle de vie dans un groupe Auto Scaling
Lorsqu'un groupe Auto Scaling répond à un événement de cycle de vie, il met l'instance en attente et envoie une notification d'événement. Pendant que l'instance est en attente, vous pouvez exécuter une action personnalisée.
Il est utile d’effectuer l’action du cycle de vie avec le résultat `CONTINUE` si vous terminez avant l’expiration du délai imparti. Si vous n’effectuez pas l’action du cycle de vie, le hook de cycle de vie passe au statut que vous avez indiqué pour le **résultat par défaut** une fois le délai expiré.
**Topics**
+ [Effectuer une action de cycle de vie (manuel)](#completing-lifecycle-hooks-aws-cli)
+ [Effectuer une action de cycle de vie (automatique)](#completing-lifecycle-hooks-automatic)
## Effectuer une action de cycle de vie (manuel)
La procédure suivante s'applique à l'interface de ligne de commande et n'est pas prise en charge dans la console. Les informations qui doivent être remplacées, comme l'ID de l'instance ou le nom d'un groupe Auto Scaling, sont en italique.
**Pour exécuter une action de cycle de vie (AWS CLI)**
1. Si vous avez besoin de plus de temps pour terminer l’action personnalisée, utilisez la commande [record-lifecycle-action-heartbeat](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/record-lifecycle-action-heartbeat.html) pour redémarrer le délai d’attente et conserver l’instance en état d’attente. Par exemple, si la valeur d'attente est d'1 heure, et que vous appelez cette commande après 30 minutes, l'instance reste en état d'attente pendant 1 heure supplémentaire, soit un total de 90 minutes.
Vous pouvez spécifier le jeton d'action du cycle de vie que vous avez reçu avec la [notification](prepare-for-lifecycle-notifications.md#notification-message-example), comme indiqué dans la commande suivante.
```
aws autoscaling record-lifecycle-action-heartbeat --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg --lifecycle-action-token bcd2f1b8-9a78-44d3-8a7a-4dd07d7cf635
```
Alternativement, vous pouvez spécifier l'ID de l'instance que vous avez reçu avec la [notification](prepare-for-lifecycle-notifications.md#notification-message-example), comme indiqué dans la commande suivante.
```
aws autoscaling record-lifecycle-action-heartbeat --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg --instance-id i-1a2b3c4d
```
1. Si vous terminez l'action personnalisée avant la fin du délai imparti, utilisez la [complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html)commande afin que le groupe Auto Scaling puisse continuer à lancer ou à arrêter l'instance. Vous pouvez spécifier le jeton de l'action du cycle de vie, comme illustré dans la commande suivante.
```
aws autoscaling complete-lifecycle-action --lifecycle-action-result CONTINUE \
--lifecycle-hook-name my-launch-hook --auto-scaling-group-name my-asg \
--lifecycle-action-token bcd2f1b8-9a78-44d3-8a7a-4dd07d7cf635
```
Sinon, vous pouvez spécifier l'ID de l'instance, comme illustré dans la commande suivante.
```
aws autoscaling complete-lifecycle-action --lifecycle-action-result CONTINUE \
--instance-id i-1a2b3c4d --lifecycle-hook-name my-launch-hook \
--auto-scaling-group-name my-asg
```
## Effectuer une action de cycle de vie (automatique)
Si vous disposez d'un script de données utilisateur qui configure vos instances après leur lancement, vous n'avez pas besoin d'effectuer manuellement les actions du cycle de vie. Vous pouvez ajouter la [complete-lifecycle-action](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/complete-lifecycle-action.html)commande au script. Le script peut récupérer l'ID d'instance à partir des métadonnées d'instance et signaler à Amazon EC2 Auto Scaling lorsque les scripts d'amorçage se sont terminés correctement.
Si ce n'est pas le cas, mettez à jour le script pour récupérer l'ID de l'instance à partir de ses métadonnées. Pour plus d'informations, consultez la section [Récupérer les métadonnées d'une instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html) dans le *guide de l'utilisateur Amazon EC2*.
Si vous utilisez Lambda, vous pouvez également configurer un rappel dans le code de votre fonction pour laisser le cycle de vie de l'instance se poursuivre si l'action personnalisée réussit. Pour de plus amples informations, veuillez consulter [Didacticiel : configurer un hook de cycle de vie qui appelle une fonction Lambda](tutorial-lifecycle-hook-lambda.md).
# Tutoriel : utilisation de scripts de données et de métadonnées d'instance pour récupérer l'état du cycle de vie
Une méthode courante pour créer des actions personnalisées pour les hooks du cycle de vie consiste à utiliser les notifications qu'Amazon EC2 Auto Scaling envoie à d'autres services, tels qu'Amazon EventBridge. Toutefois, vous pouvez éviter de devoir créer une infrastructure supplémentaire en utilisant plutôt un script de données utilisateur pour déplacer le code qui configure les instances et effectue l'action du cycle de vie dans les instances elles-mêmes.
Le tutoriel suivant vous montre comment commencer à utiliser un script de données utilisateur et des métadonnées d'instance. Vous créez une configuration de groupe Auto Scaling de base avec un script de données utilisateur qui lit l'[état du cycle de vie cible](retrieving-target-lifecycle-state-through-imds.md) des instances de votre groupe et effectue une action de rappel à une phase spécifique du cycle de vie d'une instance pour poursuivre le processus de lancement.
L'illustration suivante résume le flux d'un événement de scale-out lorsque vous utilisez un script de données utilisateur pour effectuer une action personnalisée. Après le lancement d'une instance, le cycle de vie de l'instance est suspendu jusqu'à ce que le cycle de vie soit terminé, soit en expirant, soit en recevant un signal indiquant à Amazon EC2 Auto Scaling de continuer.
![\[Le flux d'un événement de scale-out lorsque vous utilisez un script de données utilisateur pour effectuer une action personnalisée.\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/images/lifecycle-hook-user-data-script.png)
**Topics**
+ [Étape 1 : créer un rôle IAM doté des autorisations nécessaires pour utiliser des actions de cycle de vie](#instance-metadata-create-iam-role)
+ [Étape 2 : créer un modèle de lancement et inclure le rôle IAM et un script de données utilisateur](#instance-metadata-create-hello-world-function)
+ [Étape 3 : créer un groupe Auto Scaling](#instance-metadata-create-auto-scaling-group)
+ [Étape 4 : ajouter un hook de cycle de vie](#instance-metadata-add-lifecycle-hook)
+ [Étape 5 : tester et vérifier la fonctionnalité](#instance-metadata-testing-hook)
+ [Étape 6 : Nettoyer](#instance-metadata-lifecycle-hooks-tutorial-cleanup)
+ [Ressources connexes](#instance-metadata-lifecycle-hooks-tutorial-related-resources)
## Étape 1 : créer un rôle IAM doté des autorisations nécessaires pour utiliser des actions de cycle de vie
Lorsque vous utilisez le AWS CLI ou un AWS SDK pour envoyer un rappel pour effectuer des actions du cycle de vie, vous devez utiliser un rôle IAM avec des autorisations pour effectuer les actions du cycle de vie.
**Pour créer la politique**
1. Ouvrez la [page Policies](https://console.aws.amazon.com/iam/home?#/policies) (Politiques) de la console IAM et sélectionnez **Create policy** (Créer une politique).
1. Choisissez l’onglet **JSON**.
1. Dans la case **Policy Document** (Document de politique), copiez et collez le document de politique suivant dans la case. Remplacez le **sample text**par votre numéro de compte et le nom du groupe Auto Scaling que vous souhaitez créer (**TestAutoScalingEvent-group**).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:CompleteLifecycleAction"
],
"Resource": "arn:aws:autoscaling:*:123456789012:autoScalingGroup:*:autoScalingGroupName/TestAutoScalingEvent-group"
}
]
}
```
------
1. Choisissez **Suivant**.
1. Pour **Policy name** (Nom de la politique), saisissez **TestAutoScalingEvent-policy**. Sélectionnez **Create policy** (Créer une politique).
Lorsque vous avez créé la politique, vous pouvez créer un rôle qui l'utilise.
**Pour créer le rôle**
1. Dans le panneau de navigation de gauche, sélectionnez **Roles** (Rôles).
1. Sélectionnez **Create role** (Créer un rôle).
1. Pour **Select trusted entity** (Sélectionner une entité de confiance), choisissez **service AWS **.
1. Pour votre cas d'utilisation, sélectionnez **EC2**, puis **Next** (Suivant).
1. Sous **Ajouter des autorisations**, choisissez la politique que vous avez créée (**TestAutoScalingEvent-policy**). Ensuite, choisissez **Next** (Suivant).
1. Sur la page **Name, review, and create** (Nommer, vérifier et créer), pour **Role name** (Nom du rôle), saisissez **TestAutoScalingEvent-role**, puis choisissez **Create role** (Créer un rôle).
## Étape 2 : créer un modèle de lancement et inclure le rôle IAM et un script de données utilisateur
Créer un modèle de lancement à utiliser avec un groupe Auto Scaling. Incluez le rôle IAM que vous avez créé et l'exemple de script de données utilisateur fourni.
**Pour créer un modèle de lancement**
1. Ouvrez la [page des modèles de lancement](https://console.aws.amazon.com/ec2/v2/#LaunchTemplates) de la console Amazon EC2.
1. Choisissez **Create launch template** (Créer un modèle de lancement).
1. Pour **Launch template name** (Nom du modèle de lancement), saisissez **TestAutoScalingEvent-template**.
1. Sous **Guide Auto Scaling**, activez la case à cocher.
1. Pour **Application and OS Images (Amazon Machine Image)** (Amazon machine image [AMI]), choisissez Amazon Linux 2 (HVM), Type de volume SSD, 64 bits (x86) dans la liste **Quick Start** (Démarrage rapide).
1. Pour **Instance type** (Type d'instance), choisissez un type d'instance Amazon EC2 (par exemple, « t2.micro »).
1. Pour **Advanced details** (Détails avancés), développez la section afin d'afficher les champs.
1. **Pour le **profil d'instance IAM**, choisissez le nom du profil d'instance IAM de votre rôle IAM (-role)TestAutoScalingEvent.** Un profil d'instance est un conteneur pour un rôle IAM qui permet à Amazon EC2 de transmettre le rôle IAM à une instance lors du lancement de l'instance.
Lorsque vous avez utilisé la console IAM pour créer un rôle IAM, la console a automatiquement créé un profil d'instance portant le même nom que le rôle correspondant.
1. Pour **User data** (Données utilisateur), copiez et collez l'exemple de script de données utilisateur suivant dans le champ. Remplacez le texte d'exemple `group_name` par le nom du groupe Auto Scaling que vous souhaitez créer et `region` par le nom que Région AWS vous souhaitez que votre groupe Auto Scaling utilise.
```
#!/bin/bash
function token {
echo "X-aws-ec2-metadata-token: $(curl -X PUT 'http://169.254.169.254/latest/api/token' -H 'X-aws-ec2-metadata-token-ttl-seconds: 21600')"
}
function get_target_state {
echo $(curl -H "$(token)" -s http://169.254.169.254/latest/meta-data/autoscaling/target-lifecycle-state)
}
function get_instance_id {
echo $(curl -H "$(token)" -s http://169.254.169.254/latest/meta-data/instance-id)
}
function complete_lifecycle_action {
instance_id=$(get_instance_id)
group_name='TestAutoScalingEvent-group'
region='us-west-2'
echo $instance_id
echo $region
echo $(aws autoscaling complete-lifecycle-action \
--lifecycle-hook-name TestAutoScalingEvent-hook \
--auto-scaling-group-name $group_name \
--lifecycle-action-result CONTINUE \
--instance-id $instance_id \
--region $region)
}
function main {
while true
do
target_state=$(get_target_state)
if [ \"$target_state\" = \"InService\" ]; then
# Change hostname
export new_hostname="${group_name}-$instance_id"
hostname $new_hostname
# Send callback
complete_lifecycle_action
break
fi
echo $target_state
sleep 5
done
}
main
```
Ce simple script de données utilisateur effectue les opérations suivantes :
+ Appelle les métadonnées de l'instance pour récupérer l'état du cycle de vie cible et l'ID d'instance à partir des métadonnées de l'instance
+ Récupère l'état du cycle de vie cible à plusieurs reprises jusqu'à ce qu'il passe à `InService`
+ Modifie le nom d'hôte de l'instance par l'ID d'instance précédé du nom du groupe Auto Scaling, si l'état du cycle de vie cible est `InService`
+ Envoie un rappel en appelant la commande CLI **complete-lifecycle-action** pour signaler à Amazon EC2 Auto Scaling de `CONTINUE` le processus de lancement de l'EC2
1. Choisissez **Create launch template** (Créer un modèle de lancement).
1. Sur la page de confirmation, choisissez **Create Auto Scaling group** (Créer un groupe Auto Scaling).
**Note**
Pour d'autres exemples que vous pouvez utiliser comme référence pour développer votre script de données utilisateur, consultez le [GitHub référentiel](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) Amazon EC2 Auto Scaling.
## Étape 3 : créer un groupe Auto Scaling
Une fois le modèle de lancement créé, créez un groupe Auto Scaling.
**Pour créer un groupe Auto Scaling**
1. Dans la page **Choose launch template or configuration** (Choisir un modèle de lancement ou une configuration), dans **Auto Scaling group name** (Nom du groupe Auto Scaling), saisissez un nom pour le groupe Auto Scaling (**TestAutoScalingEvent-group**).
1. Choisissez **Next** (Suivant) pour accéder à la page **Choose instance launch options** (Choisir les options de lancement d'instance).
1. Dans **Network** (Réseau), choisissez un VPC.
1. Pour **Availability Zones and subnets** (Zones de disponibilité et sous-réseaux), choisissez un ou plusieurs sous-réseaux dans une ou plusieurs zones de disponibilité.
1. Dans la section **Instance type requirements** (Exigences relatives au type d'instance), utilisez le paramètre par défaut pour simplifier cette étape. (Ne remplacez pas le modèle de lancement.) Pour ce didacticiel, vous lancerez une seule instance à la demande en utilisant le type d'instance spécifié dans votre modèle de lancement.
1. Choisissez **Skip to review** (Passez à la révision) en bas de l'écran.
1. Sur la page **Review** (Vérifier), consultez les paramètres du groupe Auto Scaling, puis choisissez **Create Auto Scaling group** (Créer un groupe Auto Scaling).
## Étape 4 : ajouter un hook de cycle de vie
Ajoutez un hook de cycle de vie pour maintenir l'instance en attente jusqu'à ce que votre action de cycle de vie soit terminée.
**Ajouter un hook de cycle de vie**
1. Ouvrez la [page des groupes Auto Scaling](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) de la console Amazon EC2.
1. Cochez la case située en regard de votre groupe Auto Scaling. Un volet fractionné s'ouvre en bas de la page.
1. Dans le volet inférieur, sous l'onglet **Gestion des instances**, accédez à **Hooks de cycle de vie** et choisissez **Créer un hook de cycle de vie**.
1. Pour définir un hook de cycle de vie pour la montée en puissance (lancement d’instances), procédez comme suit :
1. Dans le champ **Nom du hook de cycle de vie**, saisissez **TestAutoScalingEvent-hook**.
1. Dans le champ **Lifecycle transition** (Transition du cycle de vie), choisissez **Instance launch** (Lancement d'instance).
1. Pour **Heartbeat timeout** (Délai de pulsation), saisissez **300** pour le nombre de secondes d'attente d'un rappel de votre script de données utilisateur.
1. Dans le champ **Default result** (Résultat par défaut), choisissez **ABANDON** (ABANDONNER). Si le hook expire sans recevoir de rappel de votre script de données utilisateur, le groupe Auto Scaling résilie la nouvelle instance.
1. (Facultatif) Conserver **Notification metadata** (Métadonnées de notification) vide.
1. Choisissez **Créer**.
## Étape 5 : tester et vérifier la fonctionnalité
Pour tester la fonctionnalité, mettez à jour le groupe Auto Scaling en augmentant de 1 la capacité souhaitée du groupe Auto Scaling. Le script de données utilisateur s'exécute et commence à vérifier l'état du cycle de vie cible de l'instance peu après le lancement de l'instance. Le script modifie le nom d'hôte et envoie une action de rappel lorsque l'état du cycle de vie cible est `InService`. Cette opération ne prend généralement que quelques secondes.
**Pour augmenter la taille du groupe Auto Scaling**
1. Ouvrez la [page des groupes Auto Scaling](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) de la console Amazon EC2.
1. Cochez la case située en regard de votre groupe Auto Scaling. Affichez les détails dans un volet inférieur tout en continuant à voir les premières lignes du volet supérieur.
1. Dans le volet inférieur, sous l'onglet **Details** (Détails), choisissez **Group details** (Détails du groupe) puis **Edit** (Modifier).
1. Pour **Desired capacity** (Capacité désirée), augmentez la valeur actuelle de 1.
1. Choisissez **Mettre à jour**. Pendant le lancement de l'instance, la colonne **Status** (Statut) du volet supérieur affiche le statut *Mise à jour de la capacité*.
Après avoir augmenté la capacité souhaitée, vous pouvez vérifier que votre instance a été lancée avec succès et qu'elle n'est pas résiliée à la description des activités de mise à l'échelle.
**Pour afficher l'activité de mise à l'échelle**
1. Revenez à la page **Groupes Auto Scaling** et sélectionnez votre groupe.
1. Dans l'onglet **Activité**, sous **Historique de l'activité**, la colonne **Statut** indique si votre groupe Auto Scaling a réussi à lancer une instance.
1. Si le script de données utilisateur échoue, une fois le délai d'expiration écoulé, vous voyez une activité de mise à l'échelle dont le statut est égal à `Canceled` et un message de statut de `Instance failed to complete user's Lifecycle Action: Lifecycle Action with token e85eb647-4fe0-4909-b341-a6c42EXAMPLE was abandoned: Lifecycle Action Completed with ABANDON Result`.
## Étape 6 : Nettoyer
Si vous n'avez plus besoin des ressources que vous avez créées pour ce tutoriel, procédez comme suit pour les supprimer.
**Pour supprimer le hook de cycle de vie**
1. Ouvrez la [page des groupes Auto Scaling](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) de la console Amazon EC2.
1. Cochez la case située en regard de votre groupe Auto Scaling.
1. Sous l'onglet **Gestion des instances**, accédez à **Hooks de cycle de vie** et choisissez le hook de cycle de vie (`TestAutoScalingEvent-hook`).
1. Sélectionnez **Actions**, **Delete** (Supprimer).
1. Pour confirmer, choisissez de nouveau **Delete** (Supprimer).
**Pour supprimer le modèle de lancement**
1. Ouvrez la [page des modèles de lancement](https://console.aws.amazon.com/ec2/v2/#LaunchTemplates) de la console Amazon EC2.
1. Sélectionnez le modèle de lancement (`TestAutoScalingEvent-template`), puis choisissez **Actions**, **Delete template** (Supprimer le modèle).
1. Lorsque vous êtes invité à confirmer l'opération, saisissez **Delete** pour confirmer la suppression du modèle de lancement spécifié, puis choisissez **Delete** (Supprimer).
Si vous avez terminé d'utiliser l'exemple de groupe Auto Scaling, supprimez-le. Vous pouvez également supprimer et la politique d'autorisations et le rôle IAM que vous avez créés.
**Pour supprimer le groupe Auto Scaling**
1. Ouvrez la [page des groupes Auto Scaling](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) de la console Amazon EC2.
1. Cochez la case en regard de votre groupe Auto Scaling (`TestAutoScalingEvent-group`) et choisissez **Delete** (Supprimer).
1. Lorsque vous êtes invité à confirmer l'opération, saisissez **delete** pour confirmer la suppression du groupe Auto Scaling spécifié, puis choisissez **Delete** (Supprimer).
Une icône de chargement dans la colonne **Name** (Nom) indique que le groupe Auto Scaling est en cours de suppression. Quelques minutes sont nécessaires pour résilier les instances et supprimer le groupe.
**Suppression du rôle IAM**
1. Ouvrez la [page Roles](https://console.aws.amazon.com/iam/home?#/roles) (Rôles) de la console IAM.
1. Sélectionnez le rôle de la fonction (`TestAutoScalingEvent-role`).
1. Sélectionnez **Delete (Supprimer)**.
1. Lorsque vous êtes invité à confirmer, saisissez le nom du rôle et choisissez **Delete** (Supprimer).
**Pour supprimer la politique IAM**
1. Ouvrez la [page Policies](https://console.aws.amazon.com/iam/home?#/policies) (Politiques) de la console IAM.
1. Sélectionnez la politique que vous avez créée (`TestAutoScalingEvent-policy`).
1. Sélectionnez **Actions**, **Supprimer**.
1. Lorsque vous êtes invité à confirmer, saisissez le nom de la politique et choisissez **Delete** (Supprimer).
## Ressources connexes
Les rubriques connexes suivantes peuvent être utiles lorsque vous développez du code qui invoque des actions sur les instances en fonction des données disponibles dans les métadonnées de l’instance.
+ [Récupérer l'état du cycle de vie cible via des métadonnées d'instance](retrieving-target-lifecycle-state-through-imds.md). Cette section décrit l’état du cycle de vie pour d’autres cas d’utilisation, tels que la résiliation d’une instance.
+ [Ajouter des hooks de cycle de vie (console)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-console). Cette procédure explique comment ajouter des hooks de cycle de vie pour la montée en puissance (lancement des instances) et la mise à l’échelle horizontale (instances résiliées ou revenant à un groupe chaud).
+ [Catégories de métadonnées d'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories) dans le guide de l'*utilisateur Amazon EC2*. Cette rubrique répertorie toutes les catégories de métadonnées d'instance que vous pouvez utiliser pour appeler des actions sur les instances EC2.
Pour consulter un didacticiel expliquant comment utiliser Amazon EventBridge pour créer des règles qui invoquent des fonctions Lambda en fonction d'événements survenant dans les instances de votre groupe Auto Scaling, consultez. [Didacticiel : configurer un hook de cycle de vie qui appelle une fonction Lambda](tutorial-lifecycle-hook-lambda.md)
# Didacticiel : configurer un hook de cycle de vie qui appelle une fonction Lambda
Dans cet exercice, vous allez créer une EventBridge règle Amazon qui inclut un modèle de filtre qui, lorsqu'il est mis en correspondance, invoque une AWS Lambda fonction en tant que cible de la règle. Nous fournissons le modèle de filtre et l'exemple de code de fonction à utiliser.
Si tout est correctement configuré, à la fin de ce didacticiel, la fonction Lambda exécutera une action personnalisée lors du lancement des instances. L'action personnalisée enregistre simplement l'événement dans le flux de CloudWatch log Logs associé à la fonction Lambda.
La fonction Lambda procède également à un rappel pour laisser le cycle de vie de l'instance se poursuivre si cette action est réussie, mais laisse l'instance abandonner le lancement et se résilier si l'action échoue.
L'illustration suivante résume le flux d'un événement de scale-out lorsque vous utilisez une fonction Lambda pour effectuer une action personnalisée. Après le lancement d'une instance, le cycle de vie de l'instance est suspendu jusqu'à ce que le cycle de vie soit terminé, soit en expirant, soit en recevant un signal indiquant à Amazon EC2 Auto Scaling de continuer.
![\[Le flux d'un événement de scale-out lorsque vous utilisez une fonction Lambda pour effectuer une action personnalisée.\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/images/lifecycle-hook-lambda-function.png)
**Note**
Selon votre cas d'utilisation, vous pouvez configurer un hook de cycle de vie en suivant les étapes ci-dessous et en créant une EventBridge règle. Vous pouvez également utiliser une fonction Lambda pour configurer directement un hook de cycle de vie sans créer de règle. EventBridge
**Topics**
+ [Conditions préalables](#lambda-hello-world-tutorial-prerequisites)
+ [Étape 1 : Créer un rôle IAM doté des autorisations nécessaires pour utiliser des actions de cycle de vie](#lambda-create-iam-role)
+ [Étape 2 : créer une fonction Lambda](#lambda-create-hello-world-function)
+ [Étape 3 : Création d'une EventBridge règle](#lambda-create-rule)
+ [Étape 4 : ajouter un hook de cycle de vie](#lambda-add-lifecycle-hook)
+ [Étape 5 : tester et vérifier l'événement](#lambda-testing-hook-notifications)
+ [Étape 6 : Nettoyer](#lambda-lifecycle-hooks-tutorial-cleanup)
+ [Ressources connexes](#lambda-lifecycle-hooks-tutorial-related-resources)
## Conditions préalables
Avant d'entamer ce didacticiel, si vous n'avez pas de groupe Auto Scaling, créez-en un. Pour créer un groupe Auto Scaling, ouvrez la [page Groupes Auto Scaling](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) de la console Amazon EC2 et choisissez **Créer un groupe Auto Scaling**.
## Étape 1 : Créer un rôle IAM doté des autorisations nécessaires pour utiliser des actions de cycle de vie
Avant de créer une fonction Lambda, vous devez créer un rôle d'exécution et une politique d'autorisations pour permettre à Lambda d'utiliser des hooks de cycle de vie.
**Pour créer la politique**
1. Ouvrez la [page Policies](https://console.aws.amazon.com/iam/home?#/policies) (Politiques) de la console IAM et sélectionnez **Create policy** (Créer une politique).
1. Choisissez l’onglet **JSON**.
1. Dans la zone **Document de politique**, collez le document de politique suivant dans la zone, en **italics**remplaçant le texte par votre numéro de compte et le nom de votre groupe Auto Scaling.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"autoscaling:CompleteLifecycleAction"
],
"Resource": "arn:aws:autoscaling:*:123456789012:autoScalingGroup:*:autoScalingGroupName/my-asg"
}
]
}
```
------
1. Choisissez **Suivant**.
1. Pour **Policy name** (Nom de la politique), saisissez **LogAutoScalingEvent-policy**. Sélectionnez **Create policy** (Créer une politique).
Lorsque vous avez créé la politique, vous pouvez créer un rôle qui l'utilise.
**Pour créer le rôle**
1. Dans le panneau de navigation de gauche, sélectionnez **Roles** (Rôles).
1. Sélectionnez **Create role** (Créer un rôle).
1. Pour **Select trusted entity** (Sélectionner une entité de confiance), choisissez **service AWS **.
1. Pour votre cas d'utilisation, sélectionnez **Lambda**, puis **Next** (Suivant).
1. Sous **Ajouter des autorisations**, choisissez la politique que vous avez créée (**LogAutoScalingEvent-policy**) et le nom **AWSLambdaBasicExecutionRole**de la politique. Ensuite, choisissez **Suivant**.
**Note**
La **AWSLambdaBasicExecutionRole**politique dispose des autorisations dont la fonction a besoin pour écrire des CloudWatch journaux dans Logs.
1. Sur la page **Name, review, and create** (Nommer, vérifier et créer), pour **Role name** (Nom du rôle), saisissez **LogAutoScalingEvent-role**, puis choisissez **Create role** (Créer un rôle).
## Étape 2 : créer une fonction Lambda
Créez une fonction Lambda qui servira de cible pour les événements. L'exemple de fonction Lambda, écrit dans Node.js, est invoqué EventBridge lorsqu'un événement correspondant est émis par Amazon EC2 Auto Scaling.
**Pour créer une fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) sur la console Lambda.
1. Sélectionnez **Create function** (Créer une fonction), puis **Author from scratch** (Créer à partir de zéro).
1. Sous **Basic information** (Informations de base), pour **Function name** (Nom de la fonction), entrez **LogAutoScalingEvent**.
1. Pour **Exécution**, choisissez **Node.js 18.x**.
1. Faites défiler l’écran vers le bas et choisissez **Modifier le rôle d’exécution par défaut**, puis dans le champ **Rôle d’exécution**, choisissez **Utiliser un rôle existant**.
1. Pour **Rôle existant**, choisissez **LogAutoScalingEvent-role**.
1. Laissez les autres valeurs par défaut.
1. Sélectionnez **Create function** (Créer une fonction). Vous retournez au code et à la configuration de la fonction.
1. Vérifiez que votre fonction `LogAutoScalingEvent` est toujours ouverte dans la console, puis sous **Code source**, dans l’éditeur, copiez l’exemple de code suivant dans le fichier index.mjs.
```
import { AutoScalingClient, CompleteLifecycleActionCommand } from "@aws-sdk/client-auto-scaling";
export const handler = async(event) => {
console.log('LogAutoScalingEvent');
console.log('Received event:', JSON.stringify(event, null, 2));
var autoscaling = new AutoScalingClient({ region: event.region });
var eventDetail = event.detail;
var params = {
AutoScalingGroupName: eventDetail['AutoScalingGroupName'], /* required */
LifecycleActionResult: 'CONTINUE', /* required */
LifecycleHookName: eventDetail['LifecycleHookName'], /* required */
InstanceId: eventDetail['EC2InstanceId'],
LifecycleActionToken: eventDetail['LifecycleActionToken']
};
var response;
const command = new CompleteLifecycleActionCommand(params);
try {
var data = await autoscaling.send(command);
console.log(data); // successful response
response = {
statusCode: 200,
body: JSON.stringify('SUCCESS'),
};
} catch (err) {
console.log(err, err.stack); // an error occurred
response = {
statusCode: 500,
body: JSON.stringify('ERROR'),
};
}
return response;
};
```
Ce code enregistre simplement l'événement afin qu'à la fin de ce didacticiel, vous puissiez voir un événement apparaître dans le flux de journal CloudWatch des journaux associé à cette fonction Lambda.
1. Choisissez **Déployer**.
## Étape 3 : Création d'une EventBridge règle
Créez une EventBridge règle pour exécuter votre fonction Lambda. Pour plus d'informations sur l'utilisation de EventBridge, consultez [EventBridge À utiliser pour gérer les événements Auto Scaling](automating-ec2-auto-scaling-with-eventbridge.md).
**Pour créer une règle avec la console**
1. Ouvrez la [EventBridge console](https://console.aws.amazon.com/events/).
1. Dans le panneau de navigation, choisissez **Rules**.
1. Choisissez **Créer une règle**.
1. Pour **Define rule detail** (Définir les détails de la règle), procédez comme suit :
1. Pour **Nom**, saisissez **LogAutoScalingEvent-rule**.
1. Pour **Event bus** (Bus d’événement), choisissez **default** (défaut). Lorsqu'un événement est généré Service AWS dans votre compte, il est toujours redirigé vers le bus d'événements par défaut de votre compte.
1. Pour **Type de règle**, choisissez **Règle avec un modèle d’événement**.
1. Choisissez **Suivant**.
1. Pour **Build event pattern** (Créer un modèle d’événement), procédez comme suit :
1. Dans **Source de l'événement**, choisissez **AWS des événements ou des événements EventBridge partenaires**.
1. Faites défiler vers le bas jusqu’à **Modèle d’événements**, puis procédez comme suit :
1.
1. Pour **Event source (Source d’événement)**, choisissez **Services AWS**.
1. Pour **Service AWS**, choisissez **Auto Scaling**.
1. Dans **Event type** (Type d'événement), choisissez **Instance Launch and Terminate** (Lancement et résiliation d'une instance).
1. Par défaut, la règle correspond à tout événement de mise à l'échelle horizontale ou de montée en puissance. Pour créer une règle qui vous avertit lorsqu'un événement de montée en puissance se produit et qu'une instance est dans un état d'attente en raison d'un hook de cycle de vie, choisissez **Specific instance event(s)** (Événement[s] d'instance spécifique[s]) et sélectionnez **EC2 Instance-launch Lifecycle Action** (Action du cycle de vie de l'instance EC2 : lancement).
1. Par défaut, la règle correspond à tout groupe Auto Scaling de la région. Pour que la règle corresponde à un groupe Auto Scaling spécifique, choisissez **Nom(s) de groupe spécifique(s)**, puis sélectionnez le groupe.
1. Choisissez **Suivant**.
1. Pour **Select target(s)** (Sélectionner la ou les cibles), procédez comme suit :
1. Pour **Target types** (Types de cibles), choisissez **Service AWS**.
1. Pour **Select a target** (Sélectionner une cible), choisissez **Lambda Function** (Fonction Lambda).
1. Dans **Fonction**, sélectionnez **LogAutoScalingEvent**.
1. Choisissez **Next** (Suivant) deux fois.
1. Sur la page **Vérifier et créer**, choisissez **Créer une règle**.
## Étape 4 : ajouter un hook de cycle de vie
Dans cette section, vous allez ajouter un hook de cycle de vie afin que Lambda exécute votre fonction sur les instances au lancement.
**Ajouter un hook de cycle de vie**
1. Ouvrez la [page des groupes Auto Scaling](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) de la console Amazon EC2.
1. Cochez la case située en regard de votre groupe Auto Scaling. Un volet fractionné s'ouvre en bas de la page.
1. Dans le volet inférieur, sous l'onglet **Gestion des instances**, accédez à **Hooks de cycle de vie** et choisissez **Créer un hook de cycle de vie**.
1. Pour définir un hook de cycle de vie pour la montée en puissance (lancement d’instances), procédez comme suit :
1. Dans le champ **Nom du hook de cycle de vie**, saisissez **LogAutoScalingEvent-hook**.
1. Dans le champ **Transition du cycle de vie**, choisissez **Lancement d'instance**.
1. Dans **Délai de pulsation**, saisissez **300** pour définir le nombre de secondes d'attente d'un rappel de votre fonction Lambda.
1. Dans le champ **Résultat par défaut**, choisissez **ABANDONNER**. Cela signifie que le groupe Auto Scaling résiliera une nouvelle instance si le hook expire sans recevoir de rappel de votre fonction Lambda.
1. (Facultatif) Laissez le champ **Métadonnées de notification** vide. Les données d'événement que nous transmettons EventBridge contiennent toutes les informations nécessaires pour appeler la fonction Lambda.
1. Choisissez **Créer**.
## Étape 5 : tester et vérifier l'événement
Pour tester l'événement, mettez à jour le groupe Auto Scaling en augmentant de 1 la capacité souhaitée du groupe Auto Scaling. Votre fonction Lambda est appelée quelques secondes après l'augmentation de la capacité souhaitée.
**Pour augmenter la taille du groupe Auto Scaling**
1. Ouvrez la [page des groupes Auto Scaling](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) de la console Amazon EC2.
1. Cochez la case située en regard de votre groupe Auto Scaling pour afficher les détails dans le volet inférieur tout en continuant à voir les premières lignes du volet supérieur.
1. Dans le volet inférieur, sous l'onglet **Détails**, choisissez **Détails du groupe** puis **Modifier**.
1. Pour **Desired capacity** (Capacité désirée), augmentez la valeur actuelle de 1.
1. Choisissez **Mettre à jour**. Pendant le lancement de l'instance, la colonne **Statut** du volet supérieur affiche le statut *Mise à jour de la capacité*.
Après avoir augmenté la capacité souhaitée, vous pouvez vérifier que votre fonction Lambda a été appelée.
**Pour afficher la sortie de votre fonction Lambda**
1. Ouvrez la [page Groupes de journaux](https://console.aws.amazon.com/cloudwatch/home#logs:) de la CloudWatch console.
1. Sélectionnez le nom du groupe de journaux pour votre fonction Lambda (`/aws/lambda/LogAutoScalingEvent`).
1. Sélectionnez le nom du flux de journaux pour afficher les données fournies par la fonction pour l'action de cycle de vie.
Vous pouvez ensuite vérifier que votre instance a été lancée avec succès à partir de la description des activités de mise à l'échelle.
**Pour afficher l'activité de mise à l'échelle**
1. Revenez à la page **Groupes Auto Scaling** et sélectionnez votre groupe.
1. Dans l'onglet **Activité**, sous **Historique de l'activité**, la colonne **Statut** indique si votre groupe Auto Scaling a réussi à lancer une instance.
+ Si l'action a abouti, le statut de l'activité de mise à l'échelle indique « Succès ».
+ Si elle a échoué, après quelques minutes d'attente, vous verrez une activité de mise à l'échelle accompagnée du statut « Annulée » et du message de statut « L'instance n'a pas réussi à exécuter l'action de cycle de vie de l'utilisateur : l'action de cycle de vie associée au jeton e85eb647-4fe0-4909-b341-a6c42EXAMPLE a été abandonnée : Action de cycle de vie terminée avec le résultat ABANDONNER ».
**Pour réduire la taille du groupe Auto Scaling**
Si vous n'avez pas besoin de l'instance supplémentaire que vous avez lancée pour ce test, vous pouvez ouvrir l'onglet **Détails** et réduire la **Capacité souhaitée** de 1.
## Étape 6 : Nettoyer
Si vous n'avez plus besoin des ressources que vous avez créées pour ce didacticiel, procédez comme suit pour les supprimer.
**Pour supprimer le hook de cycle de vie**
1. Ouvrez la [page des groupes Auto Scaling](https://console.aws.amazon.com/ec2/v2/home?#AutoScalingGroups) de la console Amazon EC2.
1. Cochez la case située en regard de votre groupe Auto Scaling.
1. Sous l'onglet **Gestion des instances**, accédez à **Hooks de cycle de vie** et choisissez le hook de cycle de vie (`LogAutoScalingEvent-hook`).
1. Sélectionnez **Actions**, **Delete** (Supprimer).
1. Pour confirmer, choisissez de nouveau **Delete** (Supprimer).
**Pour supprimer la EventBridge règle Amazon**
1. Ouvrez la [page Règles](https://console.aws.amazon.com/events/home?#/rules) dans la EventBridge console Amazon.
1. Sous **Bus d'événement**, choisissez le bus d'événement associé à la règle (`Default`).
1. Ensuite, activez la case à cocher en regard de votre règle (`LogAutoScalingEvent-rule`).
1. Sélectionnez **Delete (Supprimer)**.
1. Lorsque vous êtes invité à confirmer, saisissez le nom de la règle et choisissez **Delete** (Supprimer).
Si vous avez terminé d'utiliser l'exemple de fonction, supprimez-le. Vous pouvez également supprimer le groupe de journaux qui stocke les journaux de la fonction, ainsi que le rôle d'exécution et la politique d'autorisations que vous avez créés.
**Pour supprimer une fonction Lambda**
1. Ouvrez la [page Functions (Fonctions)](https://console.aws.amazon.com/lambda/home#/functions) sur la console Lambda.
1. Choisissez la fonction (`LogAutoScalingEvent`).
1. Sélectionnez **Actions**, **Supprimer**.
1. Lorsque vous êtes invité à confirmer, saisissez **delete** pour confirmer la suppression de la fonction spécifiée, puis choisissez **Delete** (Supprimer).
**Pour supprimer le groupe de journaux**
1. Ouvrez la [page Groupes de journaux](https://console.aws.amazon.com/cloudwatch/home#logs:) de la CloudWatch console.
1. Sélectionnez le groupe de journaux de la fonction (`/aws/lambda/LogAutoScalingEvent`).
1. Sélectionnez **Actions**, **Delete log group(s) (Supprimer le ou les groupes de journaux)**.
1. Dans la boîte de dialogue **Delete log group(s) (Supprimer le ou les groupes de journaux)**, sélectionnez **Delete (Supprimer)**.
**Pour supprimer le rôle d'exécution**
1. Ouvrez la [page Roles (Rôles)](https://console.aws.amazon.com/iam/home?#/roles) de la console IAM.
1. Sélectionnez le rôle de la fonction (`LogAutoScalingEvent-role`).
1. Sélectionnez **Delete (Supprimer)**.
1. Lorsque vous êtes invité à confirmer, saisissez le nom du rôle et choisissez **Delete** (Supprimer).
**Pour supprimer la politique IAM**
1. Ouvrez la [page Policies](https://console.aws.amazon.com/iam/home?#/policies) (Politiques) de la console IAM.
1. Sélectionnez la politique que vous avez créée (`LogAutoScalingEvent-policy`).
1. Sélectionnez **Actions**, **Supprimer**.
1. Lorsque vous êtes invité à confirmer, saisissez le nom de la politique et choisissez **Delete** (Supprimer).
## Ressources connexes
Les rubriques connexes suivantes peuvent être utiles lorsque vous créez des EventBridge règles basées sur des événements qui se produisent dans les instances de votre groupe Auto Scaling.
+ [EventBridge À utiliser pour gérer les événements Auto Scaling](automating-ec2-auto-scaling-with-eventbridge.md). Cette section présente des exemples d’événements pour d’autres cas d’utilisation, y compris des événements destinés à la mise à l’échelle horizontale.
+ [Ajouter des hooks de cycle de vie (console)](adding-lifecycle-hooks.md#adding-lifecycle-hooks-console). Cette procédure explique comment ajouter des hooks de cycle de vie pour la montée en puissance (lancement des instances) et la mise à l’échelle horizontale (instances résiliées ou revenant à un groupe chaud).
Pour suivre un didacticiel qui explique comment utiliser le service de métadonnées d’instance (IMDS) afin d’invoquer une action depuis l’instance elle-même, consultez [Tutoriel : utilisation de scripts de données et de métadonnées d'instance pour récupérer l'état du cycle de vie](tutorial-lifecycle-hook-instance-metadata.md).
# Réduisez la latence pour les applications dont le temps de démarrage est long à l'aide de pools chauds
Un groupe d'instances pré-initialisées vous permet de réduire la latence de vos applications dont les temps de démarrage sont exceptionnellement longs, du fait par exemple que les instances doivent écrire des quantités massives de données sur disque. Avec les groupes d'instances pré-initialisées, il n'est plus nécessaire de surprovisionner vos groupes Auto Scaling pour réduire la latence et améliorer ainsi les performances des applications. Pour plus d'informations, consultez l'article de blog [Scaling your applications faster with EC2 Auto Scaling Warm Pools](https://aws.amazon.com/blogs/compute/scaling-your-applications-faster-with-ec2-auto-scaling-warm-pools/).
**Important**
La création d'un groupe d'instances pré-initialisées quand elle n'est pas nécessaire risque d'entraîner des coûts inutiles. Si le temps de démarrage initial n'entraîne pas de problèmes de latence notables pour votre application, vous n'avez probablement pas besoin d'utiliser ce type de groupe.
**Topics**
+ [Concepts de base](#warm-pool-core-concepts)
+ [Conditions préalables](#warm-pool-prerequisites)
+ [Mise à jour les instances d’un groupe chaud](#update-warm-pool)
+ [Ressources connexes](#warm-pools-related-resources)
+ [Limitations](#warm-pools-limitations)
+ [Utiliser des hooks de cycle de vie](warm-pool-instance-lifecycle.md)
+ [Créez un groupe chaud pour un groupe Auto Scaling](create-warm-pool.md)
+ [Afficher le statut de surveillance de l'état](warm-pools-health-checks-monitor-view-status.md)
+ [AWS CLI exemples de travail avec des piscines chaudes](examples-warm-pools-aws-cli.md)
## Concepts de base
Avant de commencer, familiarisez-vous avec les concepts de base ci-dessous :
**Pools d'instances pré-initialisées**
Ce type de groupe d'instances EC2 pré-initialisées réside à côté d'un groupe Auto Scaling. Chaque fois que votre application doit monter en puissance, le groupe Auto Scaling peut s'appuyer sur le groupe d'instances pré-initialisées pour atteindre la nouvelle capacité souhaitée. Cela vous permet de vous assurer que les instances sont rapidement disponibles pour gérer le trafic des applications, ce qui accélère la réponse à un événement de montée en puissance. Lorsque des instances sont retirées du groupe d'instances pré-initialisées, elles sont comptabilisées dans la capacité souhaitée du groupe. Il s'agit d'une opération de type *démarrage à chaud*.
Lorsque les instances sont dans le groupe chaud, vos politiques de mise à l’échelle ne montent en puissance que si la valeur métrique des instances qui sont dans l’état `InService` est supérieure au seuil d’alarme supérieur de la politique de mise à l’échelle (qui est le même que l’utilisation cible d’une politique de suivi des objectifs et d’échelonnement).
**Taille d'un groupe d'instances pré-initialisées**
Par défaut, la taille d'un groupe d'instances pré-initialisées correspond à la différence entre la capacité maximale du groupe Auto Scaling et sa capacité souhaitée. Par exemple, si la capacité souhaitée de votre groupe Auto Scaling est de 6 et que la capacité maximale correspond à 10, la taille de votre groupe d'instances pré-initialisées est donc de 4 lorsque vous configurez le groupe pour la première fois et qu'il est initialisé.
Pour spécifier séparément la capacité maximale du pool de chaleur, utilisez l'option custom specification (`MaxGroupPreparedCapacity`) et définissez une valeur personnalisée supérieure à la capacité actuelle du groupe. Si vous fournissez une valeur personnalisée, la taille du pool de chaleur est calculée comme la différence entre la valeur personnalisée et la capacité actuelle souhaitée du groupe. Par exemple, si la capacité souhaitée de votre groupe Auto Scaling est de 6, si la capacité maximale est de 20 et si la valeur personnalisée est de 8, la taille de votre pool de chaleur sera de 2 lorsque vous le configurez pour la première fois et que le pool sera initialisé.
Il se peut que vous n'ayez besoin d'utiliser l'option custom specification (`MaxGroupPreparedCapacity`) que lorsque vous travaillez avec de grands groupes Auto Scaling afin de gérer les avantages financiers liés à un pool de chaleur. Par exemple, un groupe Auto Scaling avec 1 000 instances, une capacité maximale de 1 500 (pour fournir une capacité supplémentaire en cas de pics de trafic d'urgence) et un groupe d'instances pré-initialisées de 100 instances peut vous aider à atteindre vos objectifs mieux que de garder 500 instances réservées pour une utilisation future dans le groupe d'instances pré-initialisées.
**Taille minimale du groupe d'instances pré-initialisées.**
Envisagez d'utiliser le paramètre de taille minimale (`MinSize`) pour définir de manière statique le nombre minimum d'instances à conserver dans le pool de chaleur. Aucune taille minimale n'est définie par défaut. Ce `MinSize` paramètre est utile lorsque vous spécifiez `MaxGroupPreparedCapacity` qu'un nombre minimum d'instances est maintenu dans le pool de chaleur même lorsque la capacité souhaitée du groupe Auto Scaling est supérieure à`MaxGroupPreparedCapacity`.
**État des instances de groupe d'instances pré-initialisées**
Vous pouvez conserver des instances dans le groupe d'instances pré-initialisées dans l'un des trois états suivants : `Stopped`, `Running` ou `Hibernated`. Conserver les instances dans l'état `Stopped` est un moyen efficace de limiter les coûts. Lorsque les instances sont interrompues, vous ne payez que pour les volumes utilisés et les adresses IP élastiques attachées aux instances.
Vous pouvez également conserver les instances dans un état `Hibernated` pour arrêter les instances sans supprimer leur contenu de mémoire (RAM). Lorsqu'une instance est mise en veille prolongée, cela signale au système d'exploitation qu'il doit enregistrer le contenu de votre RAM sur votre volume racine Amazon EBS. Lorsque l'instance est redémarrée, le volume racine est restauré à son état précédent et le contenu de la RAM est rechargé. Pendant que les instances sont en veille prolongée, vous ne payez que pour les volumes EBS, y compris le stockage du contenu RAM, et les adresses IP Elastic attachées aux instances.
Garder des instances dans un état `Running` à l'intérieur du groupe d'instances pré-initialisées est également possible, mais est fortement déconseillé pour éviter d'encourir des frais inutiles. Lorsque les instances sont arrêtées ou mises en veille prolongée, vous économisez le coût des instances elles-mêmes. Vous payez les instances uniquement lorsqu'elles sont en cours d'exécution.
**Hooks de cycle de vie**
Les [hooks de cycle de vie](warm-pool-instance-lifecycle.md) vous permettent de mettre des instances dans un état d’attente afin que vous puissiez effectuer des actions personnalisées sur les instances. Les actions personnalisées sont exécutées au lancement des instances ou avant qu'elles ne se terminent.
Dans une configuration de groupe chaud, les hooks de cycle de vie retardent l’arrêt ou la mise en veille prolongée des instances et leur mise en service pendant un événement de montée en puissance jusqu’à ce que leur initialisation soit terminée. Si vous ajoutez un groupe d'instances pré-initialisées à votre groupe Auto Scaling sans hook de cycle de vie, les instances dont l'initialisation prend beaucoup de temps peuvent être arrêtées ou mises en veille prolongée, puis mises en service pendant un événement de montée en puissance avant qu'elles ne soient prêtes.
**Politique de réutilisation d'instance**
Par défaut, Amazon EC2 Auto Scaling résilie vos instances lors de la mise à l'échelle horizontale de votre groupe Auto Scaling. Ensuite, il lance de nouvelles instances dans le groupe d'instances pré-initialisées pour remplacer celles qui ont été résiliées.
Si vous souhaitez plutôt renvoyer des instances vers le groupe d'instances pré-initialisées, vous pouvez spécifier une politique de réutilisation d'instance. Cela vous permet de réutiliser des instances déjà configurées pour servir le trafic des applications. Pour s'assurer que votre groupe d'instances pré-initialisées n'est pas surapprovisionné, Amazon EC2 Auto Scaling peut résilier des instances dans le groupe d'instances pré-initialisées pour réduire sa taille lorsque celle-ci est plus grande que nécessaire en fonction de ses paramètres. Lors de la résiliation d'instances dans le groupe d'instances pré-initialisées, il utilise la [politique de résiliation par défaut](ec2-auto-scaling-termination-policies.md#default-termination-policy) pour choisir les instances à résilier en premier.
Si vous souhaitez mettre en veille prolongée des instances mises à l'échelle horizontale et que le groupe Auto Scaling contient déjà des instances, celles-ci doivent répondre aux exigences de la mise en veille prolongée des instances. Si ce n'est pas le cas, lorsque les instances retourneront dans le groupe d'instances pré-initialisées, elles seront arrêtées au lieu d'être mises en veille prolongée.
Actuellement, vous ne pouvez spécifier une politique de réutilisation d'instance qu'à l'aide de la AWS CLI ou d'un kit SDK. Cette fonction n'est pas disponible depuis la console.
## Conditions préalables
Avant de créer un groupe chaud pour votre groupe Auto Scaling, déterminez comment vous allez utiliser les hooks de cycle de vie pour initialiser de nouvelles instances avec un état initial approprié.
Pour effectuer des actions personnalisées sur des instances alors qu’elles sont en état d’attente à cause d’un hook de cycle de vie, deux options s’offrent à vous :
+ Pour les scénarios simples où vous souhaitez exécuter des commandes sur vos instances au lancement, vous pouvez inclure un script de données utilisateur lorsque vous créez un modèle de lancement ou une configuration de lancement pour votre groupe Auto Scaling. Les scripts de données utilisateur ne sont que des scripts ou cloud-init des directives shell normaux qui sont exécutés cloud-init au démarrage de vos instances. Le script peut également contrôler le moment où vos instances passent à l'état suivant en utilisant l'ID de l'instance sur laquelle il s'exécute. Si ce n'est pas le cas, mettez à jour le script pour récupérer l'ID de l'instance à partir de ses métadonnées. Pour plus d'informations, consultez la section [Accéder aux métadonnées de l'instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html) dans le *guide de l'utilisateur Amazon EC2*.
**Astuce**
Pour exécuter des scripts de données utilisateur lors du redémarrage d'une instance, les données utilisateur doivent être au format MIME en plusieurs parties et spécifier les éléments suivants dans la section `#cloud-config` des données utilisateur :
```
#cloud-config
cloud_final_modules:
- [scripts-user, always]
```
+ Pour les scénarios avancés dans lesquels vous avez besoin d'un service, par exemple AWS Lambda pour agir lorsque des instances entrent ou sortent du pool de chaleur, vous pouvez créer un lien de cycle de vie pour votre groupe Auto Scaling et configurer le service cible pour effectuer des actions personnalisées en fonction des notifications relatives au cycle de vie. Pour de plus amples informations, veuillez consulter [Cibles de notification prises en charge](warm-pool-instance-lifecycle.md#warm-pools-supported-notification-targets).
**Préparer les instances à la mise en veille prolongée**
Pour préparer les instances Auto Scaling à utiliser l'état du `Hibernated` pool, créez un nouveau modèle de lancement ou une nouvelle configuration de lancement correctement configuré pour prendre en charge l'hibernation des instances, comme décrit dans la rubrique [Conditions préalables à l'hibernation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html) du guide de l'utilisateur *Amazon* EC2. Ensuite, associez le nouveau modèle de lancement ou la nouvelle configuration de lancement au groupe Auto Scaling et lancez une actualisation d'instance pour remplacer les instances associées à un précédent modèle de lancement ou configuration de lancement. Pour de plus amples informations, veuillez consulter [Utiliser une actualisation d'instance pour mettre à jour les instances d'un groupe Auto Scaling](asg-instance-refresh.md).
## Mise à jour les instances d’un groupe chaud
Pour mettre à jour les instances d’un groupe chaud, vous devez créer un nouveau modèle de lancement ou une nouvelle configuration de lancement et l’associer au groupe Auto Scaling. Toutes les nouvelles instances sont lancées à l'aide de la nouvelle AMI et d'autres mises à jour spécifiées dans le modèle de lancement ou la configuration de lancement, mais les instances existantes ne sont pas affectées.
Pour forcer le lancement d’instances de groupe chaud de remplacement qui utilisent le nouveau modèle de lancement ou la nouvelle configuration de lancement, vous pouvez lancer une actualisation de l’instance pour effectuer une mise à jour progressive de votre groupe. Une actualisation d'instance remplace d'abord les instances `InService`. Elle remplace ensuite les instances du groupe d'instances pré-initialisées. Pour de plus amples informations, veuillez consulter [Utiliser une actualisation d'instance pour mettre à jour les instances d'un groupe Auto Scaling](asg-instance-refresh.md).
## Ressources connexes
Vous pouvez consulter notre [GitHubréférentiel](https://github.com/aws-samples/amazon-ec2-auto-scaling-group-examples) pour obtenir des exemples de crochets de cycle de vie pour les piscines chaudes.
## Limitations
+ Limites du pool de chaleur pour un groupe Auto Scaling avec des types d'instances mixtes :
+ Les pools de chaleur ne sont pas pris en charge avec les groupes d'instances mixtes pondérés. Si votre groupe Auto Scaling utilise la pondération des instances, vous ne pouvez pas ajouter de pool de chaleur.
+ Les warm pools ne prennent pas en charge les instances Spot au sein de groupes d'instances mixtes. Votre politique d'instances mixtes doit être configurée pour les instances à la demande uniquement lorsque vous utilisez des pools chauds.
+ Lorsque vous utilisez des pools chauds avec des groupes d'instances mixtes en état d'hibernation, vous devez les configurer `HibernationOptions` dans votre modèle de lancement.
+ Amazon EC2 Auto Scaling peut placer une instance dans l'état `Stopped` ou `Hibernated` que si elle est dotée d'un volume Amazon EBS comme périphérique racine. Les instances qui utilisent des stockages d'instance pour le périphérique racine ne peuvent pas être arrêtées ou mises en veille prolongée.
+ Amazon EC2 Auto Scaling ne peut mettre une instance dans `Hibernated` un état que si elle répond à toutes les exigences répertoriées dans la rubrique relative aux conditions préalables à [l'hibernation](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/hibernating-prerequisites.html) du guide de l'utilisateur Amazon *EC2*.
+ Si votre groupe d'instances pré-initialisées est épuisé lors d'un événement de montée en puissance, les instances sont lancées directement dans le groupe Auto Scaling (*démarrage à froid*). Le démarrage à froid se produit également en cas d'épuisement de la capacité d'une zone de disponibilité.
+ Si une instance du warm pool rencontre un problème pendant le processus de lancement, l'empêchant d'atteindre `InService` cet état, l'instance sera considérée comme un échec de lancement et sera interrompue. Cela s'applique quelle que soit la cause sous-jacente, telle qu'une erreur de capacité insuffisante ou tout autre facteur.
+ Si vous essayez d'utiliser un pool d'instances pré-initialisées avec Amazon Elastic Kubernetes Service (Amazon EKS), les instances qui sont toujours en cours d'initialisation peuvent s'enregistrer auprès de votre cluster Amazon EKS. Par conséquent, le cluster peut planifier des tâches sur une instance alors qu'il se prépare à être arrêté ou mis en veille prolongée.
+ De même, si vous essayez d'utiliser un groupe d'instances pré-initialisées avec un cluster Amazon ECS, les instances peuvent s'enregistrer auprès du cluster avant la fin de leur initialisation. Pour résoudre ce problème, vous devez configurer un modèle de lancement ou une configuration de lancement qui inclut une variable de configuration d'agent spéciale dans les données utilisateur. Pour plus d'informations, consultez [Utilisation d'un groupe d'instances pré-initialisées pour votre groupe Auto Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/asg-capacity-providers.html#using-warm-pool) dans le *Guide du développeur Amazon Elastic Container Service*.
# Utilisez des hooks de cycle de vie avec un pool de chaleur dans le groupe Auto Scaling
Les instances du groupe d'instances pré-initialisées gèrent leur propre cycle de vie indépendant, ce qui vous permet de créer l'action personnalisée appropriée pour chaque transition. Ce cycle de vie est conçu pour vous aider à appeler des actions dans un service cible (par exemple, une fonction Lambda) pendant qu'une instance est encore en cours d'initialisation et avant qu'elle ne soit mise en service.
**Note**
Les opérations d'API que vous utilisez pour ajouter et gérer des hooks de cycle de vie et des actions de cycle de vie complètes ne sont pas modifiées. Seul le cycle de vie de l'instance est modifié.
Pour plus d'informations sur l'ajout d'un hook de cycle de vie, consultez [Ajoutez des hooks de cycle de vie à votre groupe Auto Scaling](adding-lifecycle-hooks.md). Pour plus d'informations sur l'exécution d'une action de cycle de vie, consultez [Réaliser une action du cycle de vie dans un groupe Auto Scaling](completing-lifecycle-hooks.md).
Pour les instances entrant dans le groupe d'instances pré-initialisées, vous aurez peut-être besoin d'un hook de cycle de vie pour l'une des raisons suivantes :
+ Vous souhaitez lancer des instances EC2 à partir d'une AMI dont l'initialisation est très longue.
+ Vous souhaitez exécuter des scripts de données utilisateur pour l'amorçage des instances EC2.
Pour les instances quittant le groupe d'instances pré-initialisées, vous aurez peut-être besoin d'un hook de cycle de vie pour l'une des raisons suivantes :
+ Vous pouvez utiliser un peu plus de temps pour préparer les instances EC2 à utiliser. Par exemple, certains de vos services pourraient devoir démarrer lorsqu'une instance redémarre pour que votre application puisse fonctionner correctement.
+ Vous souhaitez pré-remplir les données du cache pour vous assurer qu'un nouveau serveur n'est pas lancé avec un cache vide.
+ Vous souhaitez enregistrer de nouvelles instances en tant qu'instances gérées auprès de votre service de gestion de la configuration.
## Transitions de l'état du cycle de vie pour les instances dans un groupe d'instances pré-initialisées
Une instance Auto Scaling peut passer par plusieurs états dans le cadre de son cycle de vie.
Le schéma suivant montre la transition entre les états Auto Scaling lorsque vous utilisez un groupe d'instances pré-initialisées :
![\[Transitions de l'état du cycle de vie pour les instances dans un groupe d'instances pré-initialisées.\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/images/warm-pools-lifecycle-diagram.png)
¹ Cet état varie en fonction du paramètre d'état du groupe d'instances pré-initialisées. Si l'état du groupe est défini sur `Running`, alors cet état est à la place `Warmed:Running`. Si l'état du groupe est défini sur `Hibernated`, alors cet état est à la place `Warmed:Hibernated`.
Lorsque vous ajoutez des hooks de cycle de vie, tenez compte des éléments suivants :
+ Lorsqu'un hook de cycle de vie est configuré pour l'action `autoscaling:EC2_INSTANCE_LAUNCHING` du cycle de vie, une instance nouvellement lancée s'arrête d'abord pour effectuer une action personnalisée lorsqu'elle atteint l'état `Warmed:Pending:Wait`, puis de nouveau lorsque l'instance redémarre et atteint l'état `Pending:Wait`.
+ Lorsqu'un hook de cycle de vie est configuré pour l'action `EC2_INSTANCE_TERMINATING` du cycle de vie, une instance en cours de résiliation s'arrête pour effectuer une action personnalisée lorsqu'elle atteint l'état `Terminating:Wait`. Toutefois, si vous spécifiez une politique de réutilisation des instances pour renvoyer les instances dans le groupe d'instances pré-initialisées à grande échelle au lieu de les arrêter, une instance qui y revient s'arrête pour effectuer une action personnalisée à l'état `EC2_INSTANCE_TERMINATING` pour l'action de cycle de vie `Warmed:Pending:Wait`.
+ Si la demande de votre application vide le groupe d'instances pré-initialisées, Amazon EC2 Auto Scaling peut lancer des instances directement dans le groupe Auto Scaling tant que le groupe n'atteint pas encore sa capacité maximale. Si les instances se lancent directement dans le groupe, elles ne sont mises en attente pour effectuer une action personnalisée à l'état `Pending:Wait`.
+ Pour contrôler la durée pendant laquelle une instance reste en état d'attente avant de passer à l'état suivant, configurez votre action personnalisée de manière à utiliser la commande **complete-lifecycle-action**. Avec les hooks de cycle de vie, les instances restent en attente soit jusqu'à ce que vous signaliez à Amazon EC2 Auto Scaling que l'action du cycle de vie est terminée, soit jusqu'à ce que le délai d'attente (défini par défaut sur une heure) soit écoulé.
Ce qui suit résume le processus d'un événement de montée en puissance.
![\[Schéma de flux d'un événement de montée en puissance.\]](http://docs.aws.amazon.com/fr_fr/autoscaling/ec2/userguide/images/warm-pools-scale-out-event-diagram.png)
Lorsque les instances atteignent un état d'attente, Amazon EC2 Auto Scaling envoie une notification. Des exemples de ces notifications sont disponibles dans la EventBridge section de ce guide. Pour de plus amples informations, veuillez consulter [Exemples d’événements et de modèles de groupe chaud](warm-pools-eventbridge-events.md).
## Cibles de notification prises en charge
Amazon EC2 Auto Scaling prend en charge la définition de l'un des éléments suivants en tant que cibles de notification pour les notifications de cycle de vie :
+ EventBridge règles
+ Rubriques Amazon SNS
+ Files d'attente Amazon SQS
+ AWS Lambda fonctions
**Important**
Si votre modèle de lancement ou votre configuration de lancement contient un script de données utilisateur (cloud-init) qui configure vos instances lors de leur lancement, vous n'avez pas besoin de recevoir de notifications pour effectuer des actions personnalisées sur les instances qui démarrent ou redémarrent.
Les sections suivantes contiennent des liens vers la documentation décrivant comment configurer les cibles de notification :
**EventBridge règles** — Pour exécuter du code lorsqu'Amazon EC2 Auto Scaling met une instance en état d'attente, vous pouvez créer EventBridge une règle et spécifier une fonction Lambda comme cible. Pour appeler différentes fonctions Lambda en fonction de différentes notifications de cycle de vie, vous pouvez créer plusieurs règles et associer chaque règle à un modèle d'événement et à une fonction Lambda spécifiques. Pour de plus amples informations, veuillez consulter [Créez des EventBridge règles pour les événements en piscine chaude](warm-pool-events-eventbridge-rules.md).
**Rubriques Amazon SNS** : pour recevoir une notification lorsqu'une instance est mise en attente, vous créez une rubrique Amazon SNS, puis vous configurez le filtrage des messages Amazon SNS afin de diffuser les notifications relatives au cycle de vie différemment en fonction de l'attribut du message. Pour de plus amples informations, veuillez consulter [Recevoir des notifications à l'aide d'Amazon SNS](prepare-for-lifecycle-notifications.md#sns-notifications).
**Files d'attente Amazon SQS** : pour configurer un point de livraison pour les notifications relatives au cycle de vie où un consommateur concerné peut les récupérer et les traiter, vous pouvez créer une file d'attente Amazon SQS et un consommateur de file d'attente qui traite les messages provenant de la file d'attente SQS. Si vous souhaitez que le consommateur de file d'attente traite différemment les notifications de cycle de vie en fonction d'un attribut de message, vous devez également configurer le consommateur de file d'attente pour analyser le message, puis agir sur le message lorsqu'un attribut spécifique correspond à la valeur souhaitée. Pour de plus amples informations, veuillez consulter [Recevoir des notifications à l'aide d'Amazon SQS](prepare-for-lifecycle-notifications.md#sqs-notifications).
**AWS Lambda fonctions** — Pour exécuter du code personnalisé lorsqu'Amazon EC2 Auto Scaling met une instance en état d'attente, vous pouvez spécifier une fonction Lambda comme cible de notification. La fonction Lambda est invoquée avec les données de notification du cycle de vie, ce qui vous permet d'effectuer des actions personnalisées telles que la configuration de l'instance, la configuration de l'application ou l'intégration à d'autres AWS services. Vous devez configurer la politique basée sur les ressources de la fonction Lambda pour permettre au rôle lié au service Auto Scaling d'appeler la fonction. Pour de plus amples informations, veuillez consulter [Acheminer les notifications AWS Lambda directement vers](prepare-for-lifecycle-notifications.md#lambda-notification).
# Créez un groupe chaud pour un groupe Auto Scaling
Cette rubrique explique comment créer un groupe chaud pour votre groupe Auto Scaling.
**Important**
Avant de continuer, renseignez les [prérequis](ec2-auto-scaling-warm-pools.md#warm-pool-prerequisites) de création d’un groupe chaud et confirmez que vous avez créé un hook de cycle de vie pour votre groupe Auto Scaling.
## Créer un groupe d'instances pré-initialisées
Utilisez la procédure suivante pour créer un groupe chaud pour votre groupe Auto Scaling.
**Pour créer un groupe d'instances pré-initialisées (console)**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Activez la case à cocher en regard d'un groupe existant.
Un volet fractionné s'ouvre en bas de la page.
1. Cliquez sur l'onglet **Instance management** (Gestion des instances).
1. Sous **Warm pool** (Groupe d'instances pré-initialisées), sélectionnez **Create warm pool** (Créer un groupe d'instances pré-initialisées).
1. Pour configurer un groupe d'instances pré-initialisées, procédez comme suit :
1. Pour **Warm pool instance state** (État de l'instance du groupe d'instances pré-initialisées), choisissez l'état dans lequel vous souhaitez transférer vos instances lorsqu'elles intègrent le groupe. La valeur par défaut est `Stopped`.
1. Pour **Minimum warm pool size** (Taille minimale du groupe d'instances pré-initialisées), entrez le nombre minimal d'instances à conserver dans le groupe.
1. Pour la **réutilisation des instances**, cochez la case **Reuse on scale in** pour permettre aux instances du groupe Auto Scaling de retourner dans le pool de chaleur à l'échelle intégrée.
1. Pour la **taille de la piscine chaude**, choisissez l'une des options disponibles :
+ **Spécification par défaut** : La taille du pool de chaleur est déterminée par la différence entre la capacité maximale et la capacité souhaitée du groupe Auto Scaling. Cette option rationalise la gestion des piscines chaudes. Après avoir créé le bassin d'eau chaude, sa taille peut être facilement mise à jour en ajustant simplement la capacité maximale du groupe.
+ **Spécification personnalisée** : La taille du pool de chaleur est déterminée par la différence entre une valeur personnalisée et la capacité souhaitée du groupe Auto Scaling. Cette option vous permet de gérer la taille de votre piscine chaude indépendamment de la capacité maximale du groupe.
1. Consultez la section **Taille estimée de la piscine chaude en fonction des paramètres actuels** pour confirmer comment les spécifications par défaut ou personnalisées s'appliquent à la taille de la piscine chaude. N'oubliez pas que la taille du pool de chaleur dépend de la capacité souhaitée du groupe Auto Scaling, qui changera si le groupe évolue.
1. Choisissez **Créer**.
## Sélection du type d'instance avec des groupes d'instances mixtes
Auto Scaling donne la priorité aux types d'instances qui se trouvent déjà dans le warm pool lors des événements de dimensionnement lorsque votre groupe est configuré avec une politique d'instances mixtes. Comportement de lancement :
1. Auto Scaling tente de lancer des instances en utilisant les types d'instances disponibles dans le warm pool.
1. Si le lancement à chaud échoue, Auto Scaling tente un lancement à froid en utilisant tous les types d'instances restants dans votre politique d'instances mixtes.
**Example**
**Exemple**
Si vous configurez votre groupe Auto Scaling avec 10 types d'instances et que votre warm pool contient 6 de ces types d'instances. Pendant le scale-out, Auto Scaling essaie d'abord les 6 types d'instances du warm pool. En cas d'échec, Auto Scaling essaie tous les types d'instances configurés par le biais d'un lancement à froid.
Cela vous permet d'obtenir des avantages en termes de performances de pool chaud lorsque cela est possible tout en préservant la flexibilité de votre configuration complète d'instances mixtes.
## Supprimer un groupe d'instances pré-initialisées
Quand vous n'avez plus besoin du groupe d'instances pré-initialisées, utilisez la procédure suivante pour le supprimer.
**Pour supprimer votre groupe d'instances pré-initialisées (console)**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Activez la case à cocher en regard d'un groupe existant.
Un volet fractionné s'ouvre en bas de la page.
1. Cliquez sur l'onglet **Instance management** (Gestion des instances).
1. Pour **Warm pool** (Groupe d'instances pré-initialisées), choisissez **Actions**, **Delete** (Supprimer).
1. Lorsque vous êtes invité à confirmer l’opération, choisissez **Supprimer**.
# Afficher le statut de surveillance de l'état et les motifs des échecs de surveillances de l'état
La surveillance de l'état permet à Amazon EC2 Auto Scaling de déterminer si une instance est malsaine et doit être interrompue. Pour les instances de groupe d'instances pré-initialisées maintenues dans l'état `Stopped`, il utilise la connaissance qu'Amazon EBS a de la disponibilité d'une instance `Stopped` pour identifier les instances malsaines. Il le fait en appelant l'API `DescribeVolumeStatus` pour déterminer l'état du volume EBS qui est attaché à l'instance. Pour les instances de groupe d'instances pré-initialisées maintenues dans l'état `Running`, il s'appuie sur les vérifications d'état EC2 pour déterminer l'état de l'instance. Bien qu'il n'y ait pas de période de grâce de surveillance de l'état pour les instances de groupe d'instances pré-initialisées, Amazon EC2 Auto Scaling ne commence pas à surveiller l'état de l'instance tant que le hook de cycle de vie n'est pas terminé.
Lorsqu'une instance est jugée malsaine, Amazon EC2 Auto Scaling la supprime automatiquement et en crée une nouvelle pour la remplacer. Généralement, les instances sont interrompues quelques minutes après l'échec de la surveillance de leur état. Pour de plus amples informations, veuillez consulter [Afficher le motif des échecs d’une surveillance de l’état](replace-unhealthy-instance.md).
La surveillance personnalisée de l'état est également prise en charge. Cela peut être utile si vous disposez de votre propre système de surveillance de l'état qui peut détecter l'état d'une instance et envoyer ces informations à Amazon EC2 Auto Scaling. Pour de plus amples informations, veuillez consulter [Configurez un bilan de santé personnalisé pour votre groupe Auto Scaling](set-up-a-custom-health-check.md).
Dans la console Amazon EC2 Auto Scaling, vous pouvez afficher le statut (sain ou non sain) de vos instances de groupe d'instances pré-initialisées. Vous pouvez également consulter leur état de santé à l'aide du AWS CLI ou de l'un des SDKs.
**Pour afficher le statut de vos instances du groupe d'instances pré-initialisées (console)**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Cochez la case située en regard du groupe Auto Scaling.
Un volet fractionné s'ouvre en bas de la page **Auto Scaling groups** (Groupes Auto Scaling).
1. Sous l'onglet **Instance management** (Gestion des instances) dans **Warm groupe instances** (Instances de groupe d'instances pré-initialisées), la colonne **Lifecycle** (Cycle de vie) affiche l'état de vos instances.
La colonne **Health status (État d'intégrité)** indique l'évaluation d'Amazon EC2 Auto Scaling portant sur l'état de l'instance.
**Note**
Les nouvelles instances commencent dans un état sain. Tant que le hook de cycle de vie n'est pas terminé, l'état d'une instance n'est pas surveillé.
**Pour afficher le motif des échecs d'une surveillance de l'état (console)**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Cochez la case située en regard du groupe Auto Scaling.
Un volet fractionné s'ouvre en bas de la page **Auto Scaling groups** (Groupes Auto Scaling).
1. Sous l'onglet **Activity** (Activité) sous **Activity history** (Historique des activités), la colonne **Status** (État) indique si votre groupe Auto Scaling a réussi à lancer ou à résilier des instances.
Si des instances malsaines sont interrompues, la colonne **Cause** indique la date et l'heure de l'interruption et le motif de l'échec de la surveillance de l'état. Par exemple, « Sur 2021-04-01T 21:48:35 Z, une instance a été mise hors service en réponse à l'échec de la surveillance de l'état du volume EBS ».
**Pour afficher le statut de vos instances du groupe d'instances pré-initialisées (AWS CLI)**
Affichez le pool de chaleur d'un groupe Auto Scaling à l'aide de la [describe-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-warm-pool.html)commande suivante.
```
aws autoscaling describe-warm-pool --auto-scaling-group-name my-asg
```
Exemple de sortie.
```
{
"WarmPoolConfiguration": {
"MinSize": 0,
"PoolState": "Stopped"
},
"Instances": [
{
"InstanceId": "i-0b5e5e7521cfaa46c",
"InstanceType": "t2.micro",
"AvailabilityZone": "us-west-2a",
"LifecycleState": "Warmed:Stopped",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-08c4cd42f320d5dcd",
"LaunchTemplateName": "my-template-for-auto-scaling",
"Version": "1"
}
},
{
"InstanceId": "i-0e21af9dcfb7aa6bf",
"InstanceType": "t2.micro",
"AvailabilityZone": "us-west-2a",
"LifecycleState": "Warmed:Stopped",
"HealthStatus": "Healthy",
"LaunchTemplate": {
"LaunchTemplateId": "lt-08c4cd42f320d5dcd",
"LaunchTemplateName": "my-template-for-auto-scaling",
"Version": "1"
}
}
]
}
```
**Pour afficher le motif des échecs d'une surveillance de l'état (AWS CLI)**
Utilisez la commande [describe-scaling-activities](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-scaling-activities.html) suivante.
```
aws autoscaling describe-scaling-activities --auto-scaling-group-name my-asg
```
Voici un exemple de réponse, où `Description` indique que votre groupe Auto Scaling a mis fin à une instance et `Cause` indique le motif de l'échec de la surveillance de l'état.
Les activités de mise à l'échelle sont classées par heure de début. Les activités toujours en cours sont décrites en premier lieu.
```
{
"Activities": [
{
"ActivityId": "4c65e23d-a35a-4e7d-b6e4-2eaa8753dc12",
"AutoScalingGroupName": "my-asg",
"Description": "Terminating EC2 instance: i-04925c838b6438f14",
"Cause": "At 2021-04-01T21:48:35Z an instance was taken out of service in response to EBS volume health check failure.",
"StartTime": "2021-04-01T21:48:35.859Z",
"EndTime": "2021-04-01T21:49:18Z",
"StatusCode": "Successful",
"Progress": 100,
"Details": "{\"Subnet ID\":\"subnet-5ea0c127\",\"Availability Zone\":\"us-west-2a\"...}",
"AutoScalingGroupARN": "arn:aws:autoscaling:us-west-2:123456789012:autoScalingGroup:283179a2-f3ce-423d-93f6-66bb518232f7:autoScalingGroupName/my-asg"
},
...
]
}
```
# Exemples de création et de gestion de piscines chaudes à l'aide du AWS CLI
Vous pouvez créer et gérer des piscines chaudes à l'aide du AWS Management Console, AWS Command Line Interface (AWS CLI) ou SDKs.
Les exemples suivants vous montrent comment créer et gérer des groupes d'instances pré-initialisées à l'aide de la AWS CLI.
**Topics**
+ [Exemple 1 : conserver des instances dans l'état `Stopped`](#warm-pool-configuration-ex1)
+ [Exemple 2 : conserver des instances dans l'état `Running`](#warm-pool-configuration-ex2)
+ [Exemple 3 : conserver des instances dans l'état `Hibernated`](#warm-pool-configuration-ex3)
+ [Exemple 4 : renvoyer des instances au groupe d'instances pré-initialisées lors de la mise à l'échelle horizontale](#warm-pool-configuration-ex4)
+ [Exemple 5 : spécifier le nombre minimal d'instances dans le groupe d'instances pré-initialisées](#warm-pool-configuration-ex5)
+ [Exemple 6 : définir la taille de la piscine chaude à l'aide d'une spécification personnalisée](#warm-pool-configuration-ex6)
+ [Exemple 7 : définir une taille absolue de groupe d'instances pré-initialisées](#warm-pool-configuration-ex7)
+ [Exemple 8 : supprimer un groupe d'instances pré-initialisées](#delete-warm-pool-cli)
## Exemple 1 : conserver des instances dans l'état `Stopped`
L'[put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemple suivant crée un pool de chaleur qui maintient les instances dans un `Stopped` état.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped
```
## Exemple 2 : conserver des instances dans l'état `Running`
L'[put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemple suivant crée un pool de chaleur qui maintient les instances dans un `Running` état plutôt que dans un `Stopped` état.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Running
```
## Exemple 3 : conserver des instances dans l'état `Hibernated`
L'[put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemple suivant crée un pool de chaleur qui maintient les instances dans un `Hibernated` état plutôt que dans un `Stopped` état. Cela vous permet d'arrêter les instances sans supprimer leur contenu en mémoire (RAM).
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Hibernated
```
## Exemple 4 : renvoyer des instances au groupe d'instances pré-initialisées lors de la mise à l'échelle horizontale
L'[put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemple suivant crée un pool de chaleur qui maintient les instances dans un `Stopped` état et inclut l'`--instance-reuse-policy`option. La valeur `'{"ReuseOnScaleIn": true}'` de la politique de réutilisation d'instance indique à Amazon EC2 Auto Scaling de renvoyer les instances vers le groupe d'instances pré-initialisées lors de la mise à l'échelle horizontale de votre groupe Auto Scaling.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --instance-reuse-policy '{"ReuseOnScaleIn": true}'
```
## Exemple 5 : spécifier le nombre minimal d'instances dans le groupe d'instances pré-initialisées
L'[put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemple suivant crée un pool de chaleur qui gère un minimum de 4 instances, de sorte qu'au moins 4 instances soient disponibles pour gérer les pics de trafic.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 4
```
## Exemple 6 : définir la taille de la piscine chaude à l'aide d'une spécification personnalisée
Par défaut, Amazon EC2 Auto Scaling gère la taille de votre pool de chaleur comme la différence entre la capacité maximale et la capacité souhaitée du groupe Auto Scaling. Cependant, vous pouvez gérer la taille de la piscine chaude indépendamment de la capacité maximale du groupe en utilisant `--max-group-prepared-capacity` cette option.
L'[put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemple suivant crée un pool de chaleur et définit le nombre maximum d'instances pouvant exister simultanément dans le pool de chauffage et dans le groupe Auto Scaling. Si le groupe a une capacité souhaitée de 800 personnes, le pool de chaleur aura initialement une taille de 100 lorsqu'il s'initialisera après avoir exécuté cette commande.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --max-group-prepared-capacity 900
```
Pour conserver un nombre minimal d'instances dans le groupe, ajoutez l'option `--min-size` à la commande, comme suit.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --max-group-prepared-capacity 900 --min-size 25
```
## Exemple 7 : définir une taille absolue de groupe d'instances pré-initialisées
Si vous définissez les mêmes valeurs pour les options `--max-group-prepared-capacity` et `--min-size`, le groupe d'instances pré-initialisées a une taille absolue. L'[put-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/put-warm-pool.html)exemple suivant crée un pool de chaleur qui maintient une taille de pool de chaleur constante de 10 instances.
```
aws autoscaling put-warm-pool --auto-scaling-group-name my-asg /
--pool-state Stopped --min-size 10 --max-group-prepared-capacity 10
```
## Exemple 8 : supprimer un groupe d'instances pré-initialisées
Utilisez la [delete-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-warm-pool.html)commande suivante pour supprimer un pool de chaleur.
```
aws autoscaling delete-warm-pool --auto-scaling-group-name my-asg
```
S'il existe des instances dans le pool de chaleur, ou si des activités de dimensionnement sont en cours, utilisez la [delete-warm-pool](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-warm-pool.html)commande avec l'`--force-delete`option. Cette option résilie également les instances Amazon EC2 et toutes les actions de cycle de vie en attente.
```
aws autoscaling delete-warm-pool --auto-scaling-group-name my-asg --force-delete
```
# Changement de zone du groupe Auto Scaling
Le changement de zone est une fonctionnalité de l'Amazon Application Recovery Controller (ARC). Grâce au changement de zone, vous pouvez rapidement remédier aux défaillances d'une application dans une zone de disponibilité en une seule action. Lorsque vous activez le décalage de zone pour un groupe Auto Scaling, le groupe est enregistré auprès du service de décalage de zone ARC. Vous pouvez ensuite démarrer un changement de zone à l'aide de l'API AWS Management Console, ou AWS CLI, et le groupe Auto Scaling considère que la zone de disponibilité présentant un décalage de zone actif est altérée.
## Concepts de changement de zone du groupe Auto Scaling
Avant de poursuivre, assurez-vous de connaître les concepts de base suivants relatifs à l'intégration avec le décalage de zone ARC.
**Déplacement de zone ARC**
Auto Scaling peut enregistrer des groupes Auto Scaling avec ARC zonal shift lorsque vous activez cette fonctionnalité. Après l'enregistrement, vous pouvez consulter vos ressources avec l'`ListManagedResources`API [ARC](https://docs.aws.amazon.com/arc-zonal-shift/latest/api/API_ListManagedResources.html). Pour plus d'informations, consultez le [changement de zone dans ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html) dans le *manuel du développeur Amazon Application Recovery Controller (ARC)*.
**Rééquilibrage des zones de disponibilité**
Auto Scaling essaie de maintenir l'équilibre des capacités dans chaque zone de disponibilité. Lorsqu'un déséquilibre se produit entre les zones de disponibilité, Auto Scaling tente automatiquement de le corriger. Pour de plus amples informations, veuillez consulter [Distribution des instances](auto-scaling-benefits.md#AutoScalingBehavior.Rebalancing).
**Mise à l'échelle dynamique**
Le dimensionnement dynamique permet d'ajuster la capacité souhaitée de votre groupe Auto Scaling en fonction des métriques que vous choisissez avec des politiques de dimensionnement. Pour de plus amples informations, veuillez consulter [Mise à l'échelle dynamique pour Amazon EC2 Auto Scaling](as-scale-based-on-demand.md).
**Surveillance de l'état**
Auto Scaling vérifie régulièrement l'état de santé de toutes les instances d'un groupe Auto Scaling pour s'assurer qu'elles fonctionnent et qu'elles sont en bon état. Lorsqu'une instance défectueuse est détectée, Auto Scaling la marque pour remplacement. Pour de plus amples informations, veuillez consulter [Surveillance de l’état des instances dans un groupe Auto Scaling](ec2-auto-scaling-health-checks.md).
**Actualisation d'instance**
Vous pouvez utiliser une actualisation d'instance pour mettre à jour les instances de votre groupe Auto Scaling. Après le lancement de l'actualisation d'une instance, Auto Scaling tente de remplacer toutes les instances de votre groupe Auto Scaling. Pour de plus amples informations, veuillez consulter [Utiliser une actualisation d'instance pour mettre à jour les instances d'un groupe Auto Scaling](asg-instance-refresh.md).
**Prédimensionné**
Vous pouvez tolérer la perte d'une seule zone de disponibilité car vous disposez d'une capacité suffisante pour votre application dans les zones de disponibilité restantes.
**Augmentation d'échelle**
Lorsque vous augmentez la capacité souhaitée d'un groupe Auto Scaling, Auto Scaling tente de lancer des instances supplémentaires pour atteindre la nouvelle capacité souhaitée. Par défaut, Auto Scaling lance l'instance de manière équilibrée afin de maintenir une capacité égale dans chaque zone de disponibilité activée d'un groupe Auto Scaling.
## Comment fonctionne le décalage de zone pour les groupes Auto Scaling
Supposons que vous disposiez d'un groupe Auto Scaling avec les zones de disponibilité suivantes :
+ `us-east-1a`
+ `us-east-1b`
+ `us-east-1c`
Vous avez activé le changement de zone dans toutes les zones de disponibilité et vous remarquez des défaillances. Vous déclenchez `us-east-1a` donc un changement de zone. Les comportements suivants se produisent lorsqu'un changement de zone est déclenché dans`us-east-1a`.
+ **Scaling out** — Auto Scaling lancera toutes les nouvelles demandes de capacité dans les zones de disponibilité saines (`us-east-1b`et`us-east-1c`).
+ **Dimensionnement dynamique** : Auto Scaling empêchera les politiques de dimensionnement de réduire la capacité souhaitée dans toutes les zones de disponibilité. Auto Scaling n'empêchera pas les politiques de dimensionnement d'augmenter la capacité souhaitée dans toutes les zones de disponibilité.
+ **Actualisations d'instances** — Auto Scaling prolongera le délai d'expiration de tout processus d'actualisation d'instance retardé alors qu'un changement de zone est actif.
Le tableau suivant décrit le comportement du contrôle de santé pour chaque option lorsqu'un changement de zone est déclenché. `us-east-1a`
| Sélection du comportement de vérification de l'état de la zone de disponibilité altérée | Comportement du bilan de santé |
| --- | --- |
| Remplacez les produits mal | Les instances qui semblent défectueuses seront remplacées dans toutes les zones de disponibilité (`us-east-1a``us-east-1b`,, et`us-east-1c`). |
| Ignorez les mauvaises | Les instances qui semblent défectueuses seront remplacées dans `us-east-1b` et`us-east-1c`. Les instances ne seront pas remplacées dans la zone de disponibilité par le décalage zonal actif (`us-east-1a`). |
## Bonnes pratiques pour utiliser le décalage de zone
Pour maintenir la haute disponibilité de vos applications lorsque vous utilisez Zonal Shift, nous vous recommandons de suivre les meilleures pratiques suivantes :
+ Surveillez EventBridge les notifications pour déterminer s'il existe un événement d'altération continu de la zone de disponibilité. Pour de plus amples informations, veuillez consulter [EventBridge À utiliser pour gérer les événements Auto Scaling](automating-ec2-auto-scaling-with-eventbridge.md).
+ Utilisez des politiques de dimensionnement avec des seuils appropriés pour vous assurer que vous disposez d'une capacité suffisante pour tolérer la perte d'une zone de disponibilité.
+ Définissez une politique de maintenance des instances avec un pourcentage sain minimum de 100. Avec ce paramètre, Auto Scaling attend qu'une nouvelle instance soit prête à être utilisée avant de mettre fin à une instance défectueuse.
Pour les clients prédimensionnés, nous recommandons également ce qui suit :
+ Sélectionnez **Ignorer** l'instance défectueuse comme comportement de vérification de l'état de la zone de disponibilité altérée, car vous n'avez pas besoin de remplacer l'instance défectueuse lors de l'événement de défaillance.
+ Utilisez l'autoshift zonal dans ARC pour vos groupes Auto Scaling. La fonctionnalité de transfert automatique zonal d'ARC permet de AWS déplacer le trafic d'une ressource hors d'une zone de disponibilité lorsqu'une déficience est AWS détectée dans une zone de disponibilité. Pour plus d'informations, consultez la section [Zonal Autoshift in ARC dans](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html) le manuel du *développeur Amazon Application Recovery Controller (ARC)*.
Pour les clients utilisant des équilibreurs de charge désactivés entre zones, nous recommandons également ce qui suit :
+ Utilisez le **mode équilibré uniquement** pour la distribution de votre zone de disponibilité.
+ Si vous utilisez le décalage de zone à la fois sur les groupes Auto Scaling et sur les équilibreurs de charge, annulez d'abord le décalage de zone sur votre groupe Auto Scaling. Attendez ensuite que la capacité soit équilibrée dans toutes les zones de disponibilité avant d'annuler le changement de zone sur l'équilibreur de charge.
+ En raison de la possibilité d'un déséquilibre de capacité lorsque vous activez le décalage de zone et que vous utilisez un équilibreur de charge désactivé entre zones, Auto Scaling inclut une étape de validation supplémentaire. Si vous suivez les meilleures pratiques, vous pouvez reconnaître cette possibilité en cochant la AWS Management Console case ou en utilisant le `skip-zonal-shift-validation` drapeau dans `CreateAutoScalingGroup``UpdateAutoScalingGroup`, ou`AttachTrafficSources`.
Pour plus d'informations sur l'utilisation du décalage de zone avec les groupes Auto Scaling, consultez le blog de AWS Compute sur [l'utilisation du décalage de zone avec Amazon EC2 Auto Scaling](https://aws.amazon.com/blogs/compute/using-zonal-shift-with-amazon-ec2-auto-scaling/).
# Activez le décalage de zone à l'aide du AWS Management Console ou du AWS CLI
Pour activer le décalage zonal, appliquez l'une des méthodes suivantes.
------
#### [ Console ]
**Pour activer le changement de zone sur un nouveau groupe (console)**
1. Suivez les instructions [Créer un groupe Auto Scaling avec un modèle de lancement](create-asg-launch-template.md) et complétez chaque étape de la procédure, jusqu'à l'étape 10.
1. Sur la page **Intégrer à d'autres services**, pour le décalage de **zone d'Application Recovery Controller (ARC), cochez la case pour activer le décalage** de zone.
1. Pour le **comportement du bilan de santé**, choisissez Ignorer un comportement malsain ou Remplacer un comportement malsain. Pour de plus amples informations, veuillez consulter [Comment fonctionne le décalage de zone pour les groupes Auto Scaling](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works).
1. Poursuivez en effectuant les étapes de la section [Créer un groupe Auto Scaling avec un modèle de lancement](create-asg-launch-template.md).
------
#### [ AWS CLI ]
**Pour activer le décalage de zone sur un nouveau groupe ()AWS CLI**
Ajoutez le paramètre `--availability-zone-impairment-policy` à la commande [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html).
Le `--availability-zone-impairment-policy` paramètre comporte deux options :
+ **ZonalShiftEnabled**— Si ce paramètre est défini sur`true`, Auto Scaling enregistre le groupe Auto Scaling avec le décalage de zone ARC et vous pouvez [démarrer, mettre à jour ou annuler un décalage de zone](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) sur la console ARC. S'il est défini sur`false`, Auto Scaling annule l'enregistrement du groupe Auto Scaling du décalage de zone ARC. Le décalage de zone doit déjà être activé pour être réglé sur. `false`
+ **ImpairedZoneHealthCheckBehavior**— Si ce paramètre est défini sur`replace-unhealthy`, les instances défectueuses seront remplacées dans la zone de disponibilité par le décalage de zone actif. Si ce paramètre est défini sur`ignore-unhealthy`, les instances défectueuses ne seront pas remplacées dans la zone de disponibilité par le décalage de zone actif. Pour de plus amples informations, veuillez consulter [Comment fonctionne le décalage de zone pour les groupes Auto Scaling](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works).
L'exemple suivant active le décalage de zone sur un nouveau groupe Auto Scaling nommé`my-asg`.
```
aws autoscaling create-auto-scaling-group \
--launch-template LaunchTemplateName=my-launch-template,Version='1' \
--auto-scaling-group-name my-asg \
--min-size 1 \
--max-size 10 \
--desired-capacity 5 \
--availability-zones us-east-1a us-east-1b us-east-1c \
--availability-zone-impairment-policy '{
"ZonalShiftEnabled": true,
"ImpairedZoneHealthCheckBehavior": IgnoreUnhealthy
}'
```
------
------
#### [ Console ]
**Pour activer le changement de zone sur un groupe existant (console)**
1. Ouvrez la EC2 console Amazon à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)et choisissez **Auto Scaling Groups** dans le volet de navigation.
1. Dans la barre de navigation située en haut de l'écran, choisissez l' Région AWS dans laquelle vous avez créé votre groupe Auto Scaling.
1. Cochez la case située en regard du groupe Auto Scaling.
Un volet fractionné s’ouvre en bas de la page.
1. **Dans l'onglet **Intégrations**, sous Changement de **zone d'Application Recovery Controller (ARC)**, choisissez Modifier.**
1. Cochez la case pour activer le décalage de zone.
1. Pour le **comportement du bilan de santé**, choisissez Ignorer un comportement malsain ou Remplacer un comportement malsain. Pour de plus amples informations, veuillez consulter [Comment fonctionne le décalage de zone pour les groupes Auto Scaling](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works).
1. Choisissez **Mettre à jour**.
------
#### [ AWS CLI ]
**Pour activer le décalage de zone sur un groupe existant ()AWS CLI**
Ajoutez le paramètre `--availability-zone-impairment-policy` à la commande [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html).
Le `--availability-zone-impairment-policy` paramètre comporte deux options :
+ **ZonalShiftEnabled**— Si ce paramètre est défini sur`true`, Auto Scaling enregistre le groupe Auto Scaling avec le décalage de zone ARC et vous pouvez [démarrer, mettre à jour ou annuler un décalage de zone](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) sur la console ARC. S'il est défini sur`false`, Auto Scaling annule l'enregistrement du groupe Auto Scaling du décalage de zone ARC. Le décalage de zone doit déjà être activé pour être réglé sur. `false`
+ **ImpairedZoneHealthCheckBehavior**— Si ce paramètre est défini sur`replace-unhealthy`, les instances défectueuses seront remplacées dans la zone de disponibilité par le décalage de zone actif. Si ce paramètre est défini sur`ignore-unhealthy`, les instances défectueuses ne seront pas remplacées dans la zone de disponibilité par le décalage de zone actif. Pour de plus amples informations, veuillez consulter [Comment fonctionne le décalage de zone pour les groupes Auto Scaling](ec2-auto-scaling-zonal-shift.md#asg-zonal-shift-how-it-works).
L'exemple suivant active le décalage de zone sur le groupe Auto Scaling spécifié.
```
aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg \
--availability-zone-impairment-policy '{
"ZonalShiftEnabled": true,
"ImpairedZoneHealthCheckBehavior": IgnoreUnhealthy
}'
```
------
# Distribution des zones de disponibilité d’un groupe Auto Scaling
Les informations suivantes décrivent les stratégies de zone de disponibilité du groupe Auto Scaling.
**Meilleur effort équilibré**
Auto Scaling gère un nombre égal d'instances dans les zones de disponibilité activées. Si les tentatives de lancement échouent dans une zone de disponibilité, Auto Scaling tente de lancer des instances dans une autre zone de disponibilité saine. Cette stratégie est importante pour les applications qui nécessitent une redondance de zone de disponibilité et qui ne sont pas affectées par des groupes déséquilibrés.
**Équilibré uniquement**
Auto Scaling gère un nombre égal d'instances dans les zones de disponibilité activées. Si les tentatives de lancement échouent dans une zone de disponibilité, Auto Scaling continuera de tenter de lancer des instances dans la zone de disponibilité. Cette stratégie est importante pour répondre à certaines exigences, telles que les charges de travail basées sur le quorum ou si votre groupe Auto Scaling peut tolérer la perte d'une zone de disponibilité parce que vous disposez d'une capacité suffisante dans les zones de disponibilité restantes.
La sélection de la stratégie de distribution de la zone de disponibilité se trouve dans la section **Réseau** des commandes AWS Management Console ou vous pouvez utiliser les [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html)commandes [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)ou.
Pour de plus amples informations, veuillez consulter [Créer des groupes Auto Scaling à l’aide de modèles de lancement](create-auto-scaling-groups-launch-template.md).
# Détachez ou attachez des instances de votre groupe Auto Scaling
Vous pouvez détacher des instances de votre groupe Auto Scaling. Une fois qu'une instance est détachée, elle devient indépendante et peut être gérée seule ou attachée à un autre groupe Auto Scaling, distinct du groupe d'origine auquel elle appartenait. Cela peut être utile, par exemple, lorsque vous souhaitez effectuer des tests à l'aide d'instances existantes qui exécutent déjà votre application.
Cette rubrique fournit des instructions sur la manière de détacher et d'attacher des instances. Lorsque vous attachez des instances, vous pouvez également utiliser une instance existante plutôt qu'une instance détachée.
Au lieu de détacher et de rattacher une instance au même groupe, nous vous recommandons d'utiliser la procédure de mise en veille pour supprimer temporairement l'instance du groupe. Pour de plus amples informations, veuillez consulter [Supprimer temporairement des instances du groupe Auto Scaling](as-enter-exit-standby.md).
**Topics**
+ [Considérations relatives au détachement des instances](#detach-instances-considerations)
+ [Considérations relatives à l'attachement d'instances](#attach-instances-considerations)
+ [Déplacer une instance vers un autre groupe à l'aide de la fonction détacher et attacher](#detach-attach-instances)
## Considérations relatives au détachement des instances
Lorsque vous détachez des instances, gardez les points suivants à l'esprit :
+ Vous ne pouvez détacher une instance que lorsqu'elle est dans un `StandBy` état `InService` ou. Si vous détachez des instances qui se trouvent dans l'état `StandBy`, faites preuve de prudence. L'inclusion de l'`ShouldDecrementDesiredCapacity`indicateur dans l'appel d'API lorsque vous tentez de détacher des instances après les avoir mises dans l'`StandBy`état peut entraîner la fermeture inattendue d'autres instances.
+ Une fois que vous avez détaché une instance, elle continue de fonctionner et d'être facturée. Pour éviter des frais inutiles, veillez à rattacher ou à résilier les instances détachées lorsqu'elles ne sont plus nécessaires.
+ Vous pouvez choisir de réduire la capacité souhaitée en fonction du nombre d'instances que vous souhaitez détacher. Si vous choisissez de ne pas réduire la capacité, Amazon EC2 Auto Scaling lance de nouvelles instances pour remplacer les instances détachées afin de maintenir la capacité souhaitée.
+ Si le nombre d'instances que vous détachez amène le groupe Auto Scaling en dessous de sa capacité minimale, vous devez réduire la capacité minimale.
+ Si vous détachez plusieurs instances de la même zone de disponibilité sans réduire la capacité souhaitée, le groupe se rééquilibrera à moins que vous ne suspendiez le processus. `AZRebalance` Pour de plus amples informations, veuillez consulter [Suspendre et reprendre les processus Amazon EC2 Auto Scaling](as-suspend-resume-processes.md).
+ Si vous détachez une instance d'un groupe Auto Scaling qui possède un groupe cible d'équilibreur de charge attaché ou un Classic Load Balancer, l'instance est désenregistrée de l'équilibreur de charge. Si le drainage de la connexion (délai de désinscription) est activé pour l'équilibreur de charge, Amazon EC2 Auto Scaling attend la fin des demandes à la volée.
## Considérations relatives à l'attachement d'instances
Notez les points suivants lorsque vous attachez des instances :
+ Amazon EC2 Auto Scaling traite les instances attachées de la même manière que les instances lancées par le groupe lui-même. Cela signifie que les instances attachées peuvent être résiliées lors d'événements d'extension si elles sont sélectionnées. Les autorisations accordées par le rôle AWSServiceRoleForAutoScaling lié au service permettent à Amazon EC2 Auto Scaling de le faire.
+ Lorsque vous attachez des instances, la capacité souhaitée du groupe augmente en fonction du nombre d'instance attachées. Si la capacité souhaitée après l'ajout des nouvelles instances dépasse la taille maximale du groupe, la demande d'attachement d'autres instances échoue.
+ Si vous ajoutez des instances à votre groupe, ce qui entraîne une répartition inégale entre les zones de disponibilité, Amazon EC2 Auto Scaling rééquilibre le groupe pour rétablir une distribution uniforme, sauf si vous suspendez le processus. `AZRebalance` Pour de plus amples informations, veuillez consulter [Suspendre et reprendre les processus Amazon EC2 Auto Scaling](as-suspend-resume-processes.md).
+ Si vous attachez une instance à un groupe Auto Scaling qui possède un groupe cible d'équilibreur de charge attaché ou un Classic Load Balancer, l'instance est enregistrée avec l'équilibreur de charge.
Pour pouvoir attacher une instance, celle-ci doit répondre aux critères suivants :
+ L'instance est dans l'état `running` avec Amazon EC2.
+ L'AMI utilisée pour lancer l'instance doit toujours exister.
+ L'instance ne fait pas partie d'un autre groupe Auto Scaling.
+ L'instance est lancée dans l'une des zones de disponibilité définies dans le groupe Auto Scaling.
+ Si le groupe Auto Scaling possède un groupe cible de l'équilibreur de charge attaché ou Classic Load Balancer, l'instance et l'équilibreur de charge doivent tous les deux se trouver dans le même VPC.
## Déplacer une instance vers un autre groupe à l'aide de la fonction détacher et attacher
Utilisez l'une des procédures suivantes pour détacher une instance de votre groupe Auto Scaling et l'associer à un autre groupe Auto Scaling.
Pour créer un nouveau groupe Auto Scaling à partir d'une instance détachée, voir [Créez un groupe Auto Scaling à partir d'une instance existante à l'aide du AWS CLI](create-asg-from-instance.md) (non recommandé, crée une configuration de lancement).
------
#### [ Console ]
**Pour détacher une instance d’un groupe Auto Scaling**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Cochez la case située en regard de votre groupe Auto Scaling.
Un volet fractionné s’ouvre en bas de la page.
1. Sous l'onglet **Instance management** (Gestion des instances) dans **Instances**, sélectionnez une instance et choisissez **Actions**, **Detach** (Détacher).
1. Dans la boîte de dialogue **Détacher l’instance**, gardez la case à cocher **Remplacer l’instance** sélectionnée pour lancer une instance de remplacement. Désactivez la case à cocher pour réduire la capacité souhaitée.
1. Lorsque vous êtes invité à confirmer l’opération, saisissez **detach** pour confirmer la suppression de l’instance spécifiée du groupe Auto Scaling, puis choisissez **Détacher l’instance**.
Vous pouvez désormais associer l'instance à un autre groupe Auto Scaling.
**Pour attacher une instance à un groupe Auto Scaling**
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. (Facultatif) Dans le panneau de navigation, sous **Auto Scaling**, choisissez **Auto Scaling Groups (Groupes Auto Scaling)**. Sélectionnez le groupe Auto Scaling et vérifiez que sa taille maximale est suffisamment grande pour pouvoir ajouter une autre instance. Sinon, dans l'onglet **Details** (Détails), augmentez la capacité maximale.
1. Dans le panneau de navigation, sous **Instances**, choisissez **Instances**, puis sélectionnez une instance.
1. Choisissez **Actions**, **Instance Settings (Paramètres de l'instance)**, puis **Attach to Auto Scaling Group (Attacher à un groupe Auto Scaling)**.
1. Sur la page **Attach to Auto Scaling group (Attacher à un groupe Auto Scaling)**, sous **Auto Scaling Group (Groupe Auto Scaling)** sélectionnez le groupe Auto Scaling, puis choisissez **Attach (Attacher)**.
1. Si l'instance ne répond pas aux critères, un message d'erreur détaillé s'affiche. Par exemple, l'instance peut se trouver dans une zone de disponibilité différente de celle du groupe Auto Scaling. Choisissez **Fermer** et réessayez avec un groupe Auto Scaling répondant aux critères.
------
#### [ AWS CLI ]
Pour détacher et attacher une instance, utilisez les exemples de commandes suivants. Remplacez chaque *user input placeholder* par vos propres informations.
**Pour détacher une instance d’un groupe Auto Scaling**
1. Pour décrire les instances actuelles, utilisez la [describe-auto-scaling-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-instances.html)commande suivante.
```
aws autoscaling describe-auto-scaling-instances \
--query 'AutoScalingInstances[?AutoScalingGroupName==`my-asg`]'
```
L’exemple suivant illustre la sortie produite lorsque vous exécutez cette commande.
Prenez note de l'ID de l'instance que vous souhaitez supprimer du groupe. Vous aurez besoin de cet identifiant à l'étape suivante.
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-0c20ac468fa3049e8",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-0787762faf1c28619",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-0f280a4c58d319a8a",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
}
]
}
```
1. [Pour détacher une instance sans réduire la capacité souhaitée, utilisez la commande detach-instances suivante.](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/detach-instances.html)
```
aws autoscaling detach-instances --instance-ids i-05b4f7d5be44822a6 \
--auto-scaling-group-name my-asg
```
Pour détacher une instance et réduire la capacité souhaitée, incluez l'`--should-decrement-desired-capacity`option.
```
aws autoscaling detach-instances --instance-ids i-05b4f7d5be44822a6 \
--auto-scaling-group-name my-asg --should-decrement-desired-capacity
```
Vous pouvez désormais associer l'instance à un autre groupe Auto Scaling.
**Pour attacher une instance à un groupe Auto Scaling**
1. Pour associer l'instance à un autre groupe Auto Scaling, utilisez la commande [attach-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/attach-instances.html) suivante.
```
aws autoscaling attach-instances --instance-ids i-05b4f7d5be44822a6 --auto-scaling-group-name my-asg-for-testing
```
1. Pour vérifier la taille du groupe Auto Scaling après avoir attaché une instance, utilisez la [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html)commande suivante.
```
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names my-asg-for-testing
```
L'exemple de réponse suivant montre que le groupe possède deux instances en cours d'exécution, dont l'une est l'instance que vous avez attachée.
```
{
"AutoScalingGroups": [
{
"AutoScalingGroupName": "my-asg-for-testing",
"AutoScalingGroupARN": "arn",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "2",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"MinSize": 1,
"MaxSize": 5,
"DesiredCapacity": 2,
...
"Instances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"HealthStatus": "Healthy",
"LifecycleState": "InService"
},
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "2",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-00dcdfffdf5175890",
"InstanceType": "t3.micro",
"HealthStatus": "Healthy",
"LifecycleState": "InService"
}
],
...
}
]
}
```
------
# Supprimer temporairement des instances du groupe Auto Scaling
Vous pouvez faire passer une instance du statut `InService` au statut `Standby`, mettre à jour ou dépanner l'instance, puis la remettre en service. Les instances en veille font toujours partie du groupe Auto Scaling, mais elles ne gèrent pas activement le trafic de l'équilibreur de charge.
Cette fonction vous permet d'arrêter et de démarrer les instances ou de les redémarrer sans vous soucier qu'Amazon EC2 Auto Scaling résilie les instances dans le cadre de ses surveillances de l'état ou lors d'événements de mise à l'échelle horizontale.
Par exemple, vous pouvez modifier l'image Amazon Machine Image (AMI) pour un groupe Auto Scaling à tout moment en modifiant le modèle de lancement ou la configuration de lancement. Toutes les instances ultérieures lancées par le groupe Auto Scaling utilisent cette AMI. Cependant, le groupe Auto Scaling ne met pas à jour les instances actuellement en service. Vous pouvez résilier ces instances et laisser Amazon EC2 Auto Scaling les remplacer ou utiliser la fonction d'actualisation de l'instance pour résilier les instances et les remplacer. Vous pouvez également placer les instances en veille, mettre à jour le logiciel, puis remettre les instances en service.
Le détachement des instances d'un groupe Auto Scaling est similaire à la mise en veille des instances. Le détachement d'instances peut être utile si vous souhaitez les associer à un autre groupe ou gérer les instances comme des instances EC2 autonomes et éventuellement les mettre hors service. Pour de plus amples informations, veuillez consulter [Détachez ou attachez des instances de votre groupe Auto Scaling](ec2-auto-scaling-detach-attach-instances.md).
**Topics**
+ [Comment fonctionne l'état de veille ?](#standby-state)
+ [Considérations](#standby-instance-considerations)
+ [État de santé d'une instance en veille](#standby-instance-health-status)
+ [Supprimer temporairement une instance en la mettant en veille](#standby-state)
## Comment fonctionne l'état de veille ?
L'état de veille fonctionne comme suit pour vous aider à temporairement supprimer une instance d'un groupe Auto Scaling :
1. Vous mettez une instance en état de veille. L'instance reste dans cet état jusqu'à ce qu'elle change de statut.
1. Si un groupe cible d'équilibreur de charge ou Classic Load Balancer est attaché à votre groupe Auto Scaling, l'instance est désenregistrée de l'équilibreur de charge. Si Connection Draining est activée pour l'équilibreur de charge, Elastic Load Balancing attend 300 secondes par défaut avant de terminer le processus de désenregistration, ce qui permet aux demandes en cours d'exécution de se terminer.
1. Vous pouvez mettre à jour ou dépanner l'instance.
1. Vous remettez l'instance en service en la sortant de l'état de veille.
1. Si un groupe cible d'équilibreur de charge ou un Classic Load Balancer est attaché au groupe Auto Scaling, l'instance est enregistrée avec l'équilibreur de charge.
Pour plus d’informations sur le cycle de vie des instances dans un groupe Auto Scaling, consultez [Cycle de vie d'une instance Amazon EC2 Auto Scaling](ec2-auto-scaling-lifecycle.md).
## Considérations
Les points suivants doivent être pris en compte lors du placement d’instances dans et hors de l’état de veille :
+ Lorsque vous mettez une instance en veille, vous pouvez soit réduire la capacité souhaitée par le biais de cette opération, soit conserver la même valeur.
+ Si vous choisissez de ne pas réduire la capacité souhaitée du groupe Auto Scaling, Amazon EC2 Auto Scaling lance une instance pour remplacer l’instance en veille. L'objectif est de vous aider à préserver la capacité pour votre application tandis qu'une ou plusieurs instances sont en veille.
+ Si vous choisissez de réduire la capacité souhaitée du groupe Auto Scaling, cela empêche le lancement d’une instance pour remplacer l’instance en veille.
+ Une fois l’instance remise en service, la capacité souhaitée est incrémentée pour refléter le nombre d’instances du groupe Auto Scaling.
+ Pour procéder à l’incrémentation (et à la décrémentation), la nouvelle capacité souhaitée doit être comprise entre la taille de groupe minimale et maximale. Sinon, l’opération échoue.
+ Si, après avoir mis une instance en veille ou remis l’instance en service en la sortant de l’état de veille, il s’avère que votre groupe Auto Scaling n’est pas équilibré entre les zones de disponibilité, Amazon EC2 Auto Scaling compense en rééquilibrant les zones de disponibilité, sauf si vous suspendez le processus `AZRebalance`. Pour de plus amples informations, veuillez consulter [Suspendre et reprendre les processus Amazon EC2 Auto Scaling](as-suspend-resume-processes.md).
+ Vous êtes facturé pour les instances en état de veille.
## État de santé d'une instance en veille
Amazon EC2 Auto Scaling ne réalise pas de surveillance de l'état sur des instances en veille. Lorsque l'instance est en veille, son état de santé reflète le statut qu'elle avait avant que vous ne la mettiez en veille. Amazon EC2 Auto Scaling ne réalise pas de surveillance de l'état sur l'instance tant que vous ne la remettez pas en service.
Par exemple, si vous mettez une instance saine en veille et que vous y mettez fin, Amazon EC2 Auto Scaling continue de signaler l'instance comme saine. Si vous tentez de remettre en service une instance arrêtée qui était en veille, Amazon EC2 Auto Scaling effectue une surveillance de l'état de l'instance, détermine qu'elle est arrêtée et non saine, et lance une instance de remplacement. Pour de plus amples informations, veuillez consulter [Surveillance de l’état des instances dans un groupe Auto Scaling](ec2-auto-scaling-health-checks.md).
## Supprimer temporairement une instance en la mettant en veille
Utilisez l'une des procédures suivantes pour mettre temporairement une instance hors service en la plaçant en mode veille.
------
#### [ Console ]
**Pour supprimer temporairement une instance**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Cochez la case située en regard du groupe Auto Scaling.
Un volet fractionné s’ouvre en bas de la page.
1. Sous l’onglet **Gestion des instances)** dans **Instances**, sélectionnez une instance.
1. Choisissez **Actions**, **Set to Standby (Régler sur Veille)**.
1. Dans la boîte de dialogue **Régler sur Veille**, gardez la case à cocher **Remplacer l’instance** sélectionnée pour lancer une instance de remplacement. Désactivez la case à cocher pour réduire la capacité souhaitée.
1. Lorsque vous êtes invité à confirmer, tapez **standby** pour confirmer le placement de l’instance spécifiée dans l’état `Standby`, puis choisissez **Régler sur Veille**.
1. Vous pouvez mettre à jour ou dépanner l’instance le cas échéant. Lorsque vous avez terminé, continuez avec l’étape suivante pour remettre l’instance en service.
1. Sélectionnez l'instance, choisissez **Actions**, **Définir sur InService**. Dans la InService boîte **de dialogue Définir** sur, choisissez **Définir sur InService**.
------
#### [ AWS CLI ]
Pour supprimer temporairement une instance de votre groupe Auto Scaling, utilisez les exemples de commandes suivants. Remplacez chaque *user input placeholder* par vos propres informations.
**Pour supprimer temporairement une instance**
1. Utilisez la commande [describe-auto-scaling-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-instances.html) suivante pour identifier l'instance à mettre à jour.
```
aws autoscaling describe-auto-scaling-instances \
--query 'AutoScalingInstances[?AutoScalingGroupName==`my-asg`]'
```
L’exemple suivant illustre la sortie produite lorsque vous exécutez cette commande.
Prenez note de l'ID de l'instance que vous souhaitez supprimer du groupe. Vous aurez besoin de cet identifiant à l'étape suivante.
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceId": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
...
]
}
```
1. Passez l'instance à l'état `Standby` avec la commande [enter-standby](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/enter-standby.html) suivante. L'option `--should-decrement-desired-capacity` réduit la capacité souhaitée afin que le groupe Auto Scaling ne lance pas d'instance de remplacement.
```
aws autoscaling enter-standby --instance-ids i-05b4f7d5be44822a6 \
--auto-scaling-group-name my-asg --should-decrement-desired-capacity
```
Voici un exemple de réponse.
```
{
"Activities": [
{
"ActivityId": "3b1839fe-24b0-40d9-80ae-bcd883c2be32",
"AutoScalingGroupName": "my-asg",
"Description": "Moving EC2 instance to Standby: i-05b4f7d5be44822a6",
"Cause": "At 2023-12-15T21:31:26Z instance i-05b4f7d5be44822a6 was moved to standby
in response to a user request, shrinking the capacity from 4 to 3.",
"StartTime": "2023-12-15T21:31:26.150Z",
"StatusCode": "InProgress",
"Progress": 50,
"Details": "{\"Subnet ID\":\"subnet-c934b782\",\"Availability Zone\":\"us-west-2a\"}"
}
]
}
```
1. (Facultatif) Vérifiez que l'état de l'instance est `Standby` avec la commande [describe-auto-scaling-instances](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-instances.html) suivante.
```
aws autoscaling describe-auto-scaling-instances --instance-ids i-05b4f7d5be44822a6
```
Voici un exemple de réponse. Notez que l'état de l'instance est désormais `Standby`.
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "Standby"
},
...
]
}
```
1. Vous pouvez mettre à jour ou dépanner l’instance le cas échéant. Lorsque vous avez terminé, continuez avec l’étape suivante pour remettre l’instance en service.
1. Remettez l'instance en service avec la commande [exit-standby](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/exit-standby.html) suivante.
```
aws autoscaling exit-standby --instance-ids i-05b4f7d5be44822a6 --auto-scaling-group-name my-asg
```
Voici un exemple de réponse.
```
{
"Activities": [
{
"ActivityId": "db12b166-cdcc-4c54-8aac-08c5935f8389",
"AutoScalingGroupName": "my-asg",
"Description": "Moving EC2 instance out of Standby: i-05b4f7d5be44822a6",
"Cause": "At 2023-12-15T21:46:14Z instance i-05b4f7d5be44822a6 was moved out of standby in
response to a user request, increasing the capacity from 3 to 4.",
"StartTime": "2023-12-15T21:46:14.678Z",
"StatusCode": "PreInService",
"Progress": 30,
"Details": "{\"Subnet ID\":\"subnet-c934b782\",\"Availability Zone\":\"us-west-2a\"}"
}
]
}
```
1. (Facultatif) Vérifiez que l'instance est remise en service avec la commande `describe-auto-scaling-instances` suivante.
```
aws autoscaling describe-auto-scaling-instances --instance-ids i-05b4f7d5be44822a6
```
Voici un exemple de réponse. Notez que l'état de l'instance est `InService`.
```
{
"AutoScalingInstances": [
{
"ProtectedFromScaleIn": false,
"AvailabilityZone": "us-west-2a",
"LaunchTemplate": {
"LaunchTemplateName": "my-launch-template",
"Version": "1",
"LaunchTemplateId": "lt-050555ad16a3f9c7f"
},
"InstanceId": "i-05b4f7d5be44822a6",
"InstanceType": "t3.micro",
"AutoScalingGroupName": "my-asg",
"HealthStatus": "HEALTHY",
"LifecycleState": "InService"
},
...
]
}
```
------
# Supprimer votre infrastructure Auto Scaling
Pour supprimer totalement l'infrastructure de mise à l'échelle, exécutez les tâches suivantes.
**Topics**
+ [Supprimer votre groupe Auto Scaling](#as-shutdown-lbs-delete-asg-cli)
+ [(Facultatif) Supprimer la configuration du lancement](#as-shutdown-lbs-delete-lc-cli)
+ [(Facultatif) Suppression du modèle de lancement](#as-shutdown-lbs-delete-lt-cli)
+ [(Facultatif) Supprimer l'équilibreur de charge et les groupes cibles](#as-shutdown-lbs-delete-lbs-cli)
+ [(Facultatif) Supprimer les CloudWatch alarmes](#as-shutdown-delete-alarms-cli)
+ [Configurer la protection contre la suppression pour vos ressources Amazon EC2 Auto Scaling](resource-deletion-protection.md)
## Supprimer votre groupe Auto Scaling
Lorsque vous supprimez un groupe Auto Scaling, ses valeurs minimales et maximales souhaitées sont définies sur 0. Les instances sont alors résiliées. La suppression d'une instance supprime également les journaux ou données associés, ainsi que tous les volumes de l'instance. Si vous ne souhaitez pas résilier une ou plusieurs instances, vous pouvez les détacher avant de supprimer le groupe Auto Scaling. Si le groupe a des politiques de mise à l'échelle, la suppression du groupe entraîne la suppression des politiques, des actions d'alarme sous-jacentes et de toute alarme qui n'a plus d'action associée.
**Pour supprimer votre groupe Auto Scaling (console)**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Cochez la case en regard de votre groupe Auto Scaling et choisissez **Actions**, puis **Supprimer**.
1. Lorsque vous êtes invité à confirmer l'opération, saisissez **delete** pour confirmer la suppression du groupe Auto Scaling spécifié, puis choisissez **Delete** (Supprimer).
Une icône de chargement dans la colonne **Name (Nom)** indique que le groupe Auto Scaling est en cours de suppression. Les colonnes **Desired** (Souhaitée), **Min** et **Max** affichent `0` instance pour le groupe Auto Scaling. Quelques minutes sont nécessaires pour résilier l'instance et supprimer le groupe. Actualisez la liste pour afficher l'état actuel.
**Pour supprimer votre groupe Auto Scaling (AWS CLI)**
Utilisez la [delete-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-auto-scaling-group.html)commande suivante pour supprimer le groupe Auto Scaling. Cette opération ne fonctionne pas si le groupe possède des instances EC2 ; elle concerne uniquement les groupes ne comportant aucune instance.
```
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name my-asg
```
Si le groupe a des instances ou des activités de mise à l'échelle en cours, utilisez la commande [delete-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-auto-scaling-group.html) avec l'option `--force-delete`. Cette action entraînera également une résiliation des instances EC2. Lorsque vous supprimez un groupe Auto Scaling de la console Amazon EC2 Auto Scaling, la console utilise cette opération pour mettre fin à toutes les instances EC2 et supprimer le groupe en même temps.
```
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name my-asg --force-delete
```
## (Facultatif) Supprimer la configuration du lancement
Vous pouvez passer cette étape pour conserver la configuration du lancement pour une utilisation ultérieure.
**Pour supprimer la configuration du lancement (console)**
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans le volet de navigation à gauche, sous **Auto Scaling**, choisissez **Groupes Auto Scaling**.
1. Sélectionnez **Configurations de lancement** en haut de la page. Lorsque vous êtes invité à confirmer, choisissez **Afficher les configurations de lancement** pour confirmer que vous souhaitez consulter la page **Configurations de lancement**.
1. Sélectionnez votre configuration du lancement et cliquez sur **Actions**, **Supprimer la configuration de lancement**.
1. Lorsque vous êtes invité à confirmer l’opération, choisissez **Supprimer**.
**Pour supprimer la configuration du lancement (AWS CLI)**
Utilisez la commande [delete-launch-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/delete-launch-configuration.html) suivante.
```
aws autoscaling delete-launch-configuration --launch-configuration-name my-launch-config
```
## (Facultatif) Suppression du modèle de lancement
Vous pouvez supprimer votre modèle de lancement ou juste une version de votre modèle de lancement. Lorsque vous supprimez un modèle de lancement, toutes ses versions sont supprimées.
Vous pouvez ignorer cette étape pour conserver le modèle de lancement en vue d'une utilisation ultérieure.
**Pour supprimer votre modèle de lancement (console)**
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans le volet de navigation, sous **Instances**, choisissez **Launch Templates** (Modèles de lancement).
1. Sélectionnez votre modèle de lancement, puis effectuez l'une des actions suivantes :
+ Choisissez **Actions**, puis **Delete template** (Supprimer le modèle). Lorsque vous êtes invité à confirmer l'opération, saisissez **Delete** pour confirmer la suppression du modèle de lancement spécifié, puis choisissez **Delete** (Supprimer).
+ Choisissez **Actions**, puis **Delete template version** (Supprimer la version du modèle). Sélectionnez la version à supprimer et choisissez **Supprimer**.
**Pour supprimer le modèle de lancement (AWS CLI)**
Utilisez la commande [delete-launch-template](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-launch-template.html) suivante pour supprimer votre modèle et toutes ses versions.
```
aws ec2 delete-launch-template --launch-template-id lt-068f72b72934aff71
```
Vous pouvez également utiliser la commande [delete-launch-template-versions](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/delete-launch-template-versions.html) pour supprimer une version spécifique d'un modèle de lancement.
```
aws ec2 delete-launch-template-versions --launch-template-id lt-068f72b72934aff71 --versions 1
```
## (Facultatif) Supprimer l'équilibreur de charge et les groupes cibles
Ignorez cette étape si votre groupe Auto Scaling n'est pas associé à un équilibreur de charge Elastic Load Balancing ou si vous souhaitez conserver ce dernier pour une utilisation ultérieure.
**Pour supprimer l'équilibreur de charge (console)**
1. Ouvrez la console Amazon EC2 à l’adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Dans le panneau de navigation, sous **Load Balancing** (Équilibrage de charge), choisissez **Load Balancers** (Équilibreurs de charge).
1. Sélectionnez l'équilibreur de charge et choisissez **Actions**, **Delete** (Supprimer).
1. Lorsque vous êtes invité à confirmer l'opération, choisissez **Oui, supprimer**.
**Pour supprimer votre groupe cible (console)**
1. Dans le panneau de navigation, sous **Load Balancing** (Répartition de charge), choisissez **Target Groups** (Groupes cibles).
1. Sélectionnez le groupe cible et choisissez **Actions**, **Delete** (Supprimer).
1. Lorsque vous êtes invité à confirmer l’opération, choisissez **Yes, Delete**.
**Pour supprimer l'équilibreur de charge associé au groupe Auto Scaling (AWS CLI)**
Pour les équilibreurs de charge d'application et les équilibreurs de charge réseau, utilisez les commandes [delete-load-balancer](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/elbv2/delete-load-balancer.html)et [delete-target-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/elbv2/delete-target-group.html)les commandes suivantes.
```
aws elbv2 delete-load-balancer --load-balancer-arn my-load-balancer-arn
aws elbv2 delete-target-group --target-group-arn my-target-group-arn
```
Pour les équilibreurs de charge classiques, utilisez la [delete-load-balancer](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/elb/delete-load-balancer.html)commande suivante.
```
aws elb delete-load-balancer --load-balancer-name my-load-balancer
```
## (Facultatif) Supprimer les CloudWatch alarmes
Pour supprimer les CloudWatch alarmes associées à votre groupe Auto Scaling, procédez comme suit. Par exemple, des alarmes peuvent être associées à la mise à l’échelle d’étape ou à de simples politiques de mise à l’échelle.
**Note**
La suppression d'un groupe Auto Scaling supprime automatiquement les CloudWatch alarmes gérées par Amazon EC2 Auto Scaling dans le cadre d'une politique de dimensionnement du suivi des cibles.
Vous pouvez ignorer cette étape si votre groupe Auto Scaling n'est associé à aucune CloudWatch alarme ou si vous souhaitez conserver les alarmes pour une utilisation future.
**Pour supprimer les CloudWatch alarmes (console)**
1. Ouvrez la CloudWatch console à l'adresse [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/).
1. Dans le panneau de navigation, choisissez **Alarms** (Alarmes).
1. Sélectionnez les alarmes et choisissez **Action**, **Delete** (Supprimer).
1. Lorsque vous êtes invité à confirmer l’opération, choisissez **Supprimer**.
**Pour supprimer les CloudWatch alarmes (AWS CLI)**
Utilisez la commande [delete-alarms](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/delete-alarms.html) suivante. Vous pouvez supprimer une ou plusieurs alarmes en même temps. Par exemple, utilisez la commande suivante pour supprimer les alarmes `Step-Scaling-AlarmHigh-AddCapacity` et `Step-Scaling-AlarmLow-RemoveCapacity`.
```
aws cloudwatch delete-alarms --alarm-name Step-Scaling-AlarmHigh-AddCapacity Step-Scaling-AlarmLow-RemoveCapacity
```
# Configurer la protection contre la suppression pour vos ressources Amazon EC2 Auto Scaling
Protégez votre infrastructure Amazon EC2 Auto Scaling contre toute suppression accidentelle en configurant plusieurs niveaux de protection. Auto Scaling propose plusieurs approches pour empêcher la suppression de ressources indésirables pour vos groupes Auto Scaling et les instances Amazon EC2 qu'il gère.
**Topics**
+ [Configurer la protection contre la suppression des groupes Auto Scaling](#asg-deletion-protection)
+ [Contrôlez les autorisations de suppression grâce aux politiques IAM](#deletion-protection-iam-policies)
## Configurer la protection contre la suppression des groupes Auto Scaling
La protection contre la suppression est un paramètre au niveau des ressources qui empêche la suppression accidentelle de votre groupe Amazon EC2 Auto Scaling. Lorsqu'elle est activée, la protection contre la suppression empêche l'opération de l'[ DeleteAutoScalingGroup](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DeleteAutoScalingGroup.html)API de réussir. Vous devez d'abord mettre à jour le paramètre de protection contre la suppression à un niveau moins restrictif avant de pouvoir supprimer le groupe Auto Scaling.
Amazon EC2 Auto Scaling propose trois niveaux de protection contre la suppression :
**Aucun** (par défaut)
Aucune protection contre la suppression n'est activée, ce qui signifie que votre groupe Auto Scaling peut être supprimé avec ou sans `ForceDelete` cette option. Lorsqu'elles `ForceDelete` sont utilisées, toutes les instances Amazon EC2 gérées par votre groupe Auto Scaling seront également résiliées de force sans exécuter de hooks de cycle de vie de résiliation.
**Empêcher la suppression forcée**
Votre groupe Auto Scaling ne peut pas être supprimé lorsque vous utilisez `ForceDelete` cette option. Cette configuration permet de supprimer des groupes Auto Scaling vides (groupes sans instances). Cette option est recommandée pour les charges de travail de production pour lesquelles vous souhaitez empêcher la fermeture massive des instances tout en autorisant le nettoyage des groupes vides.
**Empêcher toute suppression**
Votre groupe Auto Scaling ne peut pas être supprimé, que l'`ForceDelete`option soit utilisée ou non. Cette option offre la meilleure protection contre les suppressions accidentelles. Cela nécessite de désactiver explicitement la protection contre les suppressions avant que votre groupe Auto Scaling puisse être supprimé. Cela est recommandé pour les groupes Auto Scaling critiques qui devraient être rarement ou jamais supprimés.
### Comment fonctionne la protection contre la suppression
Lorsque vous tentez d'utiliser l'[ DeleteAutoScalingGroup](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_DeleteAutoScalingGroup.html)API avec la protection contre la suppression activée :
1. Amazon EC2 Auto Scaling valide le paramètre de protection contre la suppression avant de traiter la demande.
1. Si le niveau de protection contre la suppression configuré bloque la tentative de suppression, Amazon EC2 Auto Scaling renvoie `ValidationError` un.
1. Votre groupe Auto Scaling et ses instances Amazon EC2 restent inchangés.
1. Vous devez mettre à jour le paramètre de protection contre la suppression à un niveau moins restrictif avant de pouvoir supprimer votre groupe Auto Scaling.
La protection contre la suppression n'empêche pas d'autres opérations telles que :
+ Mise à jour de la configuration du groupe Auto Scaling.
+ Mettre fin à des instances individuelles.
+ Opérations de mise à l'échelle (manuelles ou automatiques).
+ Suspension ou reprise des processus.
Pour plus d'informations sur la manière de gérer correctement la résiliation d'une instance, consultez[Concevez vos applications pour gérer avec élégance la résiliation des instances](gracefully-handle-instance-termination.md).
### Configuration de la protection contre la suppression
Vous pouvez définir la protection contre la suppression lorsque vous créez un groupe Auto Scaling ou que vous mettez à jour le paramètre d'un groupe Auto Scaling existant.
------
#### [ Console ]
**Pour créer un groupe Auto Scaling avec protection contre les suppressions**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Choisissez **Créer un groupe Auto Scaling**.
1. Effectuez les étapes de configuration de votre groupe Auto Scaling.
1. Sur la page **Configurer la taille et le dimensionnement du groupe**, développez **Paramètres supplémentaires**.
1. Pour la **protection contre la suppression de groupes Auto Scaling**, choisissez le niveau de protection souhaité :
+ **Aucune - Aucune** protection contre la suppression (par défaut)
+ **Empêcher la suppression forcée** - Bloquer les opérations de suppression forcée
+ **Empêcher toute suppression** - Bloquer toutes les opérations de suppression
1. Effectuez les étapes restantes pour créer votre groupe Auto Scaling.
**Pour mettre à jour la protection contre la suppression sur un groupe Auto Scaling existant**
1. Ouvrez la console Amazon EC2 à l'adresse [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/), puis sélectionnez **Auto Scaling Groups** dans le volet de navigation.
1. Cochez la case située en regard de votre groupe Auto Scaling.
1. Choisissez **Actions**, **Modifier**.
1. Sous **Paramètres supplémentaires**, mettez à jour le paramètre de **protection contre la suppression des groupes Auto Scaling**.
1. Choisissez **Mettre à jour**.
------
#### [ AWS CLI ]
**Pour créer un groupe Auto Scaling avec protection contre les suppressions**
Utilisez la [create-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/create-auto-scaling-group.html)commande avec le `--deletion-protection` paramètre :
```
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name my-asg \
--launch-template LaunchTemplateName=my-template,Version='$Latest' \
--min-size 1 \
--max-size 5 \
--desired-capacity 2 \
--vpc-zone-identifier "subnet-12345678,subnet-87654321" \
--deletion-protection prevent-force-deletion
```
Les valeurs valides pour `--deletion-protection` sont : `none` \$1 `prevent-force-deletion` \$1 `prevent-all-deletion`
**Pour mettre à jour la protection contre la suppression sur un groupe Auto Scaling existant**
Utilisez la commande [update-auto-scaling-group](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/update-auto-scaling-group.html) :
```
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name my-asg \
--deletion-protection prevent-all-deletion
```
**Pour désactiver la protection contre la suppression**
Définissez la protection contre la suppression sur `none` :
```
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name my-asg \
--deletion-protection none
```
**Pour vérifier l'état de la protection contre les suppressions**
Utilisez la commande [describe-auto-scaling-groups](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/autoscaling/describe-auto-scaling-groups.html) :
```
aws autoscaling describe-auto-scaling-groups \
--auto-scaling-group-names my-asg
```
------
## Contrôlez les autorisations de suppression grâce aux politiques IAM
Utilisez des politiques Gestion des identités et des accès AWS (IAM) pour contrôler les utilisateurs et les rôles autorisés à supprimer des groupes Auto Scaling. Les contrôles basés sur l'IAM fournissent un niveau de sécurité supplémentaire en limitant les autorisations au niveau de l'identité.
Les politiques IAM sont particulièrement utiles lorsque vous souhaitez :
+ Accordez à différents utilisateurs différents niveaux d'accès aux opérations Auto Scaling.
+ Empêchez certains utilisateurs d'utiliser l'`ForceDelete`option même s'ils peuvent effectuer d'autres opérations Auto Scaling.
+ Limitez les autorisations de suppression à des groupes Auto Scaling spécifiques.
La politique suivante autorise la suppression d’un groupe Auto Scaling uniquement si le groupe comporte la balise `environment=development`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "autoscaling:DeleteAutoScalingGroup",
"Resource": "*",
"Condition": {
"StringEquals": { "aws:ResourceTag/environment": "development" }
}
}]
}
```
------
La politique suivante utilise la clé de `autoscaling:ForceDelete` condition pour contrôler l'accès à l'action d'`DeleteAutoScalingGroup`API. Cela peut empêcher certains utilisateurs d'utiliser l'`ForceDelete`opération, qui met fin à toutes les instances Amazon EC2 au sein d'un groupe Auto Scaling.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "autoscaling:DeleteAutoScalingGroup",
"Resource": "*",
"Condition": {
"Bool": {
"autoscaling:ForceDelete": "true"
}
}
}]
}
```
------
Sinon, si vous n'utilisez pas de clés de condition pour contrôler l'accès aux groupes Auto Scaling, vous pouvez spécifier les ressources ARNs de l'`Resource`élément pour contrôler l'accès à la place.
La politique suivante autorise les utilisateurs à utiliser l'action `DeleteAutoScalingGroup` API, mais uniquement pour les groupes Auto Scaling dont le nom commence par`devteam-`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "autoscaling:DeleteAutoScalingGroup",
"Resource": "arn:aws:autoscaling:us-east-1:111122223333:autoScalingGroup:*:autoScalingGroupName/devteam-*"
}
]
}
```
------
Vous pouvez également en spécifier plusieurs ARNs en les insérant dans une liste. L'inclusion de l'UUID permet de s'assurer que l'accès est accordé au groupe Auto Scaling spécifique. L'UUID d'un nouveau groupe est différent de l'UUID d'un groupe supprimé portant le même nom.
```
"Resource": [
"arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-1",
"arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-2",
"arn:aws:autoscaling:region:account-id:autoScalingGroup:uuid:autoScalingGroupName/devteam-3"
]
```
Pour d'autres exemples de politiques IAM pour Amazon EC2 Auto Scaling, y compris les politiques qui contrôlent les autorisations de suppression, consultez. [Exemples de politiques basées sur l’identité](security_iam_id-based-policy-examples.md)