É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 (HTTP sécurisé)

  • TCP

  • SSL (TCP sécurisé)

Le protocole HTTPS utilise le protocole SSL pour établir une connexion sécurisée sur la couche HTTP. Vous pouvez également utiliser le protocole SSL pour établir une connexion sécurisée sur la couche TCP.

Si la connexion frontale utilise TCP ou SSL, vos connexions principales peuvent utiliser TCP ou SSL. Si la connexion frontale utilise HTTP ou HTTPS, vos connexions principales peuvent utiliser HTTP ou 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. OSI (Open System Interconnection) définit une infrastructure de modèle pour l'implémentation d'un format standard de communication, appelé protocole, dans ces couches. Pour plus d'informations, consultez Modèle OSI dans 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 TCP (Transmission Control Protocol) 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 des connexions HTTP (Hypertext Transfer Protocol) et HTTPS (HTTP sécurisé) depuis les clients vers l'équilibreur de charge, et depuis l'équilibreur de charge vers votre instance principale.

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

Protocole TCP/SSL

Lorsque vous utilisez TCP (couche 4) pour les connexions frontales et principales, 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 une demande, il tente d'ouvrir une connexion TCP vers 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 plus d’informations, consultez Configurer la prise en charge du 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.

Protocole HTTP/HTTPS

Lorsque vous utilisez le protocole 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 équilibreur de charge HTTP/HTTPS, Elastic Load Balancing ouvre et gère une ou plusieurs connexions TCP. Ces connexions permettent de s'assurer qu'il existe toujours une connexion établie prête à recevoir les demandes HTTP/HTTPS.

Les demandes HTTP et les réponses HTTP utilisent des champs d'en-tête pour envoyer des informations concernant les messages HTTP. 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 plus d’informations, consultez X-Forwarded-For.

Lorsque vous utilisez HTTP/HTTPS, vous pouvez activer les sessions permanentes 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 plus d’informations, consultez Configurer des sessions permanentes pour votre Classic Load Balancer.

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

Écouteurs HTTPS/SSL

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

Certificats de serveur SSL

Si vous utilisez HTTPS ou SSL pour vos connexions front-end, vous devez déployer un certificat X.509 (certificat de serveur SSL) sur votre équilibreur de charge. L'équilibreur de charge déchiffre les demandes des clients avant de les envoyer aux instances principales (terminaison SSL). Pour plus d’informations, consultez Certificats SSL/TLS pour les Classic Load Balancers.

Si vous ne voulez pas que l'équilibreur de charge gère la terminaison SSL (opération connue sous le nom de déchargement SSL), vous pouvez utiliser le protocole TCP pour les connexions front-end et back-end et déployer des certificats sur les instances enregistrées qui traitent les demandes.

Négociation SSL

Elastic Load Balancing fournit des configurations de négociation SSL prédéfinies qui sont utilisées pour la négociation SSL lorsqu'une connexion est établie entre un client et votre équilibreur de charge. Les configurations de négociation SSL assurent la compatibilité avec un grand nombre de clients et utilisent des algorithmes de chiffrement à force élevée 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é (comme, PCI, SOX, etc.) peuvent avoir besoin d'un jeu de protocoles et de chiffrements spécifiques des clients pour garantir que les normes de sécurité sont respectées. Dans de tels cas, vous pouvez créer une configuration de négociation SSL personnalisée selon vos besoins spécifiques. Vos chiffrements et protocoles devraient prendre effet dans les 30 secondes. Pour plus d’informations, consultez Configurations de négociation SSL pour Classic Load Balancers.

Authentification de serveur principal

Si vous utilisez une connexion HTTPS ou SSL pour vos connexions back-end, 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.