SW BBANG F

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 Type Ce qui est vérifié Quand utiliser EC2 (défaut) État hyperviseur + réseau de l'instance Workloads sans load balancer ELB Health check HTTP/TCP du target group Applications derrière un ALB/NLB Custom Health Check Signal externe via set-instance-health Logique 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 :...

Vous regardez votre Target Group et toutes les instances affichent Healthy — pourtant l'ALB retourne des 502 à vos utilisateurs. C'est l'un des scénarios les plus frustrants en production : le health check passe, mais le trafic réel échoue. Le problème n'est pas la disponibilité de l'instance, c'est la nature de la réponse HTTP que l'application renvoie à l'ALB. TL;DR — Diagnostic Rapide ALB 502 Cause Signal Observable Couche Réponse HTTP invalide ou malformée access_log ALB : 502 , target_status_code: - Application Connexion fermée prématurément par la cible target_status_code: - ou vide TCP/Application Désalignement keep-alive (timeout) 502 intermittents, pas de log d'erreur applicatif Connexion Réponse trop lente (idle timeout dépassé) target_processing_time proche de 60s Timing Mauvais protocole cible (HTTP vs HTTPS) Erreur TLS dans les logs cible Protocole ...