Cours Aws

4.42 Le load balancer classique CLB (V1)

Dans ce lab, on crée un Classic Load Balancer (CLB v1). Ce type de load balancer supporte TCP en couche 4 ainsi que HTTP et HTTPS en couche 7, avec des health checks basés sur ces mêmes protocoles. L'objectif : un client envoie une requête HTTP sur le port 80 du CLB, qui la redirige en interne vers une instance EC2 backend.

Depuis la console EC2, on commence par vérifier que le serveur web d'une instance existante répond bien. On va ensuite dans le menu Load Balancers, on clique sur Create Load Balancer et on choisit le Classic Load Balancer (les autres options proposées sont l'ALB et le NLB). On le nomme, on garde le VPC par défaut et on l'expose à Internet — sinon il ne serait pas joignable depuis l'extérieur.

Configuration pas à pas

  • Listener : HTTP en entrée sur le port 80, HTTP vers le port 80 des instances.
  • Security Group : créer mon-premier-clb-sg qui ouvre le port 80 à 0.0.0.0/0.
  • Health Check : protocole HTTP sur le port 80, chemin index.html, délai 5 s, interval 30 s, seuil d'échec 2, seuil de bonne santé 10.
  • Targets : ajouter la première instance EC2 backend.
  • Tags : nommer le load balancer puis créer.

Une fois le CLB en service, AWS fournit un nom DNS public. En l'ouvrant dans le navigateur, on tombe sur la page servie par l'instance derrière. Pour vérifier l'équilibrage, on impose ensuite que les utilisateurs ne puissent atteindre l'EC2 que via le load balancer : on modifie le groupe de sécurité de l'instance pour autoriser le port 80 uniquement depuis le SG du CLB. L'accès direct à l'IP de l'instance ne fonctionne alors plus, tandis que le DNS du CLB continue de répondre.

On ajoute ensuite deux instances supplémentaires via Launch More Like This (en gardant le même profil sauf pour la zone de disponibilité de la troisième, déployée dans une autre AZ pour montrer la répartition multi-AZ). Dans le CLB, on les enregistre via Edit Instances. Au début, elles sont OutOfService le temps de passer les health checks, puis basculent InService. En rafraîchissant la page via le DNS du CLB, l'adresse IP renvoyée change à chaque fois : le CLB dispatche bien le trafic et équilibre la charge entre les trois instances EC2.

En résumé

Ce cours démontre la création d'un Elastic Load Balancer classique (CLB) version 1 sur AWS pour distribuer le trafic HTTP entre plusieurs instances EC2. Vous apprendrez à configurer les listeners (port d'écoute et de redirection), les health checks, les groupes de sécurité, et comment restreindre l'accès direct aux instances en le forçant à passer par le load balancer. Le CLB vérifie continuellement la santé des instances et bascule le trafic automatiquement vers celles opérationnelles.

Points clés

  • Le CLB (Elastic Load Balancer classique) supporte les protocoles TCP, HTTP et HTTPS et opère à la couche 7 du modèle OSI
  • Configuration des listeners : définir le port d'écoute du CLB (ex: 80) et le port de redirection vers les instances EC2 (ex: 80)
  • Health checks : vérifier la santé des instances via HTTP sur index.html avec intervalle de test (10 sec), timeout (5 sec) et seuil de défaillance (2 erreurs = retrait de la rotation)
  • Restriction d'accès : modifier les groupes de sécurité des instances pour n'autoriser les connexions que depuis le CLB, pas directement depuis Internet
  • Répartition de charge : le CLB distribue les requêtes entre toutes les instances saines, ce qui change l'adresse IP à chaque requête client
  • Ajout dynamique d'instances : vous pouvez ajouter ou retirer des instances du CLB sans interruption de service, elles passent par les health checks avant d'être actives

Questions fréquentes

Quelle est la différence entre un CLB (load balancer classique) et les autres types de load balancers AWS ?

Le CLB est le type le plus ancien et supporte les protocoles TCP, HTTP et HTTPS. Il convient aux applications simples. Les ALB (Application Load Balancer) offrent un routage plus avancé basé sur le contenu HTTP, tandis que le NLB (Network Load Balancer) gère des millions de requêtes par seconde pour les applications haute performance. Le CLB reste approprié pour les besoins de charge classiques.

Que se passe-t-il si une instance devient unhealthy selon les health checks du CLB ?

Si une instance échoue à répondre au health check (défini par le seuil de défaillance, ex: 2 erreurs consécutives), le CLB la retire automatiquement de la rotation. Le trafic cesse d'être dirigé vers cette instance et est redistribué vers les instances saines. Lorsque l'instance redevient healthy, elle réintègre la rotation.

Pourquoi faut-il modifier le groupe de sécurité des instances pour restreindre l'accès ?

Par défaut, les instances EC2 acceptent les connexions directes depuis Internet. Pour forcer tout le trafic à passer par le CLB et bénéficier de la répartition de charge, vous modifiez les règles du groupe de sécurité pour n'autoriser les connexions HTTP/HTTPS qu'en provenance du groupe de sécurité du CLB, pas directement depuis Internet.