Le palier web roule 12 instances c6i.large à la demande derrière un ALB. La facture pour ce palier seul est notable, et la charge est sans état — chaque requête tape Redis pour la session, chaque réponse est reproductible à partir des données de la requête. Le Spot est la bonne piste. La première coupe naïve, « passer l’ASG à 100 % Spot », marche une semaine, puis la capacité Spot pour c6i.large dans us-east-1a s’évapore pendant une surge régionale, chaque préavis d’interruption Spot se déclenche en même temps, l’ALB draine une douzaine d’instances simultanément, et l’application est indisponible pendant les quatre minutes que prend le backfill à la demande pour lancer et chauffer. La bonne façon d’utiliser le Spot sous un ASG est de garder une base à la demande notable, de diversifier entre types d’instances et zones pour qu’aucune piscine de capacité unique ne puisse paralyser la flotte, et de choisir la stratégie d’allocation qu’AWS va effectivement honorer pendant une surge.

Ce qui se passe

La politique d’instances mixtes de l’ASG décrit trois choses orthogonales : le modèle de lancement partagé par toutes les instances (AMI, groupes de sécurité, IAM, données utilisateur — la recette de boot), les surcharges de type d’instance qui disent « n’importe lequel de ces types est acceptable », et les options d’achat qui disent « je veux N % à la demande et 100-N % en Spot, alloue-le comme ça ».

Les deux stratégies d’allocation qui comptent aujourd’hui :

price-capacity-optimized, le défaut actuel et celui à utiliser. AWS alloue la capacité Spot depuis les piscines qui ont à la fois beaucoup de capacité disponible et un prix bas. Capacité d’abord, prix ensuite. C’est le bon choix pour presque tout.
capacity-optimized, l’allocateur capacité-d’abord original. Choisit les piscines les plus profondes sans regarder le prix. Légèrement plus sûr contre l’interruption, légèrement plus cher. À utiliser quand la survie à l’interruption domine le coût.
lowest-price, l’allocateur ancien. Choisit la piscine la moins chère sans regarder la profondeur. Va systématiquement choisir la piscine que tout le monde fuit. Ne pas utiliser pour la production.

La diversification est l’autre levier. Une flotte Spot qui peut lancer dans cinq types d’instances et trois zones a quinze piscines de capacité. Une flotte épinglée à un type dans une zone en a une. Quand cette piscine se vide, toute la portion Spot de la flotte reçoit des préavis d’interruption la même minute. La vraie diversification, c’est choisir des types d’instances aux profils de ressources similaires mais de familles différentes — c6i.large plus c5.large plus c6a.large plus m6i.large (il a plus de mémoire mais acceptable pour un palier web sans état), chacun disponible dans chaque zone que l’ASG couvre.

La base à la demande est votre plancher. AWS garantit la capacité à la demande ; il ne garantit pas le Spot. La base devrait couvrir le trafic minimum absolu dont la charge a besoin pour continuer à servir, même si toutes les instances Spot disparaissent en même temps. Pour un palier web sans état derrière un ALB, c’est habituellement 30 à 40 % de la taille typique — assez pour que la perte de tout le Spot dégrade les performances sans tomber le site.

Le préavis d’interruption Spot est de deux minutes. AWS envoie un événement CloudWatch deux minutes avant de terminer une instance Spot. Deux minutes suffisent à drainer le target group ALB (le délai de désenregistrement de 30 secondes est large), purger les requêtes en vol et nettoyer. Ce n’est pas assez pour démarrer un remplacement à la demande depuis zéro — c’est ce que gèrent la base à la demande et le ratio de surprovisionnement.

Comment vérifier

Inspecter la configuration d’instances mixtes actuelle :

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names my-web-prod-asg \
  --query 'AutoScalingGroups[0].MixedInstancesPolicy' \
  --output json

Une politique de production saine ressemble à ça :

{
  "LaunchTemplate": {
    "LaunchTemplateSpecification": {
      "LaunchTemplateName": "my-web-prod-lt",
      "Version": "$Default"
    },
    "Overrides": [
      {"InstanceType": "c6i.large"},
      {"InstanceType": "c5.large"},
      {"InstanceType": "c6a.large"},
      {"InstanceType": "m6i.large"},
      {"InstanceType": "m5.large"}
    ]
  },
  "InstancesDistribution": {
    "OnDemandAllocationStrategy": "prioritized",
    "OnDemandBaseCapacity": 4,
    "OnDemandPercentageAboveBaseCapacity": 20,
    "SpotAllocationStrategy": "price-capacity-optimized",
    "SpotInstancePools": 0
  }
}

Pour une flotte de 12 instances, ça donne : 4 à la demande toujours (la base), puis 20 % de chaque instance additionnelle est à la demande, 80 % est Spot. À 12 au total : 4 de base + 2 à la demande au-dessus de la base + 6 Spot. Perdre les 6 Spot d’un coup laisse la flotte à 6 instances — capacité de moitié, dégradée mais en service.

Pour voir à quelle fréquence les interruptions Spot se déclenchent vraiment sur cet ASG :

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2Spot \
  --metric-name InterruptedSpotInstances \
  --dimensions Name=AutoScalingGroupName,Value=my-web-prod-asg \
  --start-time $(date -u -v-30d +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Sum \
  --output text

Les piscines Spot stables montrent peut-être une interruption par instance par jour en conditions normales, parfois zéro pendant des jours d’affilée. Une piscine sous stress montre un cluster d’interruptions sur une seule heure — c’est la signature d’un événement régional de capacité, et c’est exactement le moment où votre diversification gagne sa place.

L’événement d’interruption Spot est publié vers CloudWatch Events / EventBridge :

aws events list-rules \
  --query 'Rules[?contains(EventPattern, `EC2 Spot Instance Interruption Warning`)]'

Si la règle n’existe pas, l’ASG ne draine pas proprement. Les instances Spot devraient avoir un gestionnaire d’interruption accroché à un lifecycle hook qui désenregistre du load balancer avant qu’AWS termine l’instance.

La correction

L’exemple travaillé, sur un palier web sans état dimensionné à 12 instances de base et 30 en pic :

Définir le panier de types d’instances. Choisir 4 à 6 types similaires en vCPU et mémoire. Pour un palier qui roule sur c6i.large (2 vCPU, 4 Go), le panier est c6i.large, c5.large, c6a.large, m6i.large (4 Go côté mémoire ça va), m5.large. Valider que l’AMI marche sur tous. Les types ARM comme c6g sont un panier à part — ne pas mélanger les architectures dans une politique sauf si l’AMI est multi-arch.
Choisir la base à la demande. Pour un palier où être à moitié de capacité est dégradé-mais-vivant : 30 à 40 % de la taille de flotte en charge typique. Pour un palier qui a vraiment besoin de chaque instance : 60 % ou plus, et se demander si le Spot est même le bon outil. Pour cet exemple, 4 de base sur une flotte typique de 12.
Régler le pourcentage à la demande au-dessus de la base. C’est le ratio pour tout scaling au-dessus de la base. 20 % au-dessus de la base est un bon point de départ — ça veut dire que le scale-out est majoritairement Spot mais ajoute un peu de à-la-demande en montant, pour que le ratio de la flotte ne penche pas trop Spot au pic.
Choisir la stratégie d’allocation Spot. price-capacity-optimized pour tout ce qui n’a pas une exigence spécifique de survie à l’interruption. Si la charge est vraiment sensible — des travaux longs qui perdent du progrès à l’interruption — utiliser capacity-optimized.

Configurer la politique. Avec l’ASG déjà sur un modèle de lancement :

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-web-prod-asg \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateName": "my-web-prod-lt",
        "Version": "$Default"
      },
      "Overrides": [
        {"InstanceType": "c6i.large"},
        {"InstanceType": "c5.large"},
        {"InstanceType": "c6a.large"},
        {"InstanceType": "m6i.large"},
        {"InstanceType": "m5.large"}
      ]
    },
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 4,
      "OnDemandPercentageAboveBaseCapacity": 20,
      "SpotAllocationStrategy": "price-capacity-optimized"
    }
  }'

Câbler le gestionnaire d’interruption Spot. Un lifecycle hook sur autoscaling:EC2_INSTANCE_TERMINATING est une approche — voir l’article sur les lifecycle hooks. L’approche plus simple pour les flottes derrière ALB est de régler deregistration_delay.timeout_seconds du target group à 30 et de compter sur le drainage de connexions de l’ALB. D’une manière ou de l’autre, vérifier en déclenchant manuellement une interruption avec aws ec2 send-spot-fleet-instance-interruption-notification (ou attendre une naturelle) et en regardant le log d’accès pour des 200 propres pendant le drainage.
Tester le mode d’échec. Utiliser aws fis pour injecter une simulation d’interruption Spot sur la moitié des instances Spot d’un coup, regarder le comportement de la flotte, confirmer que l’ALB ne retourne pas de 5xx pendant le drainage, confirmer que l’ASG lance des remplacements en minutes. C’est ce que vous voulez vraiment savoir avant de faire confiance à la politique en production.

L’avis tranché sur le ratio base/Spot pour un palier web sans état derrière un ALB, avec des AMI raisonnablement chaudes (sous 2 minutes pour être en service) :

30 % de base à la demande est le bon plancher. Perdre tout le Spot d’un coup laisse 30 % du trafic servi par la portion à la demande. Les target groups ALB routent autour des instances manquantes ; la latence monte, les requêtes n’échouent pas.
20 % à la demande au-dessus de la base équilibre coût et résilience au scale-out.
Cinq types d’instances sur trois zones est la diversification minimum — quinze piscines de capacité. Moins que ça et vous pariez sur le fait qu’un petit nombre de piscines restent saines ensemble.
Warmups sous 2 minutes. Si votre AMI prend 5 minutes à démarrer, le préavis de 2 minutes ne suffit pas à lancer un remplacement avant le drainage. Utiliser des warm pools ou augmenter la base à la demande.

La politique d’instances mixtes est un des changements à plus haut ROI disponibles sur un palier sans état. La mise en place prend une demi-heure. L’économie sur la facture est notable dès le premier mois. Le travail consiste à s’assurer que le mode d’échec — un événement régional de capacité retirant la majeure partie de votre Spot — dégrade le service plutôt que de le faire tomber.

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