Aller au contenu

AWS Mis à jour le 2026-01-16

Règles de listener ALB — routage par hôte et par chemin à grande échelle

Routage par hôte pour les sous-domaines multi-locataires, par chemin pour SPA + API, target groups pondérés pour canary, réponse fixe 503 pour la maintenance. Et le plafond de 100 règles qui vous bloque au 90e client.

Une SaaS multi-locataire est lancée avec acme.app.exemple.com, globex.app.exemple.com, et un certificat ACM avec wildcard. Les 30 premiers clients obtiennent chacun une règle de listener ALB d’une ligne, routant leur sous-domaine vers le même target group. Au 90e client, le déploiement échoue — TooManyRulesException. L’équipe découvre ce jour-là qu’ALB plafonne à 100 règles par listener par défaut, et que le pattern une-règle-par-locataire a une piste d’environ 95 locataires. La correction n’est pas « augmenter le quota » — AWS l’augmentera, mais le coût sous-jacent est qu’ALB évalue chaque règle sur chaque requête, et un listener de 500 règles est plus lent et plus difficile à opérer qu’un listener de 50 règles. Le pattern consiste à utiliser les emplacements de règle pour les décisions de routage, pas pour l’identité du locataire, et à pousser l’identité du locataire dans l’application ou une couche en aval.

Ce qui se passe

Les règles de listener ALB sont évaluées par ordre de priorité contre chaque requête entrante. Chaque règle peut comporter jusqu’à cinq conditions (hôte, chemin, en-tête, chaîne de requête, IP source, méthode HTTP, version HTTP) et une parmi une poignée d’actions : transférer vers un target group, rediriger, retourner une réponse fixe, authentifier via Cognito ou OIDC, ou corriger la requête et transférer.

Le quota de compte ALB par défaut est de 100 règles par listener. La limite stricte (après une augmentation de quota) est de 200 règles par listener. Chaque règle consomme des ressources au moment de la requête, et le listener devient plus difficile à comprendre à mesure que le nombre croît. Les patterns qui passent à l’échelle :

  • Routage par hôte correspond à l’en-tête Host. Bon pour une SaaS multi-locataire où chaque locataire a un sous-domaine mais l’application est la même — une règle avec une condition d’hôte avec wildcard transfère *.app.exemple.com vers le target group de l’application, et l’application lit le sous-domaine pour déterminer le locataire.

  • Routage par chemin correspond au chemin URL. Bon pour un domaine unique avec plusieurs services derrière — /api/* vers un target group, /static/* vers un autre, / vers le fallback SPA. Les règles de chemin sont la façon dont une séparation SPA + API vit derrière un seul ALB.

  • Target groups pondérés permettent à une règle de transférer vers plusieurs target groups avec des poids différents — 95 % vers le target group stable et 5 % vers le canary. Utile pour des déploiements graduels sans changement DNS.

  • Actions de réponse fixe retournent une réponse HTTP statique sans transférer vers aucune cible. L’usage classique est une page 503 mode maintenance : une règle en priorité 1 avec la condition header X-Maintenance-Mode = on retournant une réponse fixe 503, et un interrupteur d’exécution qui ajoute l’en-tête à toutes les requêtes quand la maintenance est activée.

  • Actions de redirection retournent un 301 ou un 302 sans transférer. Bon pour les migrations d’URL hérités ou pour le HTTP-vers-HTTPS au niveau du listener.

Le plafond de 100 règles mord le plus fort le pattern routage-par-hôte-par-locataire. Patterns qui survivent à l’échelle :

  1. Une règle wildcard, résolution du locataire au niveau applicatif. *.app.exemple.com est une règle. L’application lit l’en-tête Host et résout le locataire. Passe à l’échelle de millions de locataires.

  2. Par règle pour le tier ou la région. Une règle par catégorie (entreprise vs standard, US vs EU), et l’application gère le routage par locataire dans la catégorie. Reste sous 20 règles au total.

  3. Deux ALB par région. Certaines charges méritent un ALB pour les locataires face client et un deuxième pour l’admin interne ou le trafic partenaire. Deux listeners, deux budgets de 100 règles chacun.

  4. CloudFront devant ALB. CloudFront peut router par hôte ou par chemin vers différentes origines, et les limites de CloudFront sont plus élevées (ou vous pouvez utiliser Lambda@Edge pour une logique arbitraire). Le pattern : CloudFront gère la décision de routage par locataire ou par région, puis transfère vers un petit nombre d’ALB.

Comment vérifier

Lister les règles actuelles sur un listener :

LISTENER_ARN=$(aws elbv2 describe-listeners \
  --load-balancer-arn arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/prod-alb/abc \
  --query 'Listeners[?Port==`443`].ListenerArn' --output text)

aws elbv2 describe-rules --listener-arn "$LISTENER_ARN" \
  --query 'Rules[].{Priority:Priority,Conditions:Conditions[].Field,Actions:Actions[].Type}' \
  --output table

Compter combien de règles un listener utilise, utile dans une alarme :

aws elbv2 describe-rules --listener-arn "$LISTENER_ARN" \
  --query 'length(Rules)'

Une alarme CloudWatch sur ActiveConnectionCount par règle n’est pas native, mais RuleEvaluations est disponible — si une règle voit des ordres de grandeur plus de trafic que les autres, vous avez une règle chaude qui mérite peut-être son propre listener ou son propre target group avec plus de capacité.

Pour les règles wildcard sur l’hôte, le wildcard est uniquement sur le label le plus à gauche. *.app.exemple.com correspond à acme.app.exemple.com mais pas à app.exemple.com (vous avez besoin d’une règle séparée pour le domaine nu) ni à deep.acme.app.exemple.com. Confirmez contre l’en-tête Host réel que le client envoie.

Ajouter un canary à 5 % de poids :

aws elbv2 modify-rule \
  --rule-arn "$RULE_ARN" \
  --actions '[{
    "Type": "forward",
    "ForwardConfig": {
      "TargetGroups": [
        {"TargetGroupArn": "arn:aws:...stable", "Weight": 95},
        {"TargetGroupArn": "arn:aws:...canary", "Weight": 5}
      ]
    }
  }]'

Vérifier que le forward pondéré a retourné la bonne configuration :

aws elbv2 describe-rules --rule-arns "$RULE_ARN" \
  --query 'Rules[].Actions[].ForwardConfig.TargetGroups'

Le pattern mode maintenance, déployé une fois :

# Règle en priorité 1, évaluée en premier, retournant 503 quand l'en-tête est défini
aws elbv2 create-rule \
  --listener-arn "$LISTENER_ARN" \
  --priority 1 \
  --conditions '[{"Field":"http-header","HttpHeaderConfig":{"HttpHeaderName":"X-Maintenance-Mode","Values":["on"]}}]' \
  --actions '[{
    "Type": "fixed-response",
    "FixedResponseConfig": {
      "ContentType": "text/html",
      "StatusCode": "503",
      "MessageBody": "<html><body><h1>Maintenance en cours</h1></body></html>"
    }
  }]'

Ensuite la fenêtre de maintenance est un simple basculement d’en-tête à une couche CDN ou WAF, pas un changement de règle ALB dans le chemin chaud.

La correction

Le runbook pour un listener qui approche le plafond de règles :

  1. Auditer les règles existantes. Imprimez-les avec leur compte de conditions. Les règles qui correspondent à host = client-unique.app.exemple.com sont les candidates à la fusion.

  2. Identifier les dimensions de routage. Si chaque règle par locataire transfère vers le même target group, la règle est de l’identité de locataire pure et appartient à l’application. Si différents locataires transfèrent vers différents target groups (premium vs standard, US vs EU), la dimension est tier ou région — ce sont les règles qui valent la peine d’être gardées.

  3. Fusionner les règles d’hôte en wildcards par dimension. *.enterprise.app.exemple.com vers le target group entreprise, *.app.exemple.com vers le target group standard, dans cet ordre de priorité. L’identité du locataire passe par l’en-tête Host vers l’application.

  4. Pousser la logique par locataire dans l’application. L’application lit Host, cherche le locataire dans une base de données, et applique le comportement spécifique au locataire. L’ALB n’est plus l’endroit où les locataires sont définis.

  5. Plafonner le compte de règles du listener par processus, pas seulement par quota. Une vérification de pull request qui échoue si le compte de règles dépasse 50 force l’équipe à réfléchir sur la nécessité de chaque nouvelle règle. Le quota est le plafond ; le budget est plus bas.

Trois garde-fous à tenir :

Écarts de priorité. Numérotez les règles par incréments de 10 (10, 20, 30) afin que les insertions ultérieures ne nécessitent pas de tout renuméroter. ALB ne renumérote pas automatiquement.

Discipline d’action par défaut. L’action par défaut du listener est le repli lorsqu’aucune règle ne correspond. Définissez-la sur une réponse fixe 404 ou un target group qui retourne un 404 générique, pas vers l’application principale. Une règle mal configurée qui ne correspond pas ne doit pas router silencieusement vers la production.

Réponse fixe plutôt que redirection. Une redirection est un aller-retour et un risque de sécurité si la cible est paramétrée. Une réponse fixe est un paquet et ne peut pas être redirigée ailleurs par une chaîne de requête fabriquée.

Pour les déploiements canary derrière ALB et le tuning de vérifications de santé connexe, voir Tuning de vérifications de santé pour cibles SaaS. Pour la décision ALB vs NLB quand les intégrations partenaires ont besoin d’IP statiques, voir ALB vs NLB vs GWLB.

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 listener a accumulé une règle par locataire, commencez par une consultation d’infrastructure.