ALB, NLB ou GLB : lequel utiliser et quand

Elastic Load Balancing (ELB) distribue automatiquement le trafic applicatif entrant entre plusieurs cibles : instances EC2, conteneurs, fonctions Lambda ou adresses IP. ELB est un service géré : AWS prend en charge le provisionnement, la mise à l’échelle et la disponibilité de l’équilibreur de charge lui-même dans plusieurs AZ.

AWS propose trois types d’équilibreurs de charge dans la gamme ELB : Application Load Balancer (ALB), Network Load Balancer (NLB) et Gateway Load Balancer (GWLB). Chacun fonctionne à une couche différente du modèle OSI et est optimisé pour des cas d’utilisation différents.

ALB fonctionne à la couche 7 (HTTP/HTTPS) du modèle OSI. Il peut examiner les en-têtes HTTP, les chemins, les chaînes de requête, les noms d’hôte et les cookies afin de prendre des décisions de routage intelligentes. ALB est le choix privilégié pour les applications web, les microservices et les points de terminaison d’API qui nécessitent un routage fondé sur le contenu.

Principales fonctionnalités d’ALB : routage fondé sur le chemin (/api/* vers un groupe cible, /static/* vers un autre), routage fondé sur l’hôte (différents hôtes virtuels vers différents serveurs principaux), routage fondé sur les en-têtes HTTP et les chaînes de requête, prise en charge de WebSocket et prise en charge de HTTP/2. ALB peut router vers des instances EC2, des conteneurs (ECS/EKS), des fonctions Lambda et des adresses IP.

NLB fonctionne à la couche 4 (TCP/UDP/TLS). Il route les paquets en fonction des données du protocole IP sans examiner le contenu de l’application. NLB est conçu pour des performances extrêmes : il traite des millions de demandes par seconde avec une latence extrêmement faible (généralement inférieure à 100 microsecondes).

Principales fonctionnalités de NLB : adresses IP statiques par AZ (une adresse IP Elastic par sous-réseau), transmission TLS transparente (transfert du trafic chiffré sans déchiffrement), conservation de l’adresse IP du client et prise en charge des protocoles UDP (par exemple DNS, RADIUS et les serveurs de jeux). NLB ne peut pas effectuer de routage fondé sur le contenu ni examiner les en-têtes HTTP.

GWLB fonctionne à la couche 3 (couche réseau) et est exclusivement conçu pour déployer, mettre à l’échelle et gérer des appliances réseau virtuelles tierces : pare-feu, systèmes de détection et de prévention des intrusions (IDS/IPS) et systèmes d’inspection approfondie des paquets.

GWLB utilise le protocole GENEVE (port 6081) pour encapsuler le trafic et l’envoyer à votre parc d’appliances. L’appliance inspecte le paquet et le renvoie via le même point de terminaison GWLB. Le trafic circule de manière transparente, sans nécessiter de modification du routage dans le VPC source. Il s’agit du modèle standard pour intégrer une inspection de sécurité centralisée aux flux de trafic des VPC AWS.

Choisissez ALB lorsque :

• Vous avez besoin d’un routage fondé sur le contenu HTTP/HTTPS (chemin, hôte, en-tête, chaîne de requête)
• Votre infrastructure principale comprend des fonctions Lambda ou des conteneurs ECS
• Vous avez besoin de connexions WebSocket ou HTTP/2
• Vous souhaitez intégrer AWS WAF pour assurer la sécurité de l’application web au niveau de l’équilibreur de charge
• Vous créez une architecture de microservices comprenant de nombreux services sur différents chemins d’URL
• Vous avez besoin d’une terminaison SSL/TLS au niveau de l’équilibreur de charge

ALB est la bonne réponse pour la plupart des questions de l’examen SAA-C03 sur l’équilibrage de charge des applications web et des API REST.

Choisissez NLB lorsque :

• Vous avez besoin de performances extrêmes (millions de demandes par seconde, latence inférieure à la milliseconde)
• Vous avez besoin d’adresses IP statiques que les partenaires ou les pare-feu peuvent ajouter à une liste d’autorisation
• Vous devez gérer du trafic UDP (jeux, DNS, RADIUS, IoT)
• Vous souhaitez une transmission TLS transparente sans déchiffrement au niveau de l’équilibreur de charge (chiffrement de bout en bout jusqu’à la cible)
• Vous devez conserver nativement l’adresse IP source du client au niveau TCP
• Vous utilisez AWS PrivateLink pour exposer des services à d’autres VPC ou comptes (NLB est requis pour PrivateLink)

Choisissez GWLB lorsque vous devez :

• Insérer des appliances pare-feu tierces (Palo Alto, Fortinet, Check Point) dans le flux de trafic de votre réseau
• Effectuer une inspection approfondie des paquets au niveau du VPC pour tout le trafic entrant ou sortant
• Mettre à l’échelle horizontalement un parc d’appliances IDS/IPS avec équilibrage de charge automatique

Architecture : le trafic circule du VPC source → point de terminaison GWLB → VPC des appliances (où GWLB distribue le trafic entre les instances d’appliances) → l’appliance renvoie le trafic vers GWLB → GWLB le transfère vers la destination d’origine. La source et la destination ne savent pas qu’une inspection a eu lieu entre les deux.

L’équilibrage de charge entre zones distribue le trafic uniformément entre toutes les cibles enregistrées dans toutes les AZ activées, quelle que soit l’AZ dans laquelle le nœud de l’équilibreur de charge a reçu la demande. Sans équilibrage entre zones, le nœud de chaque AZ distribue uniquement le trafic aux cibles de sa propre AZ.

ALB active l’équilibrage de charge entre zones par défaut, sans coût supplémentaire. NLB désactive l’équilibrage entre zones par défaut : son activation entraîne des frais de transfert de données entre AZ. GWLB désactive également l’équilibrage entre zones par défaut. Activez l’équilibrage entre zones lorsque le nombre de cibles diffère selon les AZ afin d’éviter les points de concentration.

Tableau comparatif rapide pour l’examen :

• Couche OSI : ALB = 7 (HTTP), NLB = 4 (TCP/UDP), GWLB = 3 (IP)
• Protocoles : ALB = HTTP, HTTPS, WebSocket ; NLB = TCP, UDP, TLS ; GWLB = tous les protocoles IP via GENEVE
• IP statique : ALB = non (utilisez le modèle NLB + ALB) ; NLB = oui (1 par AZ) ; GWLB = sans objet
• Intégration à WAF : ALB = oui ; NLB = non ; GWLB = non
• Cible Lambda : ALB = oui ; NLB = non ; GWLB = non
• Drainage des connexions : les trois prennent en charge le délai de désenregistrement

ALB s’intègre nativement à AWS WAF pour une protection régionale (par opposition à WAF sur CloudFront pour une protection périphérique mondiale). En associant une ACL Web WAF à un ALB, vous pouvez filtrer les demandes HTTP avant qu’elles n’atteignent votre application : blocage des injections SQL, XSS, des adresses IP malveillantes connues et des clients abusant de la limitation de débit.

Utilisez ALB + WAF lorsque vous souhaitez effectuer l’inspection de sécurité au niveau de l’équilibreur de charge (par exemple pour protéger des API qui ne sont pas servies via CloudFront). Les ACL Web WAF associées à des ALB doivent se trouver dans la même région que l’ALB et avoir une REGIONAL portée (contrairement à WAF pour CloudFront, qui nécessite une portée CLOUDFRONT dans us-east-1).

AWS PrivateLink utilise NLB pour exposer des services d’un VPC à des consommateurs situés dans d’autres VPC ou comptes AWS, sans nécessiter d’appairage de VPC, de passerelle Internet ou de NAT. Le fournisseur de services crée un NLB devant son service ainsi qu’un service de point de terminaison VPC. Les consommateurs créent dans leur VPC un point de terminaison VPC d’interface qui pointe vers le service.

Le trafic circule sur le réseau privé d’AWS et ne traverse jamais Internet. PrivateLink est le modèle standard utilisé par les fournisseurs SaaS sur AWS et pour exposer des services partagés (par exemple un service de sécurité centralisé) à plusieurs comptes AWS internes.

Testez votre compréhension des concepts AWS Solutions Architect (SAA-C03) abordés dans cette leçon.

Dans cette leçon, vous avez appris qu’ALB route à la couche 7 (HTTP) à l’aide de règles fondées sur le contenu, de l’intégration à WAF et de cibles Lambda, que NLB route à la couche 4 (TCP/UDP) avec des IP statiques et un débit extrême, et que GWLB déploie des appliances réseau virtuelles à la couche 3 à l’aide de GENEVE. Faites correspondre l’équilibreur de charge aux exigences en matière de protocoles et de fonctionnalités. Ensuite, nous étudierons les groupes cibles et les vérifications d’état.