ALB / ELB : équilibrer le trafic HTTP

À la fin de ce tutoriel, vous aurez un Application Load Balancer en ca-central-1 devant au moins une cible (EC2 ou IP), avec security groups, listener HTTP:80, target group et health checks — et vous saurez situer ALB vs NLB vs CLB pour l’examen Solutions Architect.

Niveau : Intermédiaire · Temps estimé : 60–75 min · Versions testées : ELBv2 / ALB 2026, AWS CLI v2 · Dernière vérification : 2026-09-10 · Region : ca-central-1

← Précédent : Transit Gateway · → Suivant : Auto Scaling + Launch Template · Hub : Démarrer avec AWS

Prérequis

• VPC avec au moins deux subnets publics dans deux AZ (exigence ALB) — étendez VPC ou utilisez le VPC défaut (subnets public multi-AZ)
• Une EC2 Amazon Linux avec un serveur HTTP minimal ou acceptez de créer une cible throwaway
• Profil lab ; budget d’alerte (ALB a un coût horaire — supprimez après le lab)

Coût estimé : ALB ≈ frais horaires + LCU. Lab ≤ 1 h puis delete. Pas de NAT Gateway ici.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1

Ce que nous allons construire

Internet ──► ALB (subnets public AZ-a + AZ-b)
               │ listener :80
               ▼
            Target Group (instance)
               │ health check /
               ▼
            EC2 (Apache/nginx ou python -m http.server)

(Schéma — alt : « ALB multi-AZ vers target group EC2 ».)

Étape 1 — ALB vs NLB vs CLB (examen)

ALB exige des subnets dans ≥ 2 AZ. Health checks HTTP sont L7 (chemin /).

Étape 2 — Préparer réseau et SG

VPC_ID=$(aws ec2 describe-vpcs --filters Name=isDefault,Values=true 
  --query 'Vpcs[0].VpcId' --output text)
# Ou votre lab-vpc si multi-AZ prêt

SUBNETS=$(aws ec2 describe-subnets --filters Name=vpc-id,Values="$VPC_ID" 
  --query 'Subnets[?MapPublicIpOnLaunch==`true`].SubnetId' --output text)
# Il en faut au moins 2 AZ distinctes
echo "$SUBNETS"

SG_ALB=$(aws ec2 create-security-group --group-name lab-alb-sg 
  --description "ALB HTTP" --vpc-id "$VPC_ID" --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG_ALB" 
  --protocol tcp --port 80 --cidr 0.0.0.0/0

SG_APP=$(aws ec2 create-security-group --group-name lab-app-sg 
  --description "App from ALB only" --vpc-id "$VPC_ID" --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG_APP" 
  --protocol tcp --port 80 --source-group "$SG_ALB"

Pattern clé : Internet → SG ALB → SG app (source = SG ALB) — pas 0.0.0.0/0 sur les instances.

Étape 3 — Cible EC2 minimale

AMI_ID=$(aws ssm get-parameters 
  --names /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 
  --query 'Parameters[0].Value' --output text)

SUBNET_ONE=$(echo $SUBNETS | awk '{print $1}')

INSTANCE_ID=$(aws ec2 run-instances 
  --image-id "$AMI_ID" --instance-type t3.micro 
  --subnet-id "$SUBNET_ONE" 
  --security-group-ids "$SG_APP" 
  --iam-instance-profile Name=lab-ec2-profile 
  --user-data '#!/bin/bash
dnf install -y nginx
systemctl enable --now nginx
echo OK-from-$(hostname) > /usr/share/nginx/html/index.html
' 
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=lab-alb-target}]' 
  --query 'Instances[0].InstanceId' --output text)

aws ec2 wait instance-running --instance-ids "$INSTANCE_ID"

Attendez 1–2 min que nginx démarre (user-data). SSM optionnel pour debug.

Étape 4 — Target group

TG_ARN=$(aws elbv2 create-target-group 
  --name lab-tg-web 
  --protocol HTTP --port 80 
  --vpc-id "$VPC_ID" 
  --target-type instance 
  --health-check-path / 
  --health-check-protocol HTTP 
  --matcher HttpCode=200 
  --query 'TargetGroups[0].TargetGroupArn' --output text)

aws elbv2 register-targets --target-group-arn "$TG_ARN" 
  --targets Id="$INSTANCE_ID"

Étape 5 — Créer l’ALB + listener

SUBNET_A=$(echo $SUBNETS | awk '{print $1}')
SUBNET_B=$(echo $SUBNETS | awk '{print $2}')

ALB_ARN=$(aws elbv2 create-load-balancer 
  --name lab-alb-web 
  --type application --scheme internet-facing 
  --subnets "$SUBNET_A" "$SUBNET_B" 
  --security-groups "$SG_ALB" 
  --query 'LoadBalancers[0].LoadBalancerArn' --output text)

aws elbv2 create-listener 
  --load-balancer-arn "$ALB_ARN" 
  --protocol HTTP --port 80 
  --default-actions Type=forward,TargetGroupArn="$TG_ARN"

DNS=$(aws elbv2 describe-load-balancers --load-balancer-arns "$ALB_ARN" 
  --query 'LoadBalancers[0].DNSName' --output text)
echo "http://$DNS/"

Attendez l’état active, puis health healthy :

aws elbv2 describe-target-health --target-group-arn "$TG_ARN"
curl -s "http://$DNS/" 

Étape 6 — Fonctions ALB utiles (aperçu certif)

HTTPS : certificat ACM dans la même Region que l’ALB (≠ CloudFront qui exige us-east-1).

Étape 7 — Vérification

aws elbv2 describe-load-balancers --names lab-alb-web
aws elbv2 describe-target-health --target-group-arn "$TG_ARN"

Checklist : ALB active · ≥2 AZ · listener 80 → TG · cible healthy · curl DNS ALB renvoie le HTML · SG app sans 0.0.0.0/0.

Nettoyage (obligatoire)

LISTENER_ARN=$(aws elbv2 describe-listeners --load-balancer-arn "$ALB_ARN" 
  --query 'Listeners[0].ListenerArn' --output text)
aws elbv2 delete-listener --listener-arn "$LISTENER_ARN"
aws elbv2 delete-load-balancer --load-balancer-arn "$ALB_ARN"
# attendre disparition ENI
sleep 30
aws elbv2 delete-target-group --target-group-arn "$TG_ARN"
aws ec2 terminate-instances --instance-ids "$INSTANCE_ID"
aws ec2 delete-security-group --group-id "$SG_ALB"
aws ec2 delete-security-group --group-id "$SG_APP"

Erreurs fréquentes

Target types : instance vs IP vs Lambda

Health checks Lambda diffèrent ; pour EC2, / en HTTP 200 reste le standard lab.

Connection draining / deregistration delay

Quand une instance quitte le TG (scale-in), l’ALB laisse finir les requêtes en cours pendant le deregistration delay (défaut 300 s — trop long pour un lab, OK en prod). Réduisez en lab si besoin via attributs du target group.

Access logs et métriques CloudWatch

Activez les access logs ALB vers un bucket S3 (préfixe dédié) pour auditer codes HTTP, latences et cibles — utile en prod, optionnel en lab court. Côté CloudWatch, surveillez au minimum :

En ca-central-1, créez le bucket de logs dans la même Region que l’ALB. Pour un lab ≤ 1 h, vous pouvez sauter les access logs et vous contenter de describe-target-health + curl.

Cross-zone load balancing

Sur un ALB, le cross-zone est activé par défaut : chaque nœud ALB peut envoyer du trafic vers des cibles dans toutes les AZ du TG. Sur NLB, le défaut historique diffère — retenez pour l’examen : ALB = cross-zone on. Cela évite qu’une AZ avec peu de cibles soit surchargée si le DNS ALB renvoie davantage vers un nœud.

Idle timeout et en-têtes

Le idle timeout (défaut 60 s) coupe les connexions inactives ; augmentez-le pour des uploads longs ou du WebSocket (avec prudence). L’ALB ajoute X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Port : votre app doit faire confiance à ces en-têtes uniquement si le trafic arrive bien via l’ALB (SG source = SG ALB).

Lab bonus (5–8 min) — règle path-based

Après le listener HTTP:80 par défaut, ajoutez une règle qui forward /api/* vers le même TG (démo) ou un second TG si vous en créez un :

LISTENER_ARN=$(aws elbv2 describe-listeners --load-balancer-arn "$ALB_ARN" 
  --query 'Listeners[0].ListenerArn' --output text)
aws elbv2 create-rule --listener-arn "$LISTENER_ARN" --priority 10 
  --conditions Field=path-pattern,Values='/api/*' 
  --actions Type=forward,TargetGroupArn="$TG_ARN"
aws elbv2 describe-rules --listener-arn "$LISTENER_ARN" 
  --query 'Rules[].{Prio:Priority,Cond:Conditions}'

Objectif : voir qu’un seul ALB route par path (microservices). Supprimez la règle au nettoyage (delete-rule) avant le listener.

Scénario examen classique

« Une application web doit router /static/* vers un TG S3/EC2 et /api/* vers un autre TG, avec TLS terminé sur le load balancer. » → ALB + listener HTTPS (certificat ACM même Region) + règles host/path — pas un NLB (L4) ni un CLB legacy. Si la question insiste sur IP statiques / ultra-faible latence TCP pur → NLB.

Checklist lab anti-facture

1. Minuteur dès create-load-balancer (ALB = coût horaire + LCU).
2. Tags Name=lab-alb-web + DeleteAfter=YYYY-MM-DD.
3. Une seule EC2 cible en lab ; pas de second ALB « pour comparer ».
4. Ordre delete : listener → ALB → attendre ENI → TG → EC2 → SG.
5. Cost Explorer → filtre Elastic Load Balancing le lendemain.

Architecture suivante

L’ALB + Auto Scaling Group (tuto suivant) remplace la cible unique : le TG reste, les instances vont et viennent. Launch Template (plus Launch Configuration).

Quiz (5 questions)

1. Un ALB opère principalement en couche : – A. 4 seulement
– B. 7 (HTTP/HTTPS)
– C. 1

2. Pourquoi ≥ 2 AZ pour un ALB ? – A. Cosmétique
– B. Haute disponibilité du load balancer lui-même
– C. Obligation Free Tier

3. Le SG des instances app devrait autoriser le port 80 depuis : – A. 0.0.0.0/0 toujours
– B. Le security group de l’ALB
– C. Uniquement localhost

4. Un certificat ACM pour un listener HTTPS ALB en ca-central-1 doit être : – A. Toujours demandé en us-east-1
– B. Dans la même Region que l’ALB (ca-central-1)
– C. Uniquement importé depuis Cloudflare

5. Le deregistration delay sert surtout à : – A. Accélérer le scale-in sans égard aux requêtes
– B. Laisser finir les requêtes en cours quand une cible quitte le TG
– C. Remplacer les Security Groups

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

Pour aller plus loin

• Application Load Balancer
• Target groups
• Listener rules
• Access logs ALB
• CloudWatch metrics ELB

Maillage série AWS (P1)