Introduction aux ELB
Posté le 15 mars 2025 • 6 min de lecture • 1 177 motsDans une architecture scalable et résiliente, la répartition du trafic est essentielle pour assurer une haute disponibilité. C’est précisément le rôle des Elastic Load Balancers (ELB) dans AWS.
I. Introduction aux Load Balancers dans AWS
Un Elastic Load Balancers (ELB) agit comme un répartiteur de charge, distribuant automatiquement le trafic entrant à travers plusieurs ressources cibles, telles que les instances EC2, les containers ou les adresses IP.
Cette fonctionnalité est un pilier de la conception d’applications tolérantes aux pannes et hautement disponibles dans le cloud. AWS propose trois types d’ELB adaptés à différents cas d’usage, chacun avec ses spécificités.
II. Fonctionnement général des ELB
Lorsqu’un utilisateur accède à votre application, sa requête est d’abord traitée par l’ELB. Celui-ci examine les règles de routage définies et choisit une cible disponible selon les règles de distribution de charge (round robin, IP hash, etc.).
L’ELB surveille la santé des cibles à travers des vérifications périodiques (health checks) configurables. Si une instance est considérée comme non saine, elle est temporairement retirée de la rotation.
Illustration du fonctionnement : ELB, Listeners et Target Groups
Le diagramme ci-dessous illustre de manière structurée le fonctionnement logique d’un Elastic Load Balancer (ELB) dans AWS, en mettant en évidence la relation hiérarchique entre les composants clés : le Load Balancer, les Listeners, et les Target Groups.
À gauche, on trouve le Load Balancer, qui sert de point d’entrée unique pour toutes les requêtes entrantes issues des utilisateurs ou d’applications clientes. Il agit comme un répartiteur centralisé. Juste à sa droite, les Listeners sont représentés : ce sont des entités configurées pour écouter un port spécifique (comme 80 ou 443) avec un protocole (HTTP, HTTPS, TCP, etc.). Chaque listener peut être associé à une ou plusieurs règles de routage définies selon des conditions précises (chemin, host, en-tête, etc.). Ensuite, le trafic est redirigé vers les Target Groups, qui regroupent un ensemble de cibles (EC2, ECS, IPs) recevant les requêtes si elles sont en bon état de fonctionnement. Chaque cible au sein d’un Target Group est surveillée par des health checks, garantissant que seules les instances saines reçoivent du trafic. Cette représentation visuelle met en lumière la séparation des responsabilités entre routage, écoute du trafic, et exécution, assurant une haute disponibilité, une mise à l’échelle dynamique et une gestion fine du trafic dans les architectures cloud AWS modernes.
Autres fonctionnalités clés :
- SSL/TLS termination : gestion du chiffrement au niveau du load balancer.
- Sticky sessions : conservation de la session utilisateur sur une même cible.
- Autoscaling : intégration native avec les groupes Auto Scaling.
A. SSL/TLS termination : sécurité et performance
Les Elastic Load Balancers, en particulier les Application Load Balancers (ALB) et les Network Load Balancers (NLB), peuvent gérer la terminaison SSL/TLS en déchiffrant le trafic HTTPS directement au niveau du load balancer. Cela évite d’imposer la charge de chiffrement/déchiffrement aux instances backend, améliorant ainsi les performances applicatives. Par exemple, dans un site e-commerce à fort trafic, l’ALB peut être configuré avec un certificat ACM (AWS Certificate Manager), permettant une gestion centralisée et automatisée des certificats. Pour renforcer la sécurité, il est également possible de re-chiffrer le trafic entre le load balancer et les cibles, assurant un chiffrement bout-en-bout.
B. Sticky sessions : continuité d’expérience utilisateur
Dans certains cas, il est essentiel qu’un utilisateur reste connecté à la même instance backend tout au long de sa session — par exemple dans les systèmes de panier d’achat ou les portails d’administration. Les ELB permettent d’activer les sticky sessions (session affinities) via des cookies d’application ou générés par le load balancer (cookie AWSALB). Lorsqu’un client effectue une première requête, le cookie est renvoyé et stocké dans son navigateur, permettant aux requêtes suivantes d’être redirigées vers la même cible. Cela garantit une expérience fluide, notamment lorsque les applications ne sont pas conçues pour être stateless.
C. Auto Scaling : élasticité intelligente
Les ELB sont conçus pour fonctionner en parfaite synergie avec les groupes Auto Scaling, permettant d’adapter dynamiquement le nombre d’instances EC2 en fonction de la charge. Lorsqu’un pic de trafic est détecté, Auto Scaling peut ajouter de nouvelles instances ; l’ELB les inscrit automatiquement dans son groupe cible après vérification de leur état de santé. Inversement, les instances sous-utilisées peuvent être retirées en douceur. Cette combinaison garantit une haute disponibilité sans sur-provisionnement, tout en optimisant les coûts. Par exemple, une API REST déployée derrière un ALB avec Auto Scaling peut répondre à des pics de trafic imprévus (soldes, campagne marketing) sans temps d’arrêt.
III. Types d’Elastic Load Balancer
AWS propose trois types principaux d’ELB :
A. Application Load Balancer (ALB)
Spécialisé dans le routage HTTP/HTTPS, l’ALB est conçu pour les applications web modernes. Il supporte le routage basé sur le contenu, les en-têtes, les chemins d’URL, et l’intégration avec les containers ECS/EKS.
B. Network Load Balancer (NLB)
Optimisé pour la basse latence et le haut débit, le NLB fonctionne au niveau TCP. Idéal pour les applications nécessitant une grande performance réseau ou utilisant des protocoles non-HTTP.
C. Gateway Load Balancer (GWLB)
Permet d’insérer facilement des appliances de sécurité tierces dans votre trafic réseau. Fonctionne au niveau L3 (IP) et facilite le service chaining pour inspection ou filtrage du trafic.
IV. Comparatif des ELB : tableau synthétique
| Caractéristique | ALB | NLB | GWLB |
|---|---|---|---|
| Niveau OSI | 7 (Application) | 4 (Transport - TCP/UDP) | 3 (Réseau - IP) |
| Protocoles supportés | HTTP, HTTPS | TCP, UDP, TLS | IP |
| Routage avancé | Oui (path, header, host, etc.) | Non | Non |
| Intégration ECS/EKS | Oui | Oui | Non |
| Performances | Moyennes à élevées | Très élevées | Élevées |
| Cas d’usage typique | Appli Web, API REST | Base de données, VoIP | Inspection réseau, firewall |
V. Cas d’usage concrets
Exemple 1 : Application web avec microservices
Un site e-commerce utilise un ALB pour router les requêtes :
/produitsvers le service produit/paniervers le service panier/paiementvers un service tiers avec authentification SSL
L’ALB permet de gérer facilement les règles de routage tout en intégrant les containers ECS.
Exemple 2 : Application financière à faible latence
Une plateforme de trading en temps réel utilise un NLB pour ses connexions TCP entrantes. Le NLB fournit des IP statiques et permet une latence minimale critique dans ce secteur.
Exemple 3 : Sécurité et filtrage réseau
Une entreprise déploie un GWLB devant un cluster de pare-feux. Il permet d’insérer dynamiquement ces appliances sans modifier les architectures existantes.
VI. Bonnes pratiques de déploiement
Voici quelques recommandations pour un usage optimal des ELB sur AWS :
- Choisissez le bon type de load balancer selon votre protocole et vos besoins de performances.
- Configurez des health checks efficaces pour éviter que du trafic n’arrive sur des instances défectueuses.
- Utilisez les groupes cibles dynamiques, notamment avec des services comme Auto Scaling ou ECS.
- Activez les logs d’accès (ALB et NLB) pour audit et debugging.
- Pour les applications sensibles, combinez un WAF (Web Application Firewall) avec un ALB.
Conclusion
Les Elastic Load Balancers sont une brique essentielle des architectures AWS modernes. Bien configurés, ils améliorent la disponibilité, la sécurité et les performances de vos applications. Choisir le bon ELB et en comprendre le fonctionnement permet d’exploiter au mieux les capacités de scalabilité natives du cloud AWS.