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.

Application Load Balancers

Un équilibreur de charge constitue le point de contact unique pour les clients. Les clients envoient les demandes à l'équilibreur de charge, lequel les envoie aux cibles,telles que les instances EC2, par exemple. Pour configurer votre équilibreur de charge, vous créez des groupes cible et vous enregistrez ensuite les cibles auprès de vos groupes cible. Vous créez également des écouteurs pour rechercher les demandes de connexion des clients, et des règles d'écouteur pour acheminer les demandes des clients vers les cibles dans un ou plusieurs groupes cible.

Pour de plus amples informations, consultez la section Fonctionnement d'Elastic Load Balancing, dans le Guide de l'utilisateur Elastic Load Balancing.

Sous-réseaux pour votre équilibreur de charge

Lorsque vous créez un Application Load Balancer, vous devez activer les zones contenant vos cibles. Pour activer une zone, spécifiez un sous-réseau dans la zone. Elastic Load Balancing crée un nœud d'équilibreur de charge dans chaque zone que vous spécifiez.

Application Load Balancers prennent en charge les types de sous-réseaux suivants.

Sous-réseaux de la zone de disponibilité

Vous devez sélectionner au moins deux sous-réseaux de zone de disponibilité. Les restrictions suivantes s'appliquent :

Sous-réseaux de zone locale

Sous-réseaux Outpost

Un Application Load Balancer peut être déployé sur des instances c5/c5d, m5/m5d ou r5/r5d d'un Outpost. Le tableau suivant indique la taille et le volume EBS par type d'instance que l'équilibreur de charge peut utiliser sur un Outpost :

Groupes de sécurité d'équilibreur de charge

Un groupe de sécurité sert de pare-feu pour contrôler le trafic autorisé vers et depuis votre équilibreur de charge. Vous pouvez choisir les ports et protocoles pour autoriser à la fois le trafic entrant et sortant.

Les règles des groupes de sécurité associés à votre équilibreur de charge doivent autoriser le trafic dans les deux sens sur les ports d'écouteur et de surveillance de l'état. Chaque fois que vous ajoutez un écouteur à un équilibreur de charge ou que vous mettez à jour le port de vérification de l'état d'un groupe cible, vous devez passer en revue vos règles de groupe de sécurité pour vérifier qu'elles autorisent le trafic sur le nouveau port dans les deux sens. Pour plus d’informations, consultez Règles recommandées.

États d'un équilibreur de charge

Un équilibreur de charge peut avoir l'un des états suivants :

Attributs de l'équilibreur de charge

Les attributs de l'équilibreur de charge sont les suivants :

Type d’adresse IP

Vous pouvez définir les types d'adresses IP que les clients peuvent utiliser pour accéder à vos équilibreurs de charge internes et connectés à Internet.

Les équilibreurs de charge d'application prennent en charge les types d'adresses IP suivants :

Pour plus d'informations sur les types d'adresses IP, consultezTypes d'adresses IP de votre Application Load Balancer.

Carte des ressources de l'Application Load Balancer

La carte des ressources Application Load Balancer fournit un affichage interactif de l'architecture de votre équilibreur de charge, y compris ses écouteurs, règles, groupes cibles et cibles associés. La carte des ressources met également en évidence les relations et les chemins de routage entre toutes les ressources, produisant ainsi une représentation visuelle de la configuration de votre équilibreur de charge.

Composants de la carte des ressources

Vues cartographiques

Deux vues sont disponibles dans la carte des ressources Application Load Balancer : Overview et Unhealthy Target Map. L'option Vue d'ensemble est sélectionnée par défaut et affiche toutes les ressources de votre équilibreur de charge. La sélection de la vue Carte des cibles malsaines n'affichera que les cibles malsaines et les ressources qui leur sont associées.

La vue Malhealthy Target Map peut être utilisée pour dépanner les cibles dont les tests de santé échouent. Pour plus d’informations, consultez Résoudre les problèmes liés aux cibles défectueuses à l'aide de la carte des ressources.

Groupes de ressources

La carte des ressources Application Load Balancer contient quatre groupes de ressources, un pour chaque type de ressource. Les groupes de ressources sont les suivants : Listeners, Rules, Target groups et Targets.

Tuiles de ressources

Chaque ressource d'un groupe possède sa propre vignette, qui affiche les détails relatifs à cette ressource spécifique.

Exporter la carte des ressources

En sélectionnant Exporter, vous avez la possibilité d'exporter la vue actuelle de la carte des ressources de votre application Load Balancer au format PDF.

Connexions de l'équilibreur de charge

Lors du traitement d'une demande, l'équilibreur de charge maintient deux connexions : une connexion avec le client et une connexion avec une cible. La connexion entre l'équilibreur de charge et le client est également appelée connexion frontale. La connexion entre l'équilibreur de charge et la cible est également appelée connexion principale.

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. Sinon, si l'application ferme la connexion TCP à 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 commande modify-load-balancer-attributes avec l'attribut idle_timeout.timeout_seconds.

Durée de conservation du client HTTP

La durée de conservation du client HTTP est la durée maximale pendant laquelle un Application Load Balancer peut maintenir une connexion HTTP persistante avec un client. Une fois la durée de conservation du client HTTP configurée expirée, l'Application Load Balancer accepte une demande et 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 version HTTP utilisée par la connexion client. Pour les clients connectés via HTTP 1.x, l'équilibreur de charge envoie un en-tête HTTP contenant le champ. Connection: close Pour les clients connectés via HTTP/2, l'équilibreur de charge envoie une GOAWAY trame.

Par défaut, les équilibreurs de charge d'application définissent la durée de conservation du client HTTP sur 3 600 secondes, soit 1 heure. La durée de conservation du client HTTP 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 client HTTP jusqu'à un maximum de 604 800 secondes, soit 7 jours. L'Application Load Balancer commence la période de conservation du client HTTP lorsqu'une connexion HTTP est initialement établie avec un client. La durée continue de courir lorsqu'il n'y a pas de trafic et n'est pas réinitialisée tant qu'une nouvelle connexion n'est pas établie.

L'Application Load Balancer affecte la durée de conservation du client HTTP une seule fois lors de la connexion initiale. Lors de la mise à jour de la durée de conservation du client HTTP, cela peut entraîner des connexions simultanées avec différentes valeurs de durée de conservation du client HTTP. Les connexions existantes conserveront la valeur de durée keepalive du client HTTP appliquée lors de sa connexion initiale, tandis que toute nouvelle connexion recevra la valeur de durée keepalive mise à jour du client HTTP.

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

Utilisez la commande modify-load-balancer-attributes avec l'attribut client_keep_alive.seconds.

Equilibrage de charge entre zones

Avec les Application Load Balancers, la répartition de charge entre zones est activé par défaut et ne peut pas être modifié au niveau de l'équilibreur de charge. Pour plus d'informations, consultez Équilibrage de charge entre zones dans le Guide de l'utilisateur Elastic Load Balancing.

Il est possible de désactiver la répartition de charge entre zones au niveau du groupe cible. Pour plus d’informations, consultez Désactiver la répartition de charge entre zones.

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 commande modify-load-balancer-attributes avec l'attribut deletion_protection.enabled.

Mode d'atténuation de désynchronisation

Le mode d'atténuation de désynchronisation protège votre application contre les problèmes dus à 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. La valeur par défaut est le mode Défensif, qui fournit une atténuation durable contre la désynchronisation HTTP tout en maintenant la disponibilité de votre application. Vous pouvez passer au mode Le plus strict pour vous assurer que votre application reçoit uniquement les requêtes conformes à la RFC 7230.

La bibliothèque http_desync_guardian analyse les requêtes HTTP pour empêcher les attaques HTTP par désynchronisation. Pour plus d'informations, consultez HTTP Desync Guardian sur. GitHub

Si une requête n'est pas conforme à la RFC 7230, l'équilibreur de charge incrémente la métrique DesyncMitigationMode_NonCompliant_Request_Count. Pour plus d’informations, consultez 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 plus d’informations, consultez 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. En effet, l'augmentation du nombre de nouvelles connexions par seconde contribue aux unités de capacité de l'équilibreur de charge (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 commande modify-load-balancer-attributes avec l'attribut routing.http.desync_mitigation_mode défini sur monitor, defensive ou strictest.

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

Lorsque vous activez l'attribut Préserver l'en-tête de l'hôte, Application Load Balancer préserve l'en-tête Host dans la demande HTTP et envoie l'en-tête 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'en-tête Host de la demande HTTP avec Host: www.example.com serait modifié en Host: 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 Application Load Balancers traitent les en-têtes d'hôte dans la demande HTTP 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 commande modify-load-balancer-attributes avec l'attribut routing.http.preserve_host_header.enabled défini sur true.

Équilibreurs de charge des applications et AWS WAF

Vous pouvez l'utiliser AWS WAF avec votre Application Load Balancer pour autoriser ou bloquer les demandes en fonction des règles d'une liste de contrôle d'accès Web (ACL Web). Pour plus d'informations, consultez Utilisation des ACL web dans le Guide du développeur AWS WAF .

Par défaut, si l'équilibreur de charge ne parvient pas à obtenir de réponse AWS WAF, il renvoie une erreur HTTP 500 et ne transmet pas la demande. Si vous avez besoin que votre équilibreur de charge transmette les demandes aux cibles même s'il est incapable de les contacter AWS WAF, vous pouvez activer AWS WAF l'intégration. Pour vérifier si votre équilibreur de charge s'intègre à AWS WAF, sélectionnez votre équilibreur de charge dans AWS Management Console l'onglet Services intégrés.

ACL Web prédéfinies

Lorsque vous activez AWS WAF l'intégration, vous pouvez choisir de créer automatiquement une nouvelle ACL Web avec des règles prédéfinies. L'ACL Web prédéfinie inclut trois règles AWS gérées qui offrent des protections contre les menaces de sécurité les plus courantes.

Pour activer l'option AWS WAF Fail, ouvrez à l'aide du AWS CLI

Utilisez la commande modify-load-balancer-attributes avec l'attribut waf.fail_open.enabled défini sur true.