ALB vs NLB vs GWLB — choisir le bon load balancer du premier coup

Une équipe plateforme choisit ALB pour tout parce que le premier service livré était une API HTTPS et qu’ALB fonctionnait simplement. Deux ans plus tard, elle a un service gRPC qui exige HTTP/2 de bout en bout sans la réécriture de requêtes d’ALB, une intégration partenaire qui requiert une adresse IP source statique, et un audit de sécurité qui exige que le trafic soit miroité à travers un pare-feu virtuel. L’équipe gère trois contournements — un listener TCP sur ALB qui perd la moitié des fonctions L7, une passerelle NAT liée à une seule Elastic IP qui se brise chaque fois que l’instance sous-jacente est remplacée, et une règle de mirroring manuelle sur chaque VPC. Les trois problèmes découlent du mauvais choix de load balancer en deuxième semaine. La correction consiste à savoir lequel choisir pour quelle charge de travail, et à repérer le mauvais choix par défaut avant qu’il ne s’accumule.

Ce qui se passe

Les trois types de load balancer vivent à des couches OSI différentes et règlent des problèmes différents :

• Application Load Balancer (ALB) — Couche 7. Parle HTTP/1.1, HTTP/2, gRPC, WebSockets. Route selon l’hôte, le chemin, l’en-tête, la chaîne de requête, l’IP source, la méthode et la version HTTP. Termine TLS. S’authentifie avec Cognito ou OIDC. Intégration WAF. Émet des vérifications de santé par cible contre un chemin HTTP. Journalise chaque requête avec une granularité inférieure à la seconde. Le prix est qu’ALB réécrit la requête — il définit X-Forwarded-For, ajoute ses propres en-têtes, et décide quelle cible reçoit quelle connexion au niveau HTTP, pas TCP.

• Network Load Balancer (NLB) — Couche 4. Transfère TCP brut, UDP ou TLS (passthrough). N’inspecte pas la charge utile. Peut préserver l’IP source du client de bout en bout (pas de X-Forwarded-For parce qu’il n’y a pas de HTTP). Soutient les IP statiques — une Elastic IP par zone de disponibilité, allouée une fois, jamais tournée. Gère des millions de connexions par seconde avec faible latence. Le prix est que NLB ne voit pas HTTP — pas de routage par chemin, pas de routage d’en-tête d’hôte, pas de WAF par requête. Les vérifications de santé sont au niveau TCP par défaut ; les vérifications HTTP sont possibles mais la décision de routage reste par connexion, pas par requête.

• Gateway Load Balancer (GWLB) — Couche 3, en quelque sorte. Conçu pour une seule tâche : insérer des appareils réseau tiers (pare-feux, IDS/IPS, inspection de paquets) dans le chemin de trafic de façon transparente. Il utilise l’encapsulation GENEVE pour transférer chaque paquet vers une flotte d’appareils et ramener la réponse, sans que l’appareil ait besoin d’une IP publique ni d’être inline dans la table de routage. Le fournisseur d’appareil commercialise une image « GWLB-ready » ; le client câble des endpoints et des tables de routage. Le prix est que GWLB n’est utile que si vous déployez ce genre d’appareil. Pour du trafic applicatif entre vos services, GWLB n’est pas le bon outil.

Le mauvais choix par défaut que les équipes font est ALB. Il parle HTTP, c’est celui de tous les tutoriels, il est sélectionné parce qu’il est familier. Puis six mois plus tard, la charge de travail le dépasse — les clients gRPC échouent parce qu’ALB fait HTTP/2 vers le LB mais redescend en HTTP/1.1 vers la cible sauf configuration contraire ; un partenaire veut une liste blanche d’IP source et ALB n’a pas d’IP statiques ; un processeur de paiement requiert TLS mutuel vers un endpoint spécifique et ALB ne peut pas faire de mTLS passthrough.

Le deuxième mauvais choix par défaut est NLB pour un service qui est fondamentalement HTTP. NLB ne sait pas ce qu’est un chemin. Vous finissez par exploiter une couche nginx derrière NLB pour le routage par chemin, puis vous vous demandez pourquoi vous avez acheté un load balancer alors que vous avez de toute façon une flotte nginx.

Comment vérifier

La matrice de décision, distillée :

Le pivot le plus fréquent que nous voyons : une app HTTPS face client qui a commencé sur ALB et qui a maintenant besoin d’IP statiques pour une intégration partenaire. Deux patterns fonctionnent :

Chaîne NLB → ALB. NLB est la couche publique avec Elastic IP ; elle transfère vers ALB en tant que cible par adresse IP. ALB fait le routage L7. Le partenaire met les IP statiques du NLB en liste blanche. Le coût est deux load balancers dans le chemin, et l’IP source visible par ALB est celle du NLB, pas celle du client (utilisez le protocole proxy ou X-Forwarded-For du côté client).

Global Accelerator → ALB. Global Accelerator fournit deux IP anycast statiques et transfère vers l’ALB. Les IP ne changent jamais, même si l’ALB est remplacé. C’est le pattern le plus simple lorsque la seule exigence est « donnez-moi deux IP stables ».

L’autre pivot à connaître : gRPC sur NLB versus ALB. NLB-en-TCP fonctionne pour gRPC parce que NLB n’interfère pas avec la connexion — le client et le serveur négocient HTTP/2 de bout en bout. ALB supporte gRPC explicitement avec le protocole de target group gRPC ; le routage est par requête, ce qui permet les déploiements canary au niveau du service gRPC. Les deux fonctionnent. ALB gagne quand vous voulez le WAF sur le service gRPC ou un routage par méthode. NLB gagne quand vous voulez la plus faible latence possible ou que le service gRPC est interne et n’a pas besoin de fonctions L7.

La correction

La procédure pour un nouveau service :

1. Commencer en L7. Si le service parle HTTP/HTTPS/gRPC et n’a pas de contrainte ferme qui force L4, choisissez ALB par défaut. Listez les fonctions L7 que vous voulez — routage par chemin, par hôte, WAF, auth OIDC, journalisation des requêtes — et ALB vous les donne toutes.

2. Promouvoir en L4 (NLB) quand l’une des trois contraintes apparaît :

   • Vous avez besoin d’IP statiques qui survivent au remplacement du load balancer (listes blanches partenaires, règles pare-feu sur site).
   • Vous avez besoin d’un protocole non-HTTP (UDP, TCP brut, passthrough TLS pour mTLS).
   • Vous avez besoin de la plus faible latence possible pour un service qui ne bénéficie pas des fonctions L7.

3. Promouvoir en chaîne L7 + L4 (NLB → ALB) quand vous avez besoin d’IP statiques ET de fonctions L7. Assez fréquent pour que ce soit le pattern par défaut pour les SaaS à intégration partenaire.

4. Recourir à GWLB seulement quand vous déployez une flotte d’appareils tiers — pare-feu virtuel, inspecteur de paquets, outil DPI. GWLB n’est pas un outil pour du trafic applicatif entre vos propres services.

5. Documenter la décision. Un service dont le choix d’ALB est « nous avions besoin de routage par chemin et de WAF » est facile à migrer plus tard. Un service dont le choix d’ALB est « valeur par défaut du module Terraform » est celui qui mord à l’an deux.

L’autre règle que nous tenons : ne pas changer de type de load balancer en cours de vie sauf si vous avez une défaillance spécifique que le type courant ne peut pas adresser. Chaque changement est un changement DNS, une reconfiguration de target group, et une fenêtre de trafic à double cerveau. Le coût d’exploiter le mauvais load balancer est réel mais borné. Le coût d’exploiter deux load balancers parce que personne n’a décommissionné l’ancien est pire.

Pour plus de détails sur les patterns de routage spécifiques à ALB à grande échelle, voir Règles de listener ALB — routage par hôte et par chemin. Pour le pattern d’IP statique NLB, voir Pattern d’IP statique NLB pour listes blanches partenaires.

Stack Harbor conçoit les topologies ALB + NLB et le modèle d’opération autour dans le cadre de l’onboarding Gestion AWS et des Environnements infogérés en continu. Si votre configuration de load balancer accumule une décennie de drapeaux de fonctionnalité, commencez par une consultation d’infrastructure.