Actions de réponse fixe Actions de réacheminement Actions de redirection

Types d'actions pour les règles d'écoute

Les actions déterminent la manière dont un équilibreur de charge gère les demandes lorsque les conditions d'une règle d'écoute sont satisfaites. Chaque règle doit comporter au moins une action qui indique comment traiter les demandes correspondantes. Chaque action de règle possède un type et des informations de configuration. Les équilibreurs de charge d'application prennent en charge les types d'actions suivants pour les règles d'écoute.

Types d'action

authenticate-cognito: [Écouteurs HTTPS] Utiliser Amazon Cognito pour authentifier les utilisateurs. Pour de plus amples informations, veuillez consulter Configuration de l'authentification utilisateur.
authenticate-oidc: [Écouteurs HTTPS] Utiliser un fournisseur d'identité compatible avec OpenID Connect (OIDC) pour authentifier les utilisateurs. Pour de plus amples informations, veuillez consulter Configuration de l'authentification utilisateur.
fixed-response: Renvoyer une réponse HTTP personnalisée. Pour de plus amples informations, veuillez consulter Actions de réponse fixe.
forward: Acheminer les demandes vers les groupes cibles spécifiés. Pour de plus amples informations, veuillez consulter Actions de réacheminement.
redirect: Rediriger les demandes depuis une URL vers une autre. Pour de plus amples informations, veuillez consulter Actions de redirection.

Les bases de l'action

Chaque règle doit inclure exactement l'une des actions de routage suivantes :forward,redirect, oufixed-response, et il doit s'agir de la dernière action à effectuer.
Un écouteur HTTPS peut avoir une règle comportant une action d'authentification utilisateur et une action de routage.
Lorsque plusieurs actions sont effectuées, l'action la moins prioritaire est exécutée en premier.
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

Une fixed-response action supprime les demandes des clients et renvoie 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 de plus amples informations, veuillez consulter 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 de plus amples informations, veuillez consulter Métriques Application Load Balancer.

Exemple d'action de réponse fixe pour AWS CLI

Vous pouvez spécifier une action lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. L'action suivante envoie une réponse fixe avec le code d'état et le corps du message spécifiés.


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

Actions de réacheminement

Une action forward achemine les demandes vers son groupe cible. Avant d’ajouter une action forward, créez le groupe cible et ajoutez des cibles à ce dernier. Pour de plus amples informations, veuillez consulter Créez un groupe cible pour votre Application Load Balancer.

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.

Si vous configurez une règle pour répartir le trafic entre des groupes cibles pondérés et que l'un des groupes cibles est vide ou ne comporte que des cibles malsaines, l'équilibreur de charge ne bascule pas automatiquement vers un groupe cible ayant des cibles saines.

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.

Exemple d'action de transfert avec un groupe cible

Vous pouvez spécifier une action lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. L'action suivante transmet les demandes au groupe cible spécifié.


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

Exemple d'action de transfert avec deux groupes cibles pondérés

L'action suivante transfère les demandes aux deux groupes cibles spécifiés, en fonction de la pondération de chaque groupe cible.


[
  {
      "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
              }
          ]
      }
  }
]

Exemple d'action de transfert avec la permanence activée

Si vous disposez d'une action de transfert avec plusieurs groupes cibles et qu'un ou plusieurs des groupes cibles ont des sessions permanentes activées, vous devez activer la permanence de groupe cible.

L'action suivante transfère les demandes aux deux groupes cibles spécifiés, la permanence de groupe cible étant activée. Les demandes qui ne contiennent pas les cookies de permanence sont acheminées en fonction du poids de chaque groupe cible.


[
  {
      "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

Une redirect action redirige les demandes des clients d'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.

protocole ;: Le protocole (HTTP ou HTTPS). Vous pouvez rediriger HTTP vers HTTP, HTTP vers HTTPS et HTTPS vers HTTPS. Vous ne pouvez pas rediriger HTTPS vers HTTP.
hostname: Le nom d'hôte. Un nom d'hôte n’est pas sensible à la casse, peut comporter jusqu'à 128 caractères et se compose de caractères alphanumériques, de caractères génériques (* et ?) et de tirets (-).
port: Le port (1 à 65535).
path: Le chemin absolu, qui commence par « / ». Un chemin est sensible à la casse, peut contenir jusqu'à 128 caractères et se compose de caractères alphanumériques, de caractères génériques (* et ?), & (en utilisant &amp ;), et des caractères spéciaux suivants : _-.$/~"'@:+.
query: les paramètres de requête. La longueur maximale est de 128 caractères.

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 :

#{protocol} - Conserve le protocole. Utilisation dans le protocole et les composants de requête.
#{host} - Conserve le domaine. Utilisation dans le nom d'hôte, le chemin et composants de requête.
#{port} - Conserve le port. Utilisation dans le port, le chemin et composants de requête.
#{path} - Conserve le chemin. Utilisation dans le chemin et les composants de requête.
#{query} - Conserve les paramètres de requête. Utilisation dans le composant de requête.

Lorsqu'une action redirect est effectuée, elle est enregistrée dans les journaux d'accès. Pour de plus amples informations, veuillez consulter Entrées des journaux d'accès. Le nombre d'actions redirect ayant abouti est indiqué dans la métrique HTTP_Redirect_Count. Pour de plus amples informations, veuillez consulter 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}".

Règle qui redirige la demande vers une URL utilisant le protocole HTTPS et le port spécifié (40443), mais conservant le domaine d'origine, le chemin, ainsi que les paramètres de requête de l'URL d'origine.

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}".

Règle qui redirige la demande vers une URL conservant le protocole, le port, le nom d'hôte, ainsi que les paramètres de requête d'origine, et utilisant le mot clé #{path} pour créer un chemin modifié.

Exemple d'action de redirection pour AWS CLI

Vous pouvez spécifier une action lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. L'action suivante redirige une demande HTTP vers une requête HTTPS sur le port 443, avec le même nom d'hôte, chemin et chaîne de requête que la demande HTTP.


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

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Règles d'un écouteur

Types de conditions