ASG Health Checks : pourquoi vos instances sont terminées alors qu'elles tournent

Vous regardez la console EC2 et vos instances Auto Scaling affichent l'état InService côté EC2, mais l'ASG les termine quand même en boucle. Le réflexe immédiat est de passer le type de health check de EC2 à ELB — mais sans comprendre ce que chaque mode vérifie réellement, vous risquez soit de masquer le vrai problème, soit d'aggraver la situation.

TL;DR — Auto Scaling Group Health Checks en un coup d'œil

TypeCe qui est vérifiéQuand utiliser
EC2 (défaut)État hyperviseur + réseau de l'instanceWorkloads sans load balancer
ELBHealth check HTTP/TCP du target groupApplications derrière un ALB/NLB
Custom Health CheckSignal externe via set-instance-healthLogique métier ou monitoring tiers

Comment fonctionnent les Auto Scaling Group Health Checks

L'ASG ne surveille pas votre application directement. Il interroge une ou plusieurs sources de santé et prend une décision binaire : Healthy ou Unhealthy. Une instance marquée Unhealthy est immédiatement éligible à la terminaison, sauf si un Instance Protection ou un Standby est actif.

Le mode EC2

C'est le comportement par défaut. L'ASG interroge le statut système et le statut instance exposés par l'API EC2 (describe-instance-status). Ces deux checks couvrent la couche hyperviseur et le réseau AWS sous-jacent. Si l'instance répond aux checks EC2 — même si votre application est plantée, en boucle de démarrage, ou écoute sur le mauvais port — l'ASG la considère saine.

Le mode ELB

Quand vous activez le health check ELB, l'ASG consulte l'état de santé que le load balancer maintient pour chaque cible dans le target group. Ce sont les mêmes checks HTTP/TCP configurés dans votre target group — chemin, port, seuils de succès et d'échec. Une instance peut être running côté EC2 et unhealthy côté ELB si votre endpoint de santé retourne un 5xx ou ne répond pas dans le délai imparti.

Penser au check EC2 comme au voyant moteur d'une voiture : il vous dit que le moteur tourne, pas que vous pouvez rouler. Le check ELB, c'est un mécanicien qui démarre réellement le véhicule et vérifie que les roues tournent.

La grace period — le détail qui piège tout le monde

L'ASG applique un Health Check Grace Period après le lancement d'une instance. Pendant cette fenêtre, les résultats des health checks sont ignorés. La valeur par défaut est 300 secondes. Si votre application met 4 minutes à démarrer et que votre grace period est à 180 secondes, l'ASG va terminer l'instance avant même qu'elle soit prête — en boucle infinie.

graph TD A["Instance lancée par l'ASG"] --> B["Grace Period active (checks ignorés)"] B --> C{"Grace Period expirée ?"} C -- Non --> B C -- Oui --> D["Health Check actif (EC2 et/ou ELB)"] D --> E{"Instance saine ?"} E -- Oui --> F["InService Trafic acheminé"] E -- Non --> G["Marquée Unhealthy"] G --> H["Terminaison par l'ASG"] H --> A
  1. Launch : l'ASG démarre une nouvelle instance suite à un scaling event ou au remplacement d'une instance unhealthy.
  2. Grace Period : les health checks sont suspendus. L'instance démarre, le système d'exploitation boot, l'application s'initialise.
  3. Health Check actif : à l'expiration de la grace period, l'ASG commence à évaluer l'état de santé selon le type configuré.
  4. Unhealthy détecté : si le check échoue, l'instance passe en état Unhealthy et est marquée pour terminaison.
  5. Terminaison & remplacement : l'ASG termine l'instance et en lance une nouvelle — recommençant le cycle.

Diagnostic : pourquoi votre ASG termine des instances 'saines'

Avant de changer quoi que ce soit, identifiez la couche exacte qui déclare l'instance unhealthy. Changer le type de health check sans ce diagnostic revient à changer de thermomètre sans traiter la fièvre.

Étape 1 — Vérifier l'historique des activités de l'ASG

L'historique des activités contient la raison exacte de chaque terminaison. C'est votre premier arrêt obligatoire — les logs applicatifs ne vous diront pas pourquoi l'ASG a agi, seul cet historique le fait.

aws autoscaling describe-scaling-activities \
  --auto-scaling-group-name nom-de-votre-asg \
  --region us-east-1 \
  --query 'Activities[?StatusCode==`Failed` || contains(Description, `Terminating`)].[ActivityId,Description,Cause,StatusMessage]' \
  --output table

Cherchez dans le champ Cause la mention du type de health check qui a déclenché la terminaison : 'an instance was found to be in poor health' avec la source EC2 ou ELB.

Étape 2 — Vérifier l'état de santé actuel de chaque instance dans l'ASG

Cette commande vous montre ce que l'ASG voit en ce moment pour chaque instance — pas ce que vous voyez dans la console EC2. La différence entre HealthStatus ici et l'état EC2 vous indique si le problème vient du check ELB ou d'ailleurs.

aws autoscaling describe-auto-scaling-instances \
  --region us-east-1 \
  --query 'AutoScalingInstances[?AutoScalingGroupName==`nom-de-votre-asg`].[InstanceId,HealthStatus,LifecycleState,HealthCheckType]' \
  --output table

Étape 3 — Vérifier l'état des cibles dans le target group

Si le type de health check est ELB (ou si vous envisagez de le passer à ELB), l'état réel des cibles dans le target group est la source de vérité. Une instance peut être InService dans l'ASG et unhealthy dans le target group simultanément — c'est précisément ce que le mode ELB va exposer.

aws elbv2 describe-target-health \
  --target-group-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/mon-target-group/abcdef1234567890 \
  --region us-east-1 \
  --query 'TargetHealthDescriptions[*].[Target.Id,TargetHealth.State,TargetHealth.Reason,TargetHealth.Description]' \
  --output table

Si vous voyez des instances en état unhealthy avec la raison Target.ResponseCodeMismatch ou Target.Timeout, le problème est applicatif — et passer en mode ELB va effectivement déclencher des terminaisons que le mode EC2 ignorait.

Étape 4 — Vérifier la grace period configurée

C'est le coupable le plus fréquent dans les cycles de terminaison en boucle sur des instances qui semblent saines. Comparez la valeur configurée avec le temps de démarrage réel de votre application.

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names nom-de-votre-asg \
  --region us-east-1 \
  --query 'AutoScalingGroups[0].[HealthCheckType,HealthCheckGracePeriod,MinSize,MaxSize,DesiredCapacity]' \
  --output table
graph TD START["Instance terminée par l'ASG"] --> Q1{"Check EC2 OK ?"} Q1 -- Non --> FIX1["Problème instance : investiguer status checks EC2"] Q1 -- Oui --> Q2{"Check ELB OK ?"} Q2 -- Non --> Q3{"Application démarrée ?"} Q3 -- Non --> FIX2["Grace Period trop courte : augmenter health-check-grace-period"] Q3 -- Oui --> FIX3["Problème applicatif : endpoint santé, port, code HTTP"] Q2 -- Oui --> Q4{"Signal set-instance-health ?"} Q4 -- Oui --> FIX4["Identifier la source du signal externe"] Q4 -- Non --> FIX5["Vérifier l'historique des activités ASG"]
  1. Check EC2 OK, ELB Unhealthy : l'application ne répond pas correctement. Problème applicatif à corriger avant de changer le type de health check.
  2. Check EC2 Unhealthy : problème au niveau de l'instance elle-même (réseau, hyperviseur). Investiguer les logs système et les status checks EC2.
  3. Grace Period trop courte : augmenter la grace period pour correspondre au temps de démarrage réel de l'application.
  4. Custom Health Check signal : un appel externe à set-instance-health marque l'instance unhealthy. Identifier la source du signal.

Passer de EC2 à ELB : ce que ça change réellement

Activer le health check ELB sur un ASG existant ne remplace pas le check EC2 — il s'y ajoute. L'ASG considère une instance unhealthy si l'un ou l'autre des checks échoue. C'est un point critique que beaucoup ratent en lisant la documentation en diagonale.

Conséquence directe : si votre application a un endpoint de santé qui retourne 200 de manière fiable, passer en mode ELB vous donne une surveillance applicative réelle. Mais si votre endpoint de santé est mal configuré, trop strict, ou si votre application met du temps à démarrer, vous allez déclencher exactement le cycle de terminaison en boucle que vous essayiez de résoudre.

Modifier le type de health check

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name nom-de-votre-asg \
  --health-check-type ELB \
  --health-check-grace-period 300 \
  --region us-east-1

Ajuster la grace period

Mesurez le temps de démarrage de votre application en conditions réelles — pas en local. Ajoutez une marge de 20 à 30% pour absorber les variations. Une grace period trop longue retarde simplement la détection des instances réellement défaillantes, mais une grace period trop courte crée des cycles de terminaison inutiles.

aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name nom-de-votre-asg \
  --health-check-grace-period 600 \
  --region us-east-1

Le piège classique : symptôme de terminaison en boucle

Voici le pattern exact que l'on voit régulièrement en production. L'ASG est configuré en mode EC2. Les instances démarrent, passent les checks EC2, mais l'application met 7 minutes à initialiser sa connexion à RDS et à charger son cache. La grace period est à 300 secondes.

Le diagnostic initial pointe vers le type de health check : 'les instances semblent saines mais sont terminées, il faut passer en ELB'. On passe en mode ELB. Le cycle s'accélère. Pourquoi ? Parce que le check ELB détecte maintenant que l'application ne répond pas pendant ses 7 minutes de démarrage, et la grace period de 5 minutes expire avant que l'application soit prête.

La vraie cause : grace period insuffisante. La vraie solution : augmenter la grace period à 600 secondes minimum, puis activer le check ELB pour surveiller l'état applicatif réel une fois l'instance prête. Le type de health check n'était pas le problème — il révélait simplement un problème de timing qui existait déjà.

Changer le type de health check sans ajuster la grace period, c'est comme installer un détecteur de fumée plus sensible dans une cuisine sans améliorer la ventilation — vous aurez plus d'alertes, pas moins de problèmes.

IAM : permissions nécessaires pour le diagnostic et la modification

Les commandes de diagnostic et de modification ci-dessus nécessitent les permissions suivantes. Appliquez-les au rôle ou à l'utilisateur utilisé pour l'administration de l'ASG.

🔽 Politique IAM minimale pour la gestion des health checks ASG 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ASGHealthCheckDiagnostic",
      "Effect": "Allow",
      "Action": [
        "autoscaling:DescribeAutoScalingGroups",
        "autoscaling:DescribeAutoScalingInstances",
        "autoscaling:DescribeScalingActivities"
      ],
      "Resource": "*"
    },
    {
      "Sid": "ASGHealthCheckModify",
      "Effect": "Allow",
      "Action": [
        "autoscaling:UpdateAutoScalingGroup",
        "autoscaling:SetInstanceHealth"
      ],
      "Resource": "arn:aws:autoscaling:us-east-1:123456789012:autoScalingGroup:*:autoScalingGroupName/nom-de-votre-asg"
    },
    {
      "Sid": "ELBTargetHealthDiagnostic",
      "Effect": "Allow",
      "Action": [
        "elasticloadbalancing:DescribeTargetHealth",
        "elasticloadbalancing:DescribeTargetGroups"
      ],
      "Resource": "*"
    }
  ]
}

Note : DescribeAutoScalingGroups, DescribeAutoScalingInstances, et DescribeScalingActivities requièrent "Resource": "*" — ces actions Read/List ne supportent pas la restriction par ARN de ressource selon la Service Authorization Reference.

Récapitulatif et prochaines étapes — Auto Scaling Group Health Checks

Le type de health check EC2 vs ELB n'est pas un simple interrupteur à basculer. C'est une décision architecturale qui dépend de votre topologie (avec ou sans load balancer), de la fiabilité de votre endpoint de santé, et du temps de démarrage réel de votre application.

Ordre d'action recommandé :

  1. Consultez l'historique des activités ASG pour identifier la source exacte de la terminaison.
  2. Vérifiez l'état des cibles dans le target group si un ELB est attaché.
  3. Mesurez le temps de démarrage applicatif réel et ajustez la grace period en conséquence.
  4. Passez en mode ELB uniquement si votre endpoint de santé est fiable et que la grace period est correctement dimensionnée.

Ressources officielles : AWS Auto Scaling Health Checks — ALB Target Group Health Checks.

Glossaire

TermeDéfinition
Health Check Grace PeriodFenêtre de temps après le lancement d'une instance pendant laquelle l'ASG ignore les résultats des health checks.
InServiceÉtat du cycle de vie ASG indiquant qu'une instance est active et soumise aux health checks.
Target GroupGroupe de cibles (instances, IPs, Lambda) auquel un load balancer achemine le trafic, avec ses propres health checks configurables.
set-instance-healthAPI ASG permettant à un système externe de forcer l'état de santé d'une instance à Healthy ou Unhealthy.
Lifecycle HookMécanisme ASG permettant de suspendre une instance dans un état de transition (Pending:Wait, Terminating:Wait) pour exécuter des actions personnalisées.

Related Posts

Commentaires

Enregistrer un commentaire

Posts les plus consultés de ce blog

Groupes IAM AWS : Pourquoi Attacher les Politiques aux Groupes Plutôt qu'aux Utilisateurs

Vous venez d'intégrer trois nouveaux développeurs dans votre équipe. Vous créez leurs utilisateurs IAM, puis vous commencez à attacher les politiques une par une à chaque compte — et c'est là que le problème commence. Six mois plus tard, un développeur change de rôle, et personne ne sait exactement quelles permissions il possède ni pourquoi. TL;DR — Groupes IAM vs. Politiques Directes Critère Politiques directes sur l'utilisateur Politiques via Groupe IAM Auditabilité Difficile — chaque utilisateur est une île Claire — une politique, un groupe, N utilisateurs Gestion à l'échelle O(N) opérations pour N utilisateurs O(1) — modifier le groupe suffit Risque d'erreur Élevé — oubli fréquent lors des offboardings Faible — retirer l'utilisateur du groupe suffit Conformité (moindre...
Lire la suite

LSI vs GSI dans DynamoDB : choisir le bon index secondaire

Vous avez modélisé votre table DynamoDB autour d'une clé de partition, puis le jour où un nouveau cas d'usage apparaît — filtrer les commandes par statut, rechercher les utilisateurs par email — vous réalisez que la clé primaire ne suffit plus. C'est exactement là que les index secondaires entrent en jeu, et le choix entre un LSI et un GSI a des conséquences directes sur la cohérence des lectures, la capacité de la table et les contraintes de conception. TL;DR — LSI vs GSI dans DynamoDB Critère LSI (Local Secondary Index) GSI (Global Secondary Index) Clé de partition Identique à la table de base N'importe quel attribut Clé de tri Attribut différent de la table N'importe quel attribut (optionnel) Création Uniquement à la création de la table À tout moment Cohérence des lectures Fortement cohérente possible Éventuellement cohérente uniquement Capacité Partagée avec la table de base ...
Lire la suite

NAT Gateway vs NAT Instance : Quelle solution choisir pour vos instances privées ?

Vous venez de déployer vos premières instances EC2 dans un sous-réseau privé et vous réalisez qu'elles ne peuvent pas télécharger les mises à jour système — aucune route vers internet. La question qui suit est systématique : faut-il provisionner un NAT Gateway managé ou lancer une instance EC2 configurée comme NAT Instance ? Ce choix impacte directement la disponibilité, les coûts opérationnels et la charge de maintenance de votre infrastructure. TL;DR — NAT Gateway vs NAT Instance Critère NAT Gateway NAT Instance Gestion Entièrement managé par AWS Vous gérez l'OS, les patches, la HA Disponibilité Haute disponibilité dans une AZ Dépend de votre configuration Bande passante Scalabilité automatique jusqu'aux limites du service Limitée par le type d'instance EC2 Modèle de coût ...
Lire la suite