Le health check de l'ALB part de ses propres interfaces (protégées par sg-0a71c3e5f9b2d4068) vers
le port 8080 des instances. Le groupe app-souklmarsa-v2, recopié depuis l'ancien modèle de
l'époque nginx, n'autorise ce groupe que sur le port 80. Les paquets vers 8080 sont donc
silencieusement jetés : d'où Target.Timeout (et non une erreur HTTP), et le 504 servi par l'ALB.
L'application va bien : curl localhost:8080/health répond 200 sur l'instance. Un 404 sur
/health donnerait Target.ResponseCodeMismatch, pas un timeout. La network ACL est celle par défaut
(tout autorisé). Et l'Auto Scaling voit les instances « Healthy » parce qu'il utilise le type de
contrôle EC2, qui ne regarde que l'état de la machine.
Incident résolu
Analyse et correction
Correction : autoriser le groupe de l'ALB sur le port de l'application :
aws ec2 authorize-security-group-ingress --group-id sg-0d58e2a9c4f1b7360 --protocol tcp --port 8080 --source-group sg-0a71c3e5f9b2d4068.
Puis vérifier : aws elbv2 describe-target-health … doit passer à healthy (3 contrôles réussis,
environ 45 s) et curl -I https://www.souklmarsa.ma doit répondre 200. La règle 80, devenue inutile,
peut être retirée ensuite.
Pour que cela ne recommence pas :
- décrire les security groups en infrastructure as code et dériver le port de la règle du port du target group (une seule variable, pas deux recopies) ;
- toujours référencer le security group de l'ALB comme source, jamais 0.0.0.0/0 ;
- vérifier avec VPC Reachability Analyzer (ALB → instance:8080) avant de changer un groupe en production, et basculer d'abord une seule instance ;
- alarme CloudWatch sur
UnHealthyHostCount > 0du target group, et passer le type de contrôle de l'Auto Scaling àELBpour qu'il voie ce que voit le load balancer.