0Pricing
AWS Solutions Architect · Leçon

Règles d’écoute et routage fondé sur les chemins

Rédigez des règles d’écoute sur l’ALB pour acheminer les requêtes vers différents groupes cibles selon les en-têtes d’hôte, les modèles de chemin ou les chaînes de requête.

Règles d’écoute et routage fondé sur les chemins est une leçon AWS Solutions Architect gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage AWS Solutions Architect, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours AWS Solutions Architect comprend 4 leçons au total.

Explication des écouteurs ALB

Un écouteur ALB est un processus qui vérifie les demandes de connexion à l'aide d'un protocole et d'un port que vous indiquez (par exemple, HTTP sur le port 80 ou HTTPS sur le port 443). Chaque écouteur possède une ou plusieurs règles qui déterminent où transférer les requêtes en fonction de leur contenu.

Un écouteur doit comporter une règle par défaut (l'action générale appliquée lorsqu'aucune autre règle ne correspond) et peut comporter jusqu'à 100 règles supplémentaires. Les règles sont évaluées par ordre de priorité (le numéro le plus bas correspond à la priorité la plus élevée). Lorsqu'une requête correspond à la condition d'une règle, l'action correspondante est appliquée et les règles suivantes ne sont pas évaluées.

# Create an HTTP listener on port 80
aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789:loadbalancer/app/my-alb/abc123 \
  --protocol HTTP \
  --port 80 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/default-tg/def456

Conditions des règles

Les règles d'écoute mettent en correspondance les requêtes selon des conditions. Vous pouvez combiner plusieurs conditions dans une même règle (toutes les conditions doivent correspondre pour que la règle s'applique). Types de conditions disponibles :

  • host-header : correspond à l'en-tête HTTP Host (par exemple, api.example.com)
  • path-pattern : correspond au chemin URL (par exemple, /api/*, /images/*.jpg)
  • http-header : correspond à tout nom d'en-tête HTTP et à tout modèle de valeur
  • http-request-method : correspond aux méthodes HTTP (GET, POST, DELETE, etc.)
  • query-string : correspond aux paires clé-valeur de la chaîne de requête
  • source-ip : correspond aux plages CIDR d'adresses IP client

Routage basé sur le chemin

Le routage basé sur le chemin dirige les requêtes vers différents groupes cibles en fonction du chemin URL. Il s'agit du modèle de routage le plus courant pour les microservices placés derrière un seul ALB. Exemple de règles sur un ALB :

  • Le chemin est /api/* → groupe cible : api-service
  • Le chemin est /images/* → groupe cible : image-processor
  • Le chemin est /admin/* → groupe cible : admin-app
  • Par défaut → groupe cible : frontend-app

Cela permet à un seul ALB de placer en frontal plusieurs services distincts sans nécessiter plusieurs équilibreurs de charge, ce qui réduit les coûts et la complexité DNS.

# Create a path-based routing rule
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 10 \
  --conditions Field=path-pattern,Values='/api/*' \
  --actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/api-service/xyz789

Routage basé sur l'hôte

Le routage basé sur l'hôte achemine les requêtes en fonction de l'en-tête HTTP Host, ce qui permet de servir plusieurs noms de domaine (hôtes virtuels) depuis un seul ALB. Exemple :

  • L'hôte est api.example.com → groupe cible api-service
  • L'hôte est admin.example.com → groupe cible admin-app
  • L'hôte est www.example.com → groupe cible frontend

Chaque nom de domaine possède un enregistrement CNAME ou ALIAS pointant vers le nom DNS du même ALB, mais l'ALB achemine chacun vers le serveur principal approprié en fonction de l'en-tête d'hôte. Le routage basé sur l'hôte est idéal pour les logiciels SaaS multilocataires ou les applications monolithiques divisées en microservices.

# Create a host-based routing rule
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 5 \
  --conditions '[{"Field":"host-header","HostHeaderConfig":{"Values":["api.example.com"]}}]' \
  --actions '[{"Type":"forward","TargetGroupArn":"arn:aws:elasticloadbalancing:us-east-1:123456789:targetgroup/api-service/xyz789"}]'

Actions des règles

Lorsque les conditions d'une règle correspondent, l'ALB exécute l'une des actions suivantes :

  • forward : transfère la requête vers un ou plusieurs groupes cibles (avec des pondérations facultatives)
  • redirect : renvoie une redirection HTTP (301 ou 302) vers une nouvelle URL ; utile pour les redirections de HTTP vers HTTPS
  • fixed-response : renvoie une réponse HTTP statique avec un code d'état, un type de contenu et un corps indiqués — utile pour les pages de maintenance ou les réponses simples de vérification de l'état
  • authenticate-cognito : authentifie les utilisateurs via un groupe d'utilisateurs Cognito avant le transfert
  • authenticate-oidc : authentifie les utilisateurs via tout fournisseur d'identité compatible avec OIDC
# Create a redirect rule: HTTP to HTTPS
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/http80 \
  --priority 1 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/*"]}}]' \
  --actions '[{"Type":"redirect","RedirectConfig":{"Protocol":"HTTPS","Port":"443","StatusCode":"HTTP_301"}}]'

Modèle de redirection de HTTP vers HTTPS

Le modèle de règle d'écoute le plus courant consiste à rediriger HTTP vers HTTPS :

  1. Créez un écouteur HTTP sur le port 80 avec une règle : redirigez tout le trafic (/*) vers HTTPS avec un code d'état 301
  2. Créez un écouteur HTTPS sur le port 443 avec vos règles de routage réelles pointant vers les groupes cibles

Ainsi, les utilisateurs qui saisissent http:// ou suivent d'anciens liens HTTP sont redirigés de manière transparente vers HTTPS, sans aucune modification au niveau de l'application. La redirection est entièrement gérée au niveau de l'équilibreur de charge.

Action de réponse fixe

L'action de réponse fixe renvoie une réponse HTTP statique depuis l'ALB sans transférer la requête vers une cible. Utilisez-la pour :

  • renvoyer une page de maintenance 503 pour certains chemins pendant une opération de maintenance
  • fournir un point de terminaison léger de vérification de l'état directement depuis l'ALB (renvoie instantanément 200 OK sans surcharge du serveur principal)
  • bloquer certains chemins avec une réponse 403 Forbidden

Les réponses fixes sont utiles pour retirer temporairement des chemins du service sans modifier le code de l'application ni effectuer de nouveau déploiement, en ajustant dynamiquement les règles d'écoute.

# Return 503 maintenance page for a specific path
aws elbv2 create-rule \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --priority 20 \
  --conditions '[{"Field":"path-pattern","PathPatternConfig":{"Values":["/checkout/*"]}}]' \
  --actions '[{"Type":"fixed-response","FixedResponseConfig":{"StatusCode":"503","ContentType":"text/html","MessageBody":"<h1>Maintenance</h1>"}}]'

Authentification ALB avec Cognito

L'action authenticate-cognito de l'ALB s'intègre aux groupes d'utilisateurs Amazon Cognito afin de gérer l'authentification des utilisateurs avant de transférer les requêtes vers votre application. Lorsqu'un utilisateur non authentifié atteint une règle d'écoute protégée, l'ALB le redirige vers l'interface hébergée par Cognito pour se connecter. Après une authentification réussie, l'ALB définit un cookie chiffré et transfère la requête avec des en-têtes contenant l'identité de l'utilisateur.

Cela décharge entièrement votre application de la logique d'authentification. Votre serveur principal reçoit les en-têtes X-Amzn-Oidc-Identity, X-Amzn-Oidc-Data et X-Amzn-Oidc-Access-Token contenant les revendications de l'utilisateur authentifié.

Routage basé sur la chaîne de requête et les en-têtes

Les règles de l’écouteur ALB peuvent effectuer le routage en fonction des paramètres de chaîne de requête et des en-têtes HTTP, ce qui permet un routage précis des requêtes :

  • Router les clients mobiles en détectant l’en-tête User-Agent: *Mobile* vers un serveur principal optimisé pour les appareils mobiles
  • Router les requêtes API premium en vérifiant l’en-tête personnalisé X-API-Tier: premium vers un groupe cible plus rapide
  • Router les variantes d’un test A/B en lisant le paramètre de chaîne de requête ?variant=beta

Le routage basé sur les en-têtes permet d’implémenter des indicateurs de fonctionnalité et de répartir le trafic au niveau de l’infrastructure, sans modifier le code de l’application.

Priorité des règles et ordre d’évaluation

Les règles sont évaluées par ordre croissant de priorité. Les numéros de priorité les plus faibles sont évalués en premier. L’action de la première règle correspondante est appliquée et aucune autre règle n’est évaluée. La règle par défaut n’a pas de numéro de priorité et est toujours évaluée en dernier, comme règle générale.

Bonne pratique : attribuez des numéros de priorité par incréments de 10 (10, 20, 30...) plutôt que des entiers consécutifs. Vous pourrez ainsi insérer de nouvelles règles entre celles qui existent déjà sans devoir les renuméroter. Les règles plus spécifiques (par exemple, chemin + en-tête d’hôte) doivent avoir des numéros plus faibles (et donc une priorité plus élevée) que les règles générales.

# List rules for a listener (shows priorities)
aws elbv2 describe-rules \
  --listener-arn arn:aws:elasticloadbalancing:us-east-1:123456789:listener/app/my-alb/abc123/lis456 \
  --query 'Rules[*].{Priority:Priority,Conditions:Conditions[0].Field,Actions:Actions[0].Type}' \
  --output table

Règles d’écouteur pour les microservices

Un seul ALB peut être placé devant une plateforme complète de microservices à l’aide de règles d’écouteur. Voici un exemple concret combinant les trois types de conditions :

  • Priorité 10 : Host=api.example.com + Path=/v2/* → groupe cible api-v2
  • Priorité 20 : Host=api.example.com + Path=/v1/* → groupe cible api-v1
  • Priorité 30 : Host=auth.example.com → groupe cible auth-service
  • Priorité 40 : Host=www.example.com + Path=/static/* → redirection CloudFront
  • Par défaut : Host=www.example.com → groupe cible frontend

Cette conception réduit les coûts en supprimant le besoin d’utiliser un équilibreur de charge distinct pour chaque service.

Vérification rapide

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Récapitulatif de la leçon

Dans cette leçon, vous avez appris que : les règles d’écouteur acheminent les requêtes en fonction de l’hôte, du chemin, des en-têtes, des méthodes et des chaînes de requête ; les règles sont évaluées par ordre de priorité, la première correspondance étant retenue ; et les actions comprennent la transmission, la redirection, la réponse fixe et l’authentification Cognito. Le routage basé sur le chemin et l’hôte permet à un seul ALB d’être placé devant plusieurs microservices. Nous allons maintenant étudier la terminaison SSL et les sessions persistantes.

Questions Fréquemment Posées

La leçon « Règles d’écoute et routage fondé sur les chemins » est-elle gratuite ?

Oui — le texte complet de « Règles d’écoute et routage fondé sur les chemins » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours AWS Solutions Architect, passe à CoddyKit PRO. Le cours AWS Solutions Architect comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Règles d’écoute et routage fondé sur les chemins » ?

Rédigez des règles d’écoute sur l’ALB pour acheminer les requêtes vers différents groupes cibles selon les en-têtes d’hôte, les modèles de chemin ou les chaînes de requête. Tu pratiques AWS Solutions Architect avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer AWS Solutions Architect ?

Aucune expérience préalable n'est requise. AWS Solutions Architect sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Règles d’écoute et routage fondé sur les chemins » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon AWS Solutions Architect ?

Oui. Chaque leçon AWS Solutions Architect inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. ALB, NLB ou GLB : lequel utiliser et quand
  2. Groupes cibles et vérifications de l’état
  3. Règles d’écoute et routage fondé sur les chemins
  4. Terminaison SSL et sessions persistantes
← Retour à AWS Solutions Architect