Écouteurs pour vos Application Load Balancers

Un écouteur est un processus qui vérifie les demandes de connexion, en utilisant le protocole et le port que vous avez configurés. Avant de commencer à utiliser votre Application Load Balancer, vous devez ajouter au moins un écouteur. Si votre équilibreur de charge ne possède aucun écouteur, il ne peut pas recevoir le trafic des clients. Les règles que vous définissez pour vos écouteurs déterminent la manière dont l'équilibreur de charge achemine les demandes vers les cibles que vous enregistrez, telles que les instances EC2.

Configuration des écouteurs

Les écouteurs prennent en charge les protocoles et ports suivants :

Vous pouvez utiliser un écouteur HTTPS pour confier le travail de chiffrement et de déchiffrement à votre équilibreur de charge afin que vos applications puissent se concentrer sur leur logique métier. Si le protocole d'écoute est HTTPS, vous devez déployer au moins un certificat de serveur SSL sur l'écouteur. Pour plus d’informations, consultez Création d'un écouteur HTTPS pour votre Application Load Balancer.

Si vous devez vous assurer que les cibles déchiffrent le trafic HTTPS plutôt que l'équilibreur de charge, vous pouvez créer un Network Load Balancer avec un écouteur TCP sur le port 443. Avec un écouteur TCP, l'équilibreur de charge transmet le trafic chiffré aux cibles sans le déchiffrer. Pour plus d'informations, veuillez consulter le Guide de l'utilisateur pour les Network Load Balancers.

Les équilibreurs de charge d'application fournissent un support natif pour WebSockets. Vous pouvez mettre à niveau une connexion HTTP/1.1 existante vers une connexion WebSocket (wsouwss) en utilisant une mise à niveau de connexion HTTP. Lorsque vous effectuez une mise à niveau, la connexion TCP utilisée pour les demandes (vers l'équilibreur de charge ainsi que vers la cible) devient une WebSocket connexion permanente entre le client et la cible via l'équilibreur de charge. Vous pouvez utiliser WebSockets à la fois les écouteurs HTTP et HTTPS. Les options que vous choisissez pour votre écouteur s'appliquent aux WebSocket connexions ainsi qu'au trafic HTTP. Pour plus d'informations, consultez Comment fonctionne le WebSocket protocole dans le manuel Amazon CloudFront Developer Guide.

Les Application Load Balancers assurent un support natif pour HTTP/2 avec des écouteurs HTTPS. Vous pouvez envoyer jusqu'à 128 demandes en parallèle à l'aide d'une connexion HTTP/2. Vous pouvez utiliser la version du protocole pour envoyer la demande aux cibles à l'aide du protocole HTTP/2. Pour plus d’informations, consultez Version du protocole. Etant donné que HTTP/2 utilise les connexions front-end plus efficacement, vous constaterez peut-être moins de connexions entre les clients et l'équilibreur de charge. Vous ne pouvez pas utiliser la fonction de serveur push de HTTP/2.

Pour plus d'informations, consultez Demande de routage dans le Guide de l'utilisateur Elastic Load Balancing.

Règles d'un écouteur

Chaque écouteur possède une action par défaut, également appelée règle par défaut. La règle par défaut ne peut pas être supprimée et est toujours exécutée en dernier. Des règles supplémentaires peuvent être créées et se composent d'une priorité, d'une ou plusieurs actions et d'une ou plusieurs conditions. Vous pouvez ajouter ou modifier des règles à tout moment. Pour plus d’informations, consultez Modification d'une règle.

Règles par défaut

Lorsque vous créez un écouteur, vous définissez des actions pour la règle par défaut. Les règles par défaut ne peuvent pas avoir de conditions. Si aucune condition des règles d'un écouteur n'est satisfaite, l'action spécifiée pour la règle par défaut est effectuée.

Vous trouverez ci-dessous un exemple de règle par défaut telle qu'elle apparaît dans la console :

Priorité de la règle

Chaque règle a une priorité. Les règles sont évaluées par ordre de priorité, de la valeur la plus basse à la valeur la plus haute. La règle par défaut est évaluée en dernier. Vous pouvez modifier la priorité d'une règle personnalisée à tout moment. Vous ne pouvez pas modifier la priorité de la règle par défaut. Pour plus d’informations, consultez Priorité d'une règle d'actualisation.

Actions de règle

Chaque action de règle a un type, une priorité et les informations requises pour effectuer l'action. Pour plus d’informations, consultez Types d'actions de règle.

Conditions de règle

Chaque condition de règle comporte un type et des informations de configuration. Lorsque les conditions d'une règle sont satisfaites, ses actions sont effectuées. Pour plus d’informations, consultez Types de conditions de règle.

Types d'actions de règle

Les types d'action suivants pour une règle d'écouteur sont pris en charge :

L'action ayant la priorité la plus basse est exécutée en premier. Chaque règle doit comprendre exactement l’une des actions suivantes : forward, redirect ou fixed-response, et ce doit être la dernière action à effectuer.

Si la version du protocole est gRPC ou HTTP/2, les seules actions prises en charge sont les actions forward.

Actions de réponse fixe

Vous pouvez utiliser des actions fixed-response pour supprimer des demandes clients et renvoyer une réponse HTTP personnalisée. Vous pouvez utiliser cette action pour renvoyer un code réponse 2XX, 4XX ou 5XX et un message en option.

Lorsqu'une action fixed-response est effectuée, l'action et l'URL de la cible de redirection sont enregistrées dans les journaux d'accès. Pour plus d’informations, consultez Entrées des journaux d'accès. Le nombre d'actions fixed-response ayant abouti est indiqué dans la métrique HTTP_Fixed_Response_Count. Pour plus d’informations, consultez Métriques Application Load Balancer.

[
  {
      "Type": "fixed-response",
      "FixedResponseConfig": {
          "StatusCode": "200",
          "ContentType": "text/plain",
          "MessageBody": "Hello world"
      }
  }
]

Actions de réacheminement

Vous pouvez utiliser des actions forward pour acheminer des demandes vers un ou plusieurs groupes cibles. Si vous spécifiez plusieurs groupes cibles pour une action forward, vous devez spécifier une pondération pour chaque groupe cible. Le poids de chaque groupe cible est une valeur comprise entre 0 et 999. Les demandes qui correspondent à une règle d’écouteur avec des groupes cibles pondérés sont distribuées à ces groupes cibles en fonction de leur pondération. Par exemple, si vous spécifiez deux groupes cibles, chacun ayant une pondération de 10, chaque groupe cible reçoit la moitié des demandes. Si vous spécifiez deux groupes cibles, l'un avec une pondération de 10 et l'autre avec une pondération de 20, le groupe cible avec une pondération de 20 reçoit deux fois plus de demandes que l'autre groupe cible.

Par défaut, la configuration d'une règle de distribution du trafic entre des groupes cibles pondérés ne garantit pas que les sessions permanentes sont respectées. Pour vous assurer que les sessions permanentes sont respectées, activez la permanence du groupe cible pour la règle. Lorsque l'équilibreur de charge achemine pour la première fois une demande vers un groupe cible pondéré, il génère un cookie nommé AWSALBTG qui code les informations relatives au groupe cible sélectionné, chiffre le cookie et inclut le cookie dans la réponse au client. Le client doit inclure le cookie qu'il reçoit dans les demandes ultérieures à l'équilibreur de charge. Lorsque l'équilibreur de charge reçoit une demande qui correspond à une règle dans laquelle la permanence du groupe cible est activée et qui contient le cookie, la demande est acheminée vers le groupe cible spécifié dans le cookie.

Les Application Load Balancers ne prennent pas en charge les valeurs de cookie codées par URL.

Avec les demandes CORS (partage des ressources cross-origin), certains navigateurs nécessitent SameSite=None; Secure pour activer la permanence. Dans ce cas, Elastic Load Balancing génère un deuxième cookie AWSALBTGCORS, qui inclut les mêmes informations que le cookie stickiness d'origine, plus cet SameSite attribut. Les clients reçoivent les deux cookies.

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067"
              }
          ]
      }
  }
]

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ]
      }
  }
]

[
  {
      "Type": "forward",
      "ForwardConfig": {
          "TargetGroups": [
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067",
                  "Weight": 10
              },
              {
                  "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59",
                  "Weight": 20
              }
          ],
          "TargetGroupStickinessConfig": {
              "Enabled": true,
              "DurationSeconds": 1000
          }
      }
  }
]

Actions de redirection

Vous pouvez utiliser des actions redirect pour rediriger les demandes clients depuis une URL vers une autre. Vous pouvez configurer des redirections temporaires (HTTP 302) ou permanentes (HTTP 301) en fonction de vos besoins.

Une URI se compose des éléments suivants :

protocol://hostname:port/path?query

Vous devez modifier au moins l'un des composants suivants afin d'éviter une redirection en boucle : protocole, nom d'hôte, port ou chemin d'accès. Les composants que vous ne modifiez pas conservent leurs valeurs d'origine.

Vous pouvez réutiliser les composants d'URI de l'URL d'origine dans l'URL cible, en utilisant les mots-clés réservés suivants :

Lorsqu'une action redirect est effectuée, elle est enregistrée dans les journaux d'accès. Pour plus d’informations, consultez Entrées des journaux d'accès. Le nombre d'actions redirect ayant abouti est indiqué dans la métrique HTTP_Redirect_Count. Pour plus d’informations, consultez Métriques Application Load Balancer.

Exemple de redirection d'actions à l'aide de la console

La règle suivante définit une redirection permanente vers une URL qui utilise le protocole HTTPS et le port spécifié (40443), mais elle conserve le chemin d'accès et le nom d'hôte ainsi que les paramètres de requête d'origine. Cet écran est l'équivalent à "https://#{host}:40443/#{path}?#{query}".

La règle suivante définit une redirection permanente vers une URL qui utilise le protocole, le port, le nom d'hôte ainsi que les paramètres de requête d'origine, et utilise le mot clé #{path} pour créer un chemin modifié. Cet écran est équivalent à "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".

[
  {
      "Type": "redirect",
      "RedirectConfig": {
          "Protocol": "HTTPS",
          "Port": "443",
          "Host": "#{host}",
          "Path": "/#{path}",
          "Query": "#{query}",
          "StatusCode": "HTTP_301"
      }
  }
]

Types de conditions de règle

Les types de conditions suivants pour une règle sont pris en charge :

Chaque règle peut éventuellement inclure une des conditions suivantes : host-header, http-request-method, path-pattern et source-ip. Chaque règle peut également inclure une ou plusieurs des conditions suivantes : http-header et query-string.

Vous pouvez spécifier jusqu’à trois évaluations de correspondances par condition. Par exemple, pour chaque condition http-header, vous pouvez spécifier jusqu'à trois chaînes à comparer avec la valeur de l'en-tête HTTP dans la demande. La condition est remplie si l'une des chaînes correspond à la valeur de l'en-tête HTTP. Pour exiger que toutes les chaînes correspondent, créez une condition par évaluation de correspondance.

Vous pouvez spécifier jusqu’à cinq évaluations de correspondances par règle. Vous pouvez, par exemple, créer une règle avec cinq conditions, où chaque condition possède une évaluation de correspondance.

Vous pouvez inclure des caractères génériques dans les évaluations de correspondances pour les conditions http-header, host-header, path-pattern et query-string. Le nombre de caractères génériques par règle est limité à cinq.

Les règles sont appliquées uniquement aux caractères ASCII visibles ; les caractères de contrôle (0x00 à 0x1f et 0x7f) sont exclus.

Pour des démonstrations, consultez Routage avancé des demandes.

Conditions de l'en-tête HTTP

Vous pouvez utiliser des conditions de l’en-tête HTTP pour configurer des règles qui acheminent des demandes, en fonction des en-têtes HTTP de la demande. Vous pouvez spécifier les noms des champs d'en-tête HTTP standard ou personnalisés. Le nom de l'en-tête et l'évaluation de correspondance ne sont pas sensibles à la casse. Les caractères génériques suivants sont pris en charge dans les chaînes de comparaison : * (correspond à 0 caractères ou plus) et ? (correspond exactement à 1 caractère). Les caractères génériques ne sont pas pris en charge par le nom de l’en-tête.

[
  {
      "Field": "http-header",
      "HttpHeaderConfig": {
          "HttpHeaderName": "User-Agent",
          "Values": ["*Chrome*", "*Safari*"]
      }
  }
]

Conditions de la méthode de demande HTTP

Vous pouvez utiliser des conditions de méthode de demande HTTP pour configurer des règles qui acheminent des demandes, en fonction de la méthode de demande HTTP de la demande. Vous pouvez spécifier des méthodes HTTP standard ou personnalisées. L’évaluation des correspondances est sensible à la casse. Les caractères génériques ne sont pas pris en charge, le nom de la méthode doit par conséquent correspondre exactement.

Nous vous recommandons d’acheminer les demandes GET et HEAD de la même manière, car la réponse à une demande HEAD peut être mise en cache.

[
  {
      "Field": "http-request-method",
      "HttpRequestMethodConfig": {
          "Values": ["CUSTOM-METHOD"]
      }
  }
]

Conditions d'hôte

Vous pouvez utiliser des conditions d'hôte afin de définir des règles qui acheminent des demandes en fonction du nom d'hôte de l'en-tête de l'hôte (également appelé routage basé sur l'hôte). Cela vous permet de prendre en charge plusieurs sous-domaines et différents domaines de premier niveau à l'aide d'un seul équilibreur de charge.

Le nom d'hôte n'est pas sensible à la casse, peut comporter jusqu'à 128 caractères et peut contenir les caractères suivants :

Vous devez inclure au moins un caractère « . ». Vous pouvez inclure uniquement des caractères alphabétiques après le dernier caractère « . ».

La règle *.example.com correspond à test.example.com, mais ne correspond pas à example.com.

[
  {
      "Field": "host-header",
      "HostHeaderConfig": {
          "Values": ["*.example.com"]
      }
  }
]

Conditions de chemin

Vous pouvez utiliser des conditions de chemin d'accès afin de définir des règles qui acheminent les demandes sur la base de l'URL contenue dans la demande (routage basé sur le chemin d'accès).

Le modèle de chemin est appliqué uniquement au chemin d'accès de l'URL, pas à ses paramètres de requête. Il est appliqué uniquement aux caractères ASCII visibles ; les caractères de contrôle (0x00 à 0x1f et 0x7f) sont exclus.

L'évaluation des règles n'est effectuée qu'après normalisation de l'URI.

Un modèle de chemin est sensible à la casse, peut comporter jusqu'à 128 caractères et peut contenir les caractères suivants.

Si la version du protocole est gRPC, les conditions peuvent être spécifiques à un package, à un service ou à une méthode.

Le modèle de chemin est utilisé pour acheminer des demandes, mais il ne les modifie pas. Par exemple, si une règle a un motif de chemin d'accès de /img/*, la règle redirige une demande pour /img/picture.jpg vers le groupe cible spécifié en tant que demande pour /img/picture.jpg.

[
  {
      "Field": "path-pattern",
      "PathPatternConfig": {
          "Values": ["/img/*"]
      }
  }
]

Conditions d'une chaîne de requête

Vous pouvez utiliser des conditions d’une chaîne de requête pour configurer des règles qui acheminent les requêtes en fonction des paires clé/valeur ou des valeurs de la chaîne de requête. L’évaluation de correspondance n’est pas sensible à la casse. Les caractères génériques suivants sont pris en charge : * (correspond à 0 caractères ou plus) et ? (correspond exactement à 1 caractère).

[
  {
      "Field": "query-string",
      "QueryStringConfig": {
          "Values": [
            {
                "Key": "version", 
                "Value": "v1"
            },
            {
                "Value": "*example*"
            }
          ]
      }
  }
]

Conditions d'une adresse IP source

Vous pouvez utiliser des conditions d’adresse IP source pour configurer des règles qui acheminent des demandes, en fonction de l’adresse IP source de la demande. L’adresse IP doit être spécifiée au format CIDR. Vous pouvez utiliser des adresses IPv4 et IPv6. Les caractères génériques ne sont pas pris en charge. Vous ne pouvez pas spécifier le CIDR 255.255.255.255/32 pour la condition de règle IP source.

Si un client se trouve derrière un proxy, il s'agit de l'adresse IP du proxy et non de l'adresse IP du client.

Cette condition n'est pas remplie par les adresses dans l'en-tête X-Forwarded-For. Pour rechercher des adresses dans l'en-tête X-Forwarded-For, utilisez une condition. http-header.

[
  {
      "Field": "source-ip",
      "SourceIpConfig": {
          "Values": ["192.0.2.0/24", "198.51.100.10/32"]
      }
  }
]