Retour aux articles • CLOUD • Mis à jour en 2026 • 5 min de lecture

AWS Elastic Load Balancing : NLB (L4) vs ALB (L7)

Comprendre les différences d'architecture entre AWS Network Load Balancer (Couche 4 Hyperplane) et Application Load Balancer (Couche 7), leur supervision CloudWatch/Athena.

AWS Elastic Load Balancing : NLB (L4) vs ALB (L7)
Documentation officielle AWS ELB : docs.aws.amazon.com/elasticloadbalancing
Contrôleur Kubernetes officiel : github.com/kubernetes-sigs/aws-load-balancer-controller • Architecture : L4 Hyperplane (NLB) & L7 Proxy/WAF (ALB)

Pour compléter mon triptyque sur les répartiteurs de charge cloud après Azure et GCP, examinons comment Amazon Web Services (AWS) segmente sa gamme Elastic Load Balancing (ELB) entre la couche 4 et la couche 7.

Sur AWS, l’époque du vieux Classic Load Balancer (CLB) est révolue au profit de deux composants spécialisés : le Network Load Balancer (NLB) en couche 4 et l’Application Load Balancer (ALB) en couche 7.

Comparatif architectural AWS Elastic Load Balancing : Network Load Balancer (L4 Hyperplane) vs Application Load Balancer (L7 Proxy & WAF)

Architecture & Flux : AWS Elastic Load Balancing : NLB (L4) vs A

1. AWS Network Load Balancer (NLB : Couche 4)

Propulsé par le plan de données virtuel AWS Hyperplane, le NLB opère au niveau du flux de transport (TCP, UDP, TLS) :

  • Performances extrêmes : capable d’absorber des dizaines de millions de requêtes par seconde dès la première seconde (pas besoin de pre-warming) avec une latence de l’ordre de 100 à 200 microsecondes ;
  • Adresses IP statiques par Zone de Disponibilité (AZ) : contrairement à l’ALB dont les adresses IP changent dynamiquement, un NLB possède une IP fixe (ou une Elastic IP) par zone, indispensable lorsque des partenaires B2B filtrent les flux sortants par liste blanche d’IP ;
  • Exposition de services via AWS PrivateLink : c’est la brique obligatoire pour publier un service interne vers d’autres comptes AWS sans routage VPC Peering.

2. AWS Application Load Balancer (ALB : Couche 7)

L’ALB agit comme un véritable proxy inverse HTTP/HTTPS de niveau 7 :

  • Routage avancé : évaluation des règles sur le Host header, le chemin d’URL, la méthode HTTP, les query strings ou même l’adresse IP CIDR source ;
  • Authentification déportée : un ALB peut authentifier directement les utilisateurs via OIDC ou Amazon Cognito avant même de transmettre la requête au conteneur back-end ;
  • Cibles hétérogènes : il peut router /api/v1 vers des pods EKS en mode IP (awsvpc), /legacy vers des instances EC2 et /webhook directement vers une fonction AWS Lambda.

3. Supervision : CloudWatch Metrics & Access Logs dans S3 / Athena

Sur AWS, les métriques clés à surveiller dans Grafana (via la datasource CloudWatch) sont :

  • Sur ALB : TargetResponseTime, HTTPCode_ELB_5XX_Count (erreur du LB lui-même), HTTPCode_Target_5XX_Count (erreur de l’application) et UnHealthyHostCount ;
  • Sur NLB : ActiveFlowCount, NewFlowCount, TCP_Target_Reset_Count.

Pour analyser finement les logs d’accès stockés dans S3, une table Amazon Athena permet de requêter en SQL les requêtes les plus lentes :

SELECT target_ip, request_url, target_processing_time, elb_status_code
FROM alb_access_logs
WHERE target_processing_time > 1.0
ORDER BY target_processing_time DESC
LIMIT 50;

MàJ 2026 Gateway Load Balancer (GWLB), VPC Lattice et AWS LBC v2.8+

En 2026, l’architecture réseau AWS autour du Load Balancing s’appuie sur quatre évolutions majeures :

CritèreAWS NLB (Couche 4)AWS ALB (Couche 7)AWS Gateway LB (GWLB : L3/GENEVE)
Usage principalDébit massif TCP/UDP, IP fixes, PrivateLinkWeb, API REST/gRPC, WAF, Auth OIDCInsertion transparente d’appliances sécurité (Fortigate, Palo Alto, Suricata)
Sécurité Zonal ShiftSupport natif ARC Zonal ShiftSupport natif ARC Zonal ShiftInspection inline multi-VPC

Ce qu’il faut retenir en 2026

  1. AWS Load Balancer Controller (TargetGroupBinding) sur EKS : en couplant Karpenter et PodReadinessGates, les nouveaux pods Kubernetes reçoivent du trafic depuis l’ALB/NLB sans aucune perte de paquet lors des rolling updates.
  2. Amazon VPC Lattice : pour les communications Est-Ouest (service-à-service entre plusieurs VPC et comptes AWS), VPC Lattice remplace souvent avantageusement les empilements d’ALB internes en gérant nativement le routage L7 et l’authentification IAM (SigV4).
  3. Isolation de zone automatique (Zonal Autoshift) : en cas de dégradation d’une Availability Zone AWS, vous pouvez désormais évacuer instantanément 100 % du trafic NLB/ALB hors de la zone impactée via Route 53 Application Recovery Controller.

Hardening Maximal AWS ALB / NLB (AWS CLI & Terraform)

Selon le AWS Well-Architected Security Pillar [1] et la documentation officielle Elastic Load Balancing [2], un Application Load Balancer (ALB) de production doit impérativement :

  1. Rejeter les en-têtes HTTP malformés (routing.http.drop_invalid_header_fields.enabled = true) pour bloquer les attaques HTTP Desync / Request Smuggling.
  2. Imposer la politique de négociation ELBSecurityPolicy-TLS13-1-2-Res-2021-06 (TLS 1.3 + Forward Secrecy).
  3. S’associer à une AWS WAFv2 WebACL (AWSManagedRulesCommonRuleSet + AWSManagedRulesKnownBadInputsRuleSet) [3].

1. Commandes AWS CLI : Hardening ALB & Protection Desync

# 1. Activer la protection contre la suppression accidentelle et le rejet d'en-têtes HTTP invalides
aws elbv2 modify-load-balancer-attributes \
  --load-balancer-arn arn:aws:elasticloadbalancing:eu-west-3:123456789012:loadbalancer/app/prod-alb/50dc6c495c0c9188 \
  --attributes \
    Key=deletion_protection.enabled,Value=true \
    Key=routing.http.drop_invalid_header_fields.enabled,Value=true \
    Key=routing.http.desync_mitigation_mode,Value=strictest \
    Key=access_logs.s3.enabled,Value=true \
    Key=access_logs.s3.bucket,Value=prod-alb-security-logs

# 2. Forcer la politique TLS 1.3 stricte sur le Listener HTTPS (443)
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:eu-west-3:123456789012:listener/app/prod-alb/50dc6c495c0c9188/f2f7dc8efc522ab2 \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-Res-2021-06
Animation exécution CLI dans le terminal

2. Terraform HCL : AWS ALB Hardened + AWS WAFv2

resource "aws_lb" "prod_alb_hardened" {
  name                       = "prod-alb-hardened"
  internal                   = false
  load_balancer_type         = "application"
  security_groups            = [aws_security_group.alb_sg.id]
  subnets                    = var.public_subnet_ids
  enable_deletion_protection = true
  drop_invalid_header_fields = true
  desync_mitigation_mode     = "strictest"

  access_logs {
    bucket  = aws_s3_bucket.alb_logs.id
    prefix  = "alb-access"
    enabled = true
  }
}

resource "aws_lb_listener" "https_strict" {
  load_balancer_arn = aws_lb.prod_alb_hardened.arn
  port              = 443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-Res-2021-06"
  certificate_arn   = var.acm_certificate_arn

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.app_tg.arn
  }
}

resource "aws_wafv2_web_acl_association" "alb_waf_bind" {
  resource_arn = aws_lb.prod_alb_hardened.arn
  web_acl_arn  = aws_wafv2_web_acl.prod_waf.arn
}

Sources