Configuration des écouteurs Règles d'un écouteur Types d'actions de règle Types de conditions de règle En-têtes X-forwarded

É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 EC2 que les instances.

Table des matières

Configuration des écouteurs

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

Protocoles :HTTP, HTTPS
Ports : 1 à 65535

Vous pouvez utiliser un HTTPS écouteur pour déléguer 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 c'est le protocole d'écouteHTTPS, vous devez déployer au moins un certificat de SSL serveur sur l'écouteur. Pour de plus amples informations, veuillez consulter Créez un HTTPS écouteur pour votre Application Load Balancer.

Si vous devez vous assurer que les cibles déchiffrent le HTTPS trafic plutôt que l'équilibreur de charge, vous pouvez créer un Network Load Balancer avec TCP un écouteur sur le port 443. Avec un TCP écouteur, 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 une prise en charge native pour WebSockets. Vous pouvez mettre à niveau une connexion HTTP /1.1 existante vers une connexion WebSocket (wsouwss) en utilisant une mise à niveau de HTTP connexion. Lorsque vous effectuez une mise à niveau, la TCP connexion 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 l'utiliser WebSockets avec les deux HTTP et les HTTPS auditeurs. Les options que vous choisissez pour votre écouteur s'appliquent aux WebSocket connexions ainsi qu'au HTTP trafic. Pour plus d'informations, consultez Comment fonctionne le WebSocket protocole dans le manuel Amazon CloudFront Developer Guide.

Les équilibreurs de charge d'application fournissent une prise en charge native de HTTP /2 avec des HTTPS écouteurs. Vous pouvez envoyer jusqu'à 128 requêtes en parallèle en utilisant une connexion HTTP /2. Vous pouvez utiliser la version du protocole pour envoyer la demande aux cibles en utilisant HTTP /2. Pour de plus amples informations, veuillez consulter Version du protocole. Comme HTTP /2 utilise les connexions frontales de manière plus efficace, vous remarquerez peut-être moins de connexions entre les clients et l'équilibreur de charge. Vous ne pouvez pas utiliser la fonction server-push de /2. HTTP

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 de plus amples informations, veuillez consulter 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 de plus amples informations, veuillez consulter 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 de plus amples informations, veuillez consulter 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 de plus amples informations, veuillez consulter 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 :

authenticate-cognito: [HTTPSauditeurs] Utilisez Amazon Cognito pour authentifier les utilisateurs. Pour de plus amples informations, veuillez consulter Authentification des utilisateurs à l'aide d'un Application Load Balancer.
authenticate-oidc: [HTTPSlisteners] Utilisez un fournisseur d'identité compatible avec OpenID OIDC Connect () pour authentifier les utilisateurs.
fixed-response: Renvoie une HTTP réponse 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: Redirigez les demandes de l'une URL à l'autre. Pour de plus amples informations, veuillez consulter Actions de redirection.

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 g RPC ou HTTP /2, les seules actions prises en charge sont les forward actions.

Actions de réponse fixe

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

Lorsqu'une fixed-response action est entreprise, l'action et le nom URL de la cible de redirection sont enregistrés 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

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 équilibreurs de charge d'application ne prennent pas en charge les valeurs des cookies URL codées.

Dans le cas des demandes CORS (partage de ressources entre origines multiples), certains navigateurs nécessitent d'SameSite=None; Secureactiver le caractère collant. 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

Vous pouvez utiliser redirect des actions pour rediriger les demandes des clients de l'une URL à l'autre. Vous pouvez configurer les redirections de manière temporaire (HTTP302) ou permanente (HTTP301) en fonction de vos besoins.

A URI comprend les composants 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 (HTTPouHTTPS). Vous pouvez rediriger HTTP HTTP vers HTTPHTTPS, vers et HTTPS versHTTPS. Vous ne pouvez pas rediriger HTTPS versHTTP.
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 des URI composants de l'original URL dans la cible à URL l'aide des 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 un port URL qui utilise le HTTPS protocole et le port spécifiés (40443), mais conserve le nom d'hôte, le chemin et 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 un port utilisant le HTTPS protocole et le port spécifiés (40443), mais URL qui conserve le domaine, le chemin et les paramètres de requête d'origine de l'original. URL

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

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

Exemple d'action de redirection pour le 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 HTTP demande vers une HTTPS demande sur le port 443, avec le même nom d'hôte, le même chemin et la même chaîne de requête que la HTTP demande.


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

host-header: Chemin basé sur le nom d'hôte de chaque demande. Pour de plus amples informations, veuillez consulter Conditions d'hôte.
http-header: Route basée sur les HTTP en-têtes de chaque demande. Pour de plus amples informations, veuillez consulter HTTPconditions d'en-tête.
http-request-method: Route basée sur la méthode de HTTP demande de chaque demande. Pour de plus amples informations, veuillez consulter HTTPconditions de la méthode de demande.
path-pattern: Route basée sur les modèles de chemin contenus dans la demandeURLs. Pour de plus amples informations, veuillez consulter Conditions de chemin.
query-string: Chemin basé sur des paires clé/valeur dans les chaînes de demandes. Pour de plus amples informations, veuillez consulter Conditions d'une chaîne de requête.
source-ip: Chemin basé sur l’adresse IP source de chaque demande. Pour de plus amples informations, veuillez consulter Conditions d'une adresse IP source.

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 http-header condition, vous pouvez spécifier jusqu'à trois chaînes à comparer à la valeur de l'HTTPen-tête de la demande. La condition est satisfaite si l'une des chaînes correspond à la valeur de l'HTTPen-tête. 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 ASCII caractères visibles ; les caractères de contrôle (0x00 à 0x1f et 0x7f) sont exclus.

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

HTTPconditions d'en-tête

Vous pouvez utiliser les conditions HTTP d'en-tête pour configurer des règles qui acheminent les demandes en fonction HTTP des en-têtes de la demande. Vous pouvez spécifier les noms des champs d'HTTPen-tête 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.

Exemple de condition HTTP d'en-tête pour le AWS CLI

Vous pouvez spécifier des conditions lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. La condition suivante est remplie par les demandes avec un en-tête d’agent utilisateur qui correspond à l'une des chaînes spécifiées.


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

HTTPconditions de la méthode de demande

Vous pouvez utiliser les conditions de la méthode de HTTP demande pour configurer les règles qui acheminent les HTTP demandes en fonction de la méthode de demande utilisée. Vous pouvez définir des HTTP méthodes 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 GET les HEAD demandes de la même manière, car la réponse à une HEAD demande peut être mise en cache.

Exemple de condition de HTTP méthode pour le AWS CLI


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

A à Z, a à z, 0 à 9
- .
* (correspond à 0 caractère ou plus)
? (correspond à 1 caractère exactement)

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

Exemples de noms d'hôtes

example.com
test.example.com
*.example.com

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

Exemple de condition d'en-tête d'hôte pour le AWS CLI


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

Conditions de chemin

Vous pouvez utiliser les conditions de chemin pour définir des règles qui acheminent les demandes URL en fonction du contenu de la demande (également appelé routage basé sur le chemin).

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

L'évaluation des règles n'est effectuée qu'une fois URI la normalisation effectuée.

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

A à Z, a à z, 0 à 9
_ - . $ / ~ " ' @ : +
& (utilisation de &)
* (correspond à 0 caractère ou plus)
? (correspond à 1 caractère exactement)

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

Exemples de modèles de HTTP trajectoire

/img/*
/img/*/pics

Exemples de modèles de RPC trajectoire G

/package
/package.service
/package.service/method

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.

Exemple de condition de modèle de chemin pour le AWS CLI

Vous pouvez spécifier des conditions lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. La condition suivante est satisfaite par les demandes URL contenant la chaîne spécifiée.


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

Exemple de condition de chaîne de requête pour AWS CLI

Vous pouvez spécifier des conditions lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. La condition suivante est remplie par les requêtes avec une chaîne de requête qui comprend soit une paire clé/valeur de "version=v1", soit une clé définie sur "exemple".


[
  {
      "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 CIDR format. Vous pouvez utiliser à la fois les IPv6 adresses IPv4 et les adresses. Les caractères génériques ne sont pas pris en charge. Vous ne pouvez pas spécifier la condition de règle 255.255.255.255/32 CIDR pour l'adresse 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 satisfaite par les adresses figurant dans l' X-Forwarded-Foren-tête. Pour rechercher des adresses dans l' X-Forwarded-Foren-tête, utilisez une http-header condition.

Exemple de condition IP source pour le AWS CLI

Vous pouvez spécifier des conditions lorsque vous créez ou modifiez une règle. Pour en savoir plus veuillez consulter les commandes create-rule et modify-rule. La condition suivante est satisfaite par les demandes dont l'adresse IP source se trouve dans l'un des CIDR blocs spécifiés.


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

HTTPen-têtes et équilibreurs de charge d'application

HTTPles demandes et HTTP les réponses utilisent des champs d'en-tête pour envoyer des informations sur les HTTP messages. HTTPles en-têtes sont ajoutés automatiquement. Les champs d'en-tête sont des paires nom-valeur dont les noms et les valeurs sont séparés par un signe deux points, et qui sont séparées entre elles par un retour chariot (CR) et un saut de ligne (LF). Un ensemble standard de champs d'HTTPen-tête est défini dans la section RFC 2616, En-têtes de message. Il existe également des HTTP en-têtes non standard qui sont automatiquement ajoutés et largement utilisés par les applications. Certains HTTP en-têtes non standard ont un X-Forwarded préfixe. Les Application Load Balancers prennent en charge les en-têtes X-Forwarded suivants.

Pour plus d'informations sur HTTP les connexions, consultez la section Request routing dans le guide de l'utilisateur d'Elastic Load Balancing.

X-Forwarded-For

L'en-tête de X-Forwarded-For demande vous aide à identifier l'adresse IP d'un client lorsque vous utilisez un HTTP équilibreur de HTTPS charge. Comme les équilibreurs de charge interceptent le trafic entre les clients et les serveurs, vos journaux d'accès au serveur ne contiennent que l'adresse IP de l'équilibreur de charge. Pour voir l'adresse IP du client, utilisez l'attribut routing.http.xff_header_processing.mode. Cet attribut vous permet de modifier, de conserver ou de supprimer l'X-Forwarded-Foren-tête de la HTTP demande avant que l'Application Load Balancer n'envoie la demande à la cible. Les valeurs possibles pour cet attribut sont append, preserve et remove. La valeur par défaut de cet attribut est append.

Important

L'X-Forwarded-Foren-tête doit être utilisé avec prudence en raison des risques de sécurité potentiels. Les entrées ne peuvent être considérées comme fiables que si elles sont ajoutées par des systèmes correctement sécurisés au sein du réseau.

Ajout

Par défaut, l'Application Load Balancer stocke l'adresse IP du client dans l'en-tête de demande X-Forwarded-For et transmet l'en-tête à votre serveur. Si l'en-tête de demande X-Forwarded-For n'est pas inclus dans la demande d'origine, l'équilibreur de charge en crée un avec l'adresse IP du client comme valeur de la demande. Sinon, l'équilibreur de charge ajoute l'adresse IP du client à l'en-tête existant, puis transmet l'en-tête à votre serveur. L'en-tête de demande X-Forwarded-For peut contenir plusieurs adresses IP séparées par des virgules.

L'en-tête de demande X-Forwarded-For a le format suivant :


X-Forwarded-For: client-ip-address

Voici un exemple d'en-tête de demande X-Forwarded-For pour un client avec l'adresse IP 203.0.113.7.


X-Forwarded-For: 203.0.113.7

Voici un exemple d'en-tête de X-Forwarded-For demande pour un client dont l'IPv6adresse est2001:DB8::21f:5bff:febf:ce22:8a2e.


X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e

Lorsque l'attribut de préservation du port client (routing.http.xff_client_port.enabled) est activé sur l'équilibreur de charge, l'en-tête de la demande X-Forwarded-For inclut client-port-number ajouté à client-ip-address, séparés par deux points. L'en-tête prend alors la forme suivante :


IPv4 -- X-Forwarded-For: client-ip-address:client-port-number


IPv6 -- X-Forwarded-For: [client-ip-address]:client-port-number

Notez IPv6 en effet que lorsque l'équilibreur de charge ajoute le client-ip-address à l'en-tête existant, il place l'adresse entre crochets.

Voici un exemple d'en-tête de X-Forwarded-For demande pour un client dont l'IPv4adresse 12.34.56.78 et le numéro de port sont8080.


X-Forwarded-For: 12.34.56.78:8080

Voici un exemple d'en-tête de X-Forwarded-For demande pour un client dont l'IPv6adresse 2001:db8:85a3:8d3:1319:8a2e:370:7348 et le numéro de port sont8080.


X-Forwarded-For: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:8080

Préserver

Le preserve mode de l'attribut garantit que l'X-Forwarded-Foren-tête de la HTTP demande n'est en aucun cas modifié avant son envoi aux cibles.

Remove (suppression)

Le remove mode de l'attribut supprime l'X-Forwarded-Foren-tête de la HTTP demande avant qu'elle ne soit envoyée aux cibles.

Note

Si vous activez l'attribut de préservation du port client (routing.http.xff_client_port.enabled) et que vous sélectionnez également preserve ou remove pour l'attribut routing.http.xff_header_processing.mode, Application Load Balancer remplace l'attribut de préservation du port client. Il conserve l'en-tête X-Forwarded-For inchangé ou le supprime selon le mode que vous sélectionnez, avant de l'envoyer aux cibles.

Le tableau suivant présente des exemples d'en-tête X-Forwarded-For que la cible reçoit lorsque vous sélectionnez le mode append, preserve ou remove. Dans cet exemple, l'adresse IP du dernier saut est 127.0.0.1.

Description de la demande	Exemple de demande	XFFen `append` mode	XFFen `preserve` mode	XFFen `remove` mode
La demande est envoyée sans XFF en-tête	`GET /index.html HTTP/1.1 Host: example.com`	`X-Forwarded-For: 127.0.0.1`	Absent	Absent
La demande est envoyée avec un XFF en-tête et une adresse IP du client.	`GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.4`	`X-Forwarded-For: 127.0.0.4, 127.0.0.1`	`X-Forwarded-For: 127.0.0.4`	Absent
La demande est envoyée avec un XFF en-tête contenant plusieurs adresses IP de clients.	`GET /index.html HTTP/1.1 Host: example.com X-Forwarded-For: 127.0.0.4, 127.0.0.8`	`X-Forwarded-For: 127.0.0.4, 127.0.0.8, 127.0.0.1`	`X-Forwarded-For: 127.0.0.4, 127.0.0.8`	Absent

Pour modifier, conserver ou supprimer X-Forwarded-For en-tête à l'aide de la console

Ouvrez la EC2 console Amazon à l'adresse https://console.aws.amazon.com/ec2/.
Dans le volet de navigation, choisissez Load Balancers (Équilibreurs de charge).
Sélectionnez l'équilibreur de charge.
Dans l'onglet Attributes, choisissez Edit.
Dans la section Configuration du trafic, sous Gestion des paquets, pour l'X-Forwarded-For en-tête, choisissez Ajouter (par défaut), Préserver ou Supprimer.
Sélectionnez Enregistrer les modifications.

Pour modifier, conserver ou supprimer X-Forwarded-For en-tête utilisant le AWS CLI

Utilisez la modify-load-balancer-attributescommande avec l'routing.http.xff_header_processing.modeattribut.

X-Forwarded-Proto

L'en-tête de X-Forwarded-Proto demande vous aide à identifier le protocole (HTTPouHTTPS) utilisé par un client pour se connecter à votre équilibreur de charge. Les journaux d'accès de votre serveur contiennent uniquement le protocole utilisé entre le serveur et l'équilibreur de charge ; ils ne comportent aucune information sur le protocole utilisé entre le client et l'équilibreur de charge. Pour déterminer le protocole utilisé entre le client et l'équilibreur de charge, utilisez l'en-tête de demande X-Forwarded-Proto. Elastic Load Balancing stocke le protocole utilisé entre le client et l'équilibreur de charge dans l'en-tête de demande X-Forwarded-Proto et transmet en même temps l'en-tête à votre serveur.

Votre application ou site Web peut utiliser le protocole stocké dans l'en-tête de la X-Forwarded-Proto demande pour afficher une réponse qui redirige vers le protocole appropriéURL.

L'en-tête de demande X-Forwarded-Proto a le format suivant :


X-Forwarded-Proto: originatingProtocol

L'exemple suivant contient un en-tête de X-Forwarded-Proto demande pour une demande provenant du client en tant que HTTPS demande :


X-Forwarded-Proto: https

X-Forwarded-Port

L'en-tête de demande X-Forwarded-Port vous permet d'identifier le port de destination utilisé par le client pour se connecter à l'équilibreur de charge.

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

Lancement d'un changement de zone

Création d'un HTTP écouteur