Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Modifier les attributs de votre Application Load Balancer

Après avoir créé un Application Load Balancer, vous pouvez modifier ses attributs.

Délai d'inactivité des connexions

Le délai d'inactivité de la connexion est la période pendant laquelle une connexion client ou cible existante peut rester inactive, sans qu'aucune donnée ne soit envoyée ou reçue, avant que l'équilibreur de charge ne ferme la connexion.

Pour garantir que les opérations longues telles que le téléchargement de fichiers aient le temps de se terminer, envoyez au moins 1 octet de données avant la fin de chaque période d'inactivité et augmentez la durée de la période d'inactivité selon les besoins. Nous vous recommandons également de configurer le délai d'inactivité de votre application afin qu'il soit supérieur au délai d'inactivité configuré pour l'équilibreur de charge. Dans le cas contraire, si l'application ferme la TCP connexion à l'équilibreur de charge de manière inappropriée, celui-ci peut envoyer une demande à l'application avant qu'elle ne reçoive le paquet indiquant que la connexion est fermée. Si tel est le cas, l'équilibreur de charge envoie une erreur HTTP 502 Bad Gateway au client.

Par défaut, Elastic Load Balancing définit le délai d'inactivité de votre équilibreur de charge à 60 secondes, soit 1 minute. Utilisez la procédure suivante pour définir une valeur de délai d'inactivité différente.

Pour mettre à jour la valeur du délai d'inactivité à l'aide du AWS CLI

Utilisez la modify-load-balancer-attributescommande avec l'idle_timeout.timeout_secondsattribut.

HTTPdurée de conservation du client

La durée de conservation du HTTP client est la durée maximale pendant laquelle un Application Load Balancer maintient une connexion HTTP permanente avec un client. Une fois la durée de conservation configurée du HTTP client expirée, l'Application Load Balancer accepte une autre demande, puis renvoie une réponse qui ferme la connexion en douceur.

Le type de réponse envoyée par l'équilibreur de charge dépend de la HTTP version utilisée par la connexion client.

Par défaut, Application Load Balancer définit la durée de conservation du HTTP client pour les équilibreurs de charge à 3 600 secondes, soit 1 heure. La durée de conservation du HTTP client ne peut pas être désactivée ou définie en dessous du minimum de 60 secondes, mais vous pouvez augmenter la durée de conservation du HTTP client jusqu'à un maximum de 604 800 secondes, soit 7 jours. Un Application Load Balancer commence la période de conservation du HTTP client lorsqu'une HTTP connexion à un client est initialement établie. La durée continue lorsqu'il n'y a pas de trafic et ne se réinitialise pas tant qu'une nouvelle connexion n'est pas établie.

Lorsque le trafic de l'équilibreur de charge est déplacé hors d'une zone de disponibilité restreinte à l'aide du changement de zone ou du décalage automatique de zone, les clients disposant déjà de connexions ouvertes peuvent continuer à faire des demandes concernant la zone affectée jusqu'à ce qu'ils se reconnectent. Pour accélérer la restauration, pensez à définir une valeur de durée de conservation inférieure afin de limiter la durée pendant laquelle les clients restent connectés à un équilibreur de charge. Pour plus d'informations, consultez Limiter le temps pendant lequel les clients restent connectés à vos points de terminaison dans le manuel du développeur Amazon Application Recovery Controller (ARC).

L'Application Load Balancer attribue la valeur de durée keepalive au HTTP client lors de la connexion initiale. Lorsque vous mettez à jour la durée de conservation du HTTP client, cela peut entraîner des connexions simultanées avec différentes valeurs de durée de conservation du HTTP client. Les connexions existantes conservent la valeur de durée de conservation du HTTP client appliquée lors de sa connexion initiale. Les nouvelles connexions reçoivent la valeur de durée Keepalive mise à jour du HTTP client.

Pour mettre à jour la valeur de la durée de conservation du client à l'aide du AWS CLI

Utilisez la modify-load-balancer-attributescommande avec l'client_keep_alive.secondsattribut.

Deletion protection (Protection contre la suppression)

Pour éviter la suppression accidentelle de votre équilibreur de charge, vous pouvez activer la protection contre la suppression. Par défaut, la protection contre la suppression est désactivée pour votre équilibreur de charge.

Si vous activez la protection contre la suppression de votre équilibreur de charge, vous devez la désactiver pour pouvoir supprimer l'équilibreur de charge.

Pour activer ou désactiver la protection contre la suppression à l'aide du AWS CLI

Utilisez la modify-load-balancer-attributescommande avec l'deletion_protection.enabledattribut.

Mode d'atténuation de désynchronisation

Le mode d'atténuation de la désynchronisation protège votre application contre les problèmes liés à la désynchronisation. HTTP L'équilibreur de charge classe chaque demande en fonction de son niveau de menace, autorise les demandes sécurisées, puis atténue les risques comme spécifié par le mode d'atténuation que vous spécifiez. Les modes d'atténuation de désynchronisation sont Moniteur, Défensif et Le plus strict. Le mode par défaut est le mode défensif, qui permet d'atténuer durablement les risques de HTTP désynchronisation tout en préservant la disponibilité de votre application. Vous pouvez passer en mode le plus strict pour garantir que votre application ne reçoit que les demandes conformes à la norme RFC7230.

La bibliothèque http_desync_guardian analyse HTTP les demandes pour empêcher les attaques de désynchronisation. HTTP Pour plus d'informations, consultez HTTPDesync Guardian sur. GitHub

Si une demande n'est pas conforme à la norme RFC 7230, l'équilibreur de charge incrémente la métrique. DesyncMitigationMode_NonCompliant_Request_Count Pour de plus amples informations, veuillez consulter Métriques Application Load Balancer.

La classification de chaque demande est incluse dans les journaux d'accès de l'équilibreur de charge. Si la demande n'est pas conforme, les journaux d'accès incluent un code de motif de classification. Pour de plus amples informations, veuillez consulter Motifs de classification.

Modes

Le tableau suivant décrit la façon dont les Application Load Balancers traitent les requêtes en fonction du mode et de la classification.

¹ Achemine les requêtes mais ferme les connexions client et cible. Des frais supplémentaires peuvent vous être facturés si votre équilibreur de charge reçoit un grand nombre de demandes ambiguës en mode défensif. Cela est dû au fait que l'augmentation du nombre de nouvelles connexions par seconde contribue aux unités de capacité Load Balancer (LCU) utilisées par heure. Vous pouvez utiliser la métrique NewConnectionCount pour comparer la manière dont votre équilibreur de charge établit de nouvelles connexions en mode moniteur et en mode défensif.

Pour mettre à jour le mode d'atténuation de la désynchronisation à l'aide du AWS CLI

Utilisez la modify-load-balancer-attributescommande avec l'routing.http.desync_mitigation_modeattribut défini sur monitordefensive, oustrictest.

Préservation de l'en-tête de l'hôte

Lorsque vous activez l'attribut d'en-tête Preserve host, l'Application Load Balancer préserve l'Hosten-tête de la HTTP demande et l'envoie aux cibles sans aucune modification. Si Application Load Balancer reçoit plusieurs en-têtes Host, il les conserve tous. Les règles de l'écouteur ne sont appliquées qu'au premier en-tête Host reçu.

Par défaut, lorsque l'attribut Préserver l'en-tête de l'hôte n'est pas activé, Application Load Balancer modifie l'en-tête Host de la manière suivante :

Lorsque la préservation de l'en-tête de l'hôte n'est pas activée et que le port de l'écouteur n'est pas un port par défaut : lorsque vous n'utilisez pas les ports par défaut (ports 80 ou 443), nous ajoutons le numéro de port à l'en-tête de l'hôte s'il n'est pas déjà ajouté par le client. Par exemple, l'Hosten-tête de la HTTP demande avec Host: www.example.com serait modifié enHost: www.example.com:8080, si le port de l'écouteur n'est pas un port par défaut, tel que. 8080

Lorsque la préservation de l'en-tête de l'hôte n'est pas activée et que le port de l'écouteur est un port par défaut (port 80 ou 443) : pour les ports de l'écouteur par défaut (port 80 ou 443), nous n'ajoutons pas le numéro de port à l'en-tête de l'hôte sortant. Tout numéro de port qui figurait déjà dans l'en-tête de l'hôte entrant est supprimé.

Le tableau suivant présente d'autres exemples de la façon dont les équilibreurs de charge d'application traitent les en-têtes d'hôte dans la HTTP demande en fonction du port de l'écouteur.

Pour activer la conservation de l'en-tête de l'hôte à l'aide du AWS CLI

Utilisez la modify-load-balancer-attributescommande avec l'routing.http.preserve_host_header.enabledattribut défini surtrue.