Écouteurs de votre Classic Load Balancer - Elastic Load Balancing

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.

Écouteurs de votre Classic Load Balancer

Avant de commencer à utiliser Elastic Load Balancing, vous devez configurer un ou plusieurs Écouteurs pour votre Classic Load Balancer. Un écouteur est un processus qui vérifie les demandes de connexion. Il est configuré avec un protocole et un port pour les connexions frontales (du client vers l'équilibreur de charge), et un protocole et un port pour les connexions principales (de l'équilibreur de charge vers l'instance principale).

Elastic Load Balancing prend en charge les protocoles suivants :

  • HTTP

  • HTTPS(sécuriséHTTP)

  • TCP

  • SSL(sécuriséTCP)

Le HTTPS protocole utilise le SSL protocole pour établir des connexions sécurisées sur la HTTP couche. Vous pouvez également utiliser le SSL protocole pour établir des connexions sécurisées sur la TCP couche.

Si la connexion frontale utilise TCP ouSSL, vos connexions principales peuvent utiliser l'un ou l'autre ouTCP. SSL Si la connexion frontale utilise HTTP ouHTTPS, vos connexions principales peuvent utiliser l'un ou l'autre ouHTTP. HTTPS

Les instances principales peuvent écouter sur les ports 1 à 65535.

Les équilibreurs de charge peuvent écouter sur les ports suivants : 1-65535

Protocoles

La communication pour une application web classique passe par des couches de matériels et de logiciels. Chaque couche fournit une fonction de communication spécifique. Le contrôle sur la fonction de communication est transmis d'une couche à la couche suivante, dans l'ordre. L'Open System Interconnection (OSI) définit un cadre modèle pour implémenter un format standard de communication, appelé protocole, dans ces couches. Pour plus d'informations, voir le OSImodèle sur Wikipedia.

Lorsque vous utilisez Elastic Load Balancing, vous devez avoir une compréhension de base des couches 4 et 7. La couche 4 est la couche de transport qui décrit la connexion du protocole de contrôle de transmission (TCP) entre le client et votre instance principale, via l'équilibreur de charge. La couche 4 est le niveau le plus bas configurable pour votre équilibreur de charge. La couche 7 est la couche d'application qui décrit l'utilisation du protocole de transfert hypertexte (HTTP) et des connexions HTTPS (sécuriséesHTTP) entre les clients et l'équilibreur de charge et entre l'équilibreur de charge et votre instance principale.

Le protocole Secure Sockets Layer (SSL) est principalement utilisé pour chiffrer des données confidentielles sur des réseaux non sécurisés tels qu'Internet. Le SSL protocole établit une connexion sécurisée entre un client et le serveur principal et garantit que toutes les données transmises entre votre client et votre serveur sont privées et intégrales.

TCP/SSLprotocole

Lorsque vous utilisez TCP (couche 4) pour les connexions frontales et dorsales, votre équilibreur de charge transmet la demande aux instances principales sans modifier les en-têtes. Une fois que votre équilibreur de charge a reçu la demande, il tente d'ouvrir une TCP connexion à l'instance principale sur le port spécifié dans la configuration de l'écouteur.

Comme les équilibreurs de charge interceptent le trafic entre les clients et vos instances principales, les journaux d'accès pour votre instance principale contiennent l'adresse IP de l'équilibreur de charge, et non celle client d'origine. Vous pouvez activer le protocole proxy, qui ajoute un en-tête avec les informations de connexion du client, comme l'adresse IP source, l'adresse IP de destination et des numéros de port. L'en-tête est ensuite envoyé à l'instance principale dans le cadre de la demande. Vous pouvez analyser la première ligne de la demande pour extraire les informations de connexion. Pour de plus amples informations, veuillez consulter Configurer le protocole proxy pour votre Classic Load Balancer.

En utilisant cette configuration, vous ne recevez pas de cookies pour la permanence des sessions ou d'en-têtes X-Forwarded.

HTTP/HTTPSprotocole

Lorsque vous utilisez HTTP (couche 7) pour les connexions frontales et dorsales, votre équilibreur de charge analyse les en-têtes de la demande avant de l'envoyer aux instances principales.

Pour chaque instance enregistrée et saine derrière un équilibreurHTTP/HTTPSload, Elastic Load Balancing ouvre et gère une ou plusieurs TCP connexions. Ces connexions garantissent qu'il existe toujours une connexion établie prête à recevoir des HTTP requêtes/HTTPS.

Les HTTP demandes et les HTTP réponses utilisent des champs d'en-tête pour envoyer des informations sur HTTP les messages. Elastic Load Balancing prend en charge les en-têtes X-Forwarded-For. Comme les équilibreurs de charge interceptent le trafic entre les clients et les serveurs, vos journaux d'accès au serveur contiennent uniquement l'adresse IP de l'équilibreur de charge. Pour voir l'adresse IP du client, utilisez l'en-tête de demande X-Forwarded-For. Pour de plus amples informations, veuillez consulter X-Forwarded-For.

Lorsque vous utilisezHTTP/HTTPS, vous pouvez activer les sessions persistantes sur votre équilibreur de charge. Une session permanente lie la session d'un utilisateur à une instance principale spécifique. Il est ainsi possible de garantir que toutes les demandes provenant de l'utilisateur pendant la session sont adressées à la même instance principale. Pour de plus amples informations, veuillez consulter Configurer des sessions permanentes pour votre Classic Load Balancer.

Toutes les HTTP extensions ne sont pas prises en charge dans l'équilibreur de charge. Vous devrez peut-être utiliser un TCP écouteur si l'équilibreur de charge n'est pas en mesure de terminer la demande en raison de méthodes inattendues, de codes de réponse ou d'autres implémentations 1.0/1.1 non standardHTTP.

HTTPS/SSLauditeurs

Vous pouvez créer un équilibreur de charge avec les fonctions de sécurité suivantes.

SSLcertificats de serveur

Si vous utilisez HTTPS ou SSL pour vos connexions frontales, vous devez déployer un certificat X.509 (certificat de SSL serveur) sur votre équilibreur de charge. L'équilibreur de charge déchiffre les demandes des clients avant de les envoyer aux instances principales (c'est ce que l'on appelle la terminaison). SSL Pour de plus amples informations, veuillez consulter SSL/TLScertificats pour les équilibreurs de charge classiques.

Si vous ne souhaitez pas que l'équilibreur de charge gère la SSL résiliation (SSLdéchargement), vous pouvez l'utiliser à la fois TCP pour les connexions frontales et dorsales, et déployer des certificats sur les instances enregistrées qui traitent les demandes.

SSLnégociation

Elastic Load Balancing fournit des configurations de SSL négociation prédéfinies qui sont utilisées pour SSL la négociation lorsqu'une connexion est établie entre un client et votre équilibreur de charge. Les configurations de SSL négociation assurent la compatibilité avec un large éventail de clients et utilisent des algorithmes cryptographiques puissants appelés chiffrements. Cependant, certains cas d'utilisation peuvent avoir besoin que toutes les données sur le réseau soient chiffrées et autoriser uniquement des chiffrements spécifiques. Certaines normes de conformité en matière de sécurité (telles que PCISOX,, etc.) peuvent nécessiter un ensemble spécifique de protocoles et de chiffrements de la part des clients pour garantir le respect des normes de sécurité. Dans ce cas, vous pouvez créer une configuration de SSL négociation personnalisée, en fonction de vos besoins spécifiques. Vos chiffrements et protocoles devraient prendre effet dans les 30 secondes. Pour de plus amples informations, veuillez consulter SSLconfigurations de négociation pour les équilibreurs de charge classiques.

Authentification de serveur principal

Si vous utilisez HTTPS ou SSL pour vos connexions principales, vous pouvez activer l'authentification de vos instances enregistrées. Vous pouvez ensuite utiliser le processus d'authentification pour vous assurer que ces instances acceptent uniquement les communications chiffrées et que chaque instance enregistrée possède la clé publique qui convient.

Pour plus d'informations, consultez Configurer l'authentification de serveur principal.