Configurer les politiques de résiliation pour Amazon EC2 Auto Scaling - Amazon EC2 Auto Scaling

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.

Configurer les politiques de résiliation pour Amazon EC2 Auto Scaling

Une politique de résiliation fournit les critères qu'Amazon EC2 Auto Scaling suit pour mettre fin aux instances dans un ordre spécifique.

Par défaut, Amazon EC2 Auto Scaling utilise une politique de résiliation conçue pour mettre fin d'abord aux instances qui utilisent des configurations obsolètes. Vous pouvez modifier la politique de résiliation afin de contrôler les instances les plus importantes à résilier en premier.

Lorsqu'Amazon EC2 Auto Scaling met fin à des instances, il essaie de maintenir l'équilibre entre les zones de disponibilité activées pour votre groupe Auto Scaling. Le maintien de l'équilibre zonal prime sur la politique de résiliation. Si une zone de disponibilité possède plus d'instances que d'autres, Amazon EC2 Auto Scaling applique d'abord la politique de résiliation à la zone déséquilibrée. Si les zones de disponibilité sont équilibrées, la politique de résiliation s'applique à toutes les zones.

Comment fonctionne la politique de résiliation par défaut

Lorsqu'Amazon EC2 Auto Scaling doit mettre fin à une instance, il identifie d'abord la zone de disponibilité (ou les zones) qui compte le plus d'instances et au moins une instance qui n'est pas protégée contre le scaling in. Il procède ensuite à l'évaluation des instances non protégées au sein de la zone de disponibilité identifiée comme suit :

Instances utilisant des configurations obsolètes
  • Pour les groupes qui utilisent un modèle de lancement : déterminez si l'une des instances utilise des configurations obsolètes, en hiérarchisant dans cet ordre :

    1. Vérifiez d'abord les instances lancées avec une configuration de lancement.

    2. Vérifiez ensuite si les instances ont été lancées à l'aide d'un modèle de lancement différent du modèle de lancement actuel.

    3. Enfin, vérifiez les instances utilisant la version la plus ancienne du modèle de lancement actuel.

  • Pour les groupes utilisant une configuration de lancement : déterminez si l'une des instances utilise la configuration de lancement la plus ancienne.

Si aucune instance avec des configurations obsolètes n'est trouvée, ou s'il existe plusieurs instances parmi lesquelles choisir, Amazon EC2 Auto Scaling prend en compte le prochain critère selon lequel les instances approchent de leur prochaine heure de facturation.

Instances approchant de l'heure de facturation suivante

Déterminez si l'une des instances répondant aux critères précédents est la plus proche de l'heure de facturation suivante. Si plusieurs instances sont également proches, arrêtez-en une au hasard. Cela vous permet d'optimiser l'utilisation de vos instances facturées à l'heure. Cependant, la majeure partie de l'utilisation de l'EC2 est désormais facturée à la seconde, de sorte que cette optimisation présente moins d'avantages. Pour plus d’informations, consultez Tarification Amazon EC2.

L'organigramme suivant illustre le fonctionnement de la politique de résiliation par défaut pour les groupes qui utilisent un modèle de lancement.


                        Un organigramme montrant comment un groupe Auto Scaling utilise la politique de résiliation par défaut pour mettre fin à des instances.

Politique de résiliation par défaut et groupes d'instances mixtes

Amazon EC2 Auto Scaling applique des critères supplémentaires lors de la résiliation d'instances dans des groupes d'instances mixtes.

Lorsqu'Amazon EC2 Auto Scaling doit mettre fin à une instance, il identifie d'abord quelle option d'achat (ponctuelle ou à la demande) doit être résiliée en fonction des paramètres du groupe. Cela garantit que le groupe évolue vers le ratio spécifié d'instances ponctuelles et à la demande au fil du temps.

Il applique ensuite la politique de résiliation indépendamment au sein de chaque zone de disponibilité. Il détermine quelle instance ponctuelle ou à la demande dans quelle zone de disponibilité mettre fin afin de maintenir l'équilibre des zones de disponibilité. La même logique s'applique à un groupe d'instances mixte avec des pondérations définies pour les types d'instances.

Dans chaque zone, la politique de résiliation par défaut fonctionne comme suit pour déterminer quelle instance non protégée peut être résiliée dans le cadre de l'option d'achat identifiée :

  1. Déterminez si l'une des instances peut être interrompue afin d'améliorer l'alignement avec la stratégie d'allocation spécifiée pour le groupe Auto Scaling. Si aucune instance n'est identifiée pour l'optimisation, ou s'il existe plusieurs instances parmi lesquelles choisir, l'évaluation se poursuit.

  2. Déterminez si l'une des instances utilise des configurations obsolètes, en hiérarchisant dans cet ordre :

    1. Vérifiez d'abord les instances lancées avec une configuration de lancement.

    2. Vérifiez ensuite si les instances ont été lancées à l'aide d'un modèle de lancement différent du modèle de lancement actuel.

    3. Enfin, vérifiez les instances utilisant la version la plus ancienne du modèle de lancement actuel.

    Si aucune instance avec des configurations obsolètes n'est trouvée, ou s'il existe plusieurs instances parmi lesquelles choisir, l'évaluation se poursuit.

  3. Déterminez si l'une des instances est la plus proche de l'heure de facturation suivante. Si plusieurs instances sont également proches, choisissez-en une au hasard.

Politiques de résiliation prédéfinies

Vous avez le choix entre les politiques de résiliation prédéfinies suivantes :

  • Default— Mettez fin aux instances conformément à la politique de résiliation par défaut.

  • AllocationStrategy— Mettez fin aux instances du groupe Auto Scaling pour aligner les instances restantes sur la stratégie d'allocation pour le type d'instance en cours de résiliation (instance ponctuelle ou instance à la demande). Cette politique est utile lorsque vous préférez les types d'instances ayant changé. Si la politique d'allocation Spot est lowest-price, vous pouvez progressivement rééquilibrer la distribution d'instances Spot entre vos groupes Spot ayant le prix le plus bas. Si la politique d'allocation Spot est capacity-optimized, vous pouvez progressivement rééquilibrer la distribution d'instances Spot entre vos groupes Spot ayant la capacité Spot disponible.la plus élevée. Vous pouvez également remplacer progressivement les instances à la demande ayant un type de priorité inférieur par les instances à la demande ayant un type de priorité supérieur.

  • OldestLaunchTemplate— Mettez fin aux instances dont le modèle de lancement est le plus ancien. Avec cette politique, les instances qui utilisent le modèle de lancement non courant sont mises hors service en premier, suivies des instances qui utilisent la plus ancienne version du modèle de lancement actuel. Cette politique est utile lorsque vous mettez à jour un groupe et supprimez les instances d'une configuration précédente.

  • OldestLaunchConfiguration— Mettez fin aux instances dont la configuration de lancement est la plus ancienne. Cette politique est utile lorsque vous mettez à jour un groupe et supprimez les instances d’une configuration précédente. Avec cette politique, les instances qui utilisent la configuration de lancement non courant sont mises hors service en premier.

  • ClosestToNextInstanceHour— Résiliez les instances les plus proches de l'heure de facturation suivante. Cette politique vous permet d'optimiser l'utilisation de vos instances qui ont un tarif horaire.

  • NewestInstance— Mettez fin à l'instance la plus récente du groupe. Cette politique est utile lorsque vous testez une nouvelle configuration de lancement mais ne souhaitez pas la garder en production.

  • OldestInstance— Mettez fin à la plus ancienne instance du groupe. Cette option est utile lorsque vous mettez à niveau les instances du groupe Auto Scaling vers un nouveau type d'instance EC2. Vous pouvez petit à petit remplacer les anciennes instances par des nouvelles.

    Note

    Amazon EC2 Auto Scaling équilibre toujours les instances entre les zones de disponibilité en premier, quelle que soit la politique de résiliation utilisée. Par conséquent, vous pouvez rencontrer des situations dans lesquelles certaines instances plus récentes sont résiliées avant les instances plus anciennes. Par exemple, lorsqu'une zone de disponibilité est ajoutée plus récemment ou lorsqu'une zone de disponibilité possède plus d'instances que celles qui sont utilisées par le groupe.

Modifier la politique de résiliation d'un groupe Auto Scaling

Pour modifier la politique de résiliation de votre groupe Auto Scaling, appliquez l'une des méthodes suivantes.

Console

Vous ne pouvez pas modifier la politique de résiliation lorsque vous créez initialement un groupe Auto Scaling dans la console Amazon EC2 Auto Scaling. La politique de résiliation par défaut est utilisée automatiquement. Une fois votre groupe Auto Scaling créé, vous pouvez remplacer la politique par défaut par une autre politique de résiliation ou par plusieurs politiques de résiliation répertoriées dans l'ordre dans lequel elles doivent s'appliquer.

Pour modifier la politique de résiliation d'un groupe Auto Scaling
  1. Ouvrez la console Amazon EC2 à l’adresse https://console.aws.amazon.com/ec2/ et choisissez Groupes Auto Scaling dans le panneau de navigation.

  2. Cochez la case située en regard du groupe Auto Scaling.

    Un volet fractionné s’ouvre en bas de la page.

  3. Sous l’onglet Détails, choisissez Configurations avancées, Modifier.

  4. Pour Termination policies (Politiques de résiliation), choisissez une ou plusieurs politiques de résiliation. Si vous choisissez plusieurs politiques, placez-les dans l'ordre dans lequel vous souhaitez qu'elles soient évaluées.

    Vous pouvez éventuellement choisir Custom termination policy (Politique de résiliation personnalisée), puis choisir une fonction Lambda qui répond à vos besoins. Si vous avez créé des versions et des alias pour votre fonction Lambda, vous pouvez choisir une version ou un alias dans la liste déroulante Version/Alias. Pour utiliser la version non publiée de votre fonction Lambda, laissez Version/Alias sur sa valeur par défaut. Pour plus d’informations, consultez Créer une politique de résiliation personnalisée avec Lambda.

    Note

    Lorsque vous utilisez plusieurs politiques, leur ordre doit être défini correctement :

    • Si vous utilisez la politique Par défaut, elle doit être la dernière de la liste.

    • Si vous utilisez une Politique de résiliation personnalisée, elle doit être la première politique de la liste.

  5. Choisissez Mettre à jour.

AWS CLI

La politique de résiliation par défaut est utilisée automatiquement sauf si une politique différente est spécifiée.

Pour modifier la politique de résiliation d'un groupe Auto Scaling

Utilisez l’une des commandes suivantes :

Vous pouvez utiliser individuellement les politiques de résiliation ou les combiner dans une liste de politiques. Par exemple, utilisez la commande suivante pour mettre à jour un groupe Auto Scaling afin d'utiliser la politique OldestLaunchConfiguration en premier lieu, puis la politique ClosestToNextInstanceHour.

aws autoscaling update-auto-scaling-group --auto-scaling-group-name my-asg --termination-policies "OldestLaunchConfiguration" "ClosestToNextInstanceHour"

Si vous utilisez la politique de résiliation Default, mettez-la en fin de liste. Par exemple, --termination-policies "OldestLaunchConfiguration" "Default".

Pour utiliser une politique de résiliation personnalisée, vous devez d'abord créer votre politique de résiliation à l'aide de AWS Lambda. Pour spécifier la fonction Lambda à utiliser comme politique de résiliation, mettez-la en fin de liste. Par exemple, --termination-policies "arn:aws:lambda:us-west-2:123456789012:function:HelloFunction:prod" "OldestLaunchConfiguration". Pour plus d’informations, consultez Créer une politique de résiliation personnalisée avec Lambda.