Cette approche hybride Auto Scaling ne semble pas être disponible dès le départ, malheureusement.
Cependant, vous pouvez peut-être contourner cette limitation comme suit (non testé, juste une conception de système que je jongle depuis un certain temps):
Solution de contournement potentielle
Comme indiqué dans Utilisation de la mise à l'échelle automatique pour lancer des instances ponctuelles, l'offre de prix au comptant est un paramètre de la configuration de lancement utilisée. Comme vous l'avez souligné, aucune configuration de lancement hybride n'est disponible, elle doit plutôt être à la demande ou sur place, ce qui signifie que le cas d'utilisation nécessite deux configurations de lancement différentes.
Cela ne semble pas aider immédiatement, car vous ne pouvez attacher qu'une seule configuration de lancement à un groupe Auto Scaling à la fois , avec les contraintes suivantes (partiellement obsolètes) (voir Configuration de lancement ):
Lorsque vous attachez une configuration de lancement nouvelle ou mise à jour à votre groupe Auto Scaling, toute nouvelle instance sera lancée à l'aide des nouveaux paramètres de configuration. Les instances existantes ne sont pas affectées . Lorsque Auto Scaling doit être réduit, il met d'abord fin aux instances qui ont une configuration de lancement plus ancienne . [c'est moi qui souligne]
Les parties soulignées sont cependant essentielles, la première couvrant l'exigence de maintenir les instances à la demande en cours d'exécution après le passage de la configuration de lancement à la demande initiale respective à la configuration de lancement supplémentaire, et la seconde n'étant plus nécessairement le cas en raison de les politiques de terminaison Auto Scaling récemment introduites (pour un changement, il n'y a généralement pas eu de fanfare via un article de blog AWS), documentées dans la politique de terminaison d'instance pour votre groupe Auto Scaling :
Avant que Auto Scaling sélectionne une instance à terminer, il identifie d'abord la zone de disponibilité qui a plus d'instances que les autres zones de disponibilité utilisées par le groupe. Si toutes les zones de disponibilité ont le même nombre d'instances, il identifie une zone de disponibilité aléatoire. Dans la zone de disponibilité identifiée, Auto Scaling utilise la stratégie de résiliation pour sélectionner l'instance à résilier . [c'est moi qui souligne]
Comme il est indiqué dans Comment votre résiliation Policy Works , vous pouvez maintenant spécifier NewestInstance , si vous voulez la dernière instance lancée à fin , ce qui serait l' un des cas ponctuels , plus récemment lancé:
Auto Scaling utilise l'heure de lancement de l'instance pour identifier l'instance qui a été lancée en dernier.
Évidemment, il peut y avoir un peu plus à cela, par exemple, vous pouvez spécifier l'une des politiques en tant que politique autonome, ou vous pouvez répertorier plusieurs politiques dans une liste ordonnée , mais cette approche devrait garantir la charge de toutes les instances prises en compte dans le mesures et déclencheurs à mise à l'échelle automatique ; une mise en garde demeure cependant:
Caveat
Si l'équilibreur de charge met fin à l'une des instances à la demande pour toute autre raison (par exemple, parce qu'elle est devenue malsaine en soi), elle ne sera pas remplacée automatiquement par une instance à la demande. Vous devez donc surveiller et tenir compte de cet événement séparément, par exemple en réactivant temporairement la configuration de lancement à la demande.
Bonne chance!