Les flèches du diagramme indiquent uniquement le sens de l'établissement de la connexion - pas le flux de trafic.
Oui, le trafic de retour passe par l'ELB.
Mais, ce n'est pas un NAT avec état - c'est un proxy de connexion TCP. Les machines ELB acceptent les connexions TCP sur les ports d'écoute configurés, mettant fin à la session SSL si elle est ainsi configurée et établissent une nouvelle connexion TCP avec le serveur principal. Si l'écouteur est configuré pour HTTP, l'ELB fonctionne en mode sensible à la charge utile en analysant, enregistrant et transmettant les requêtes HTTP au back-end, sinon il est indépendant de la payload, établissant une nouvelle connexion TCP 1: 1 au back-end pour chaque connexion entrante et «attacher les tuyaux ensemble» (sans prise de conscience ni modification au niveau HTTP).
Dans les deux cas, l'adresse source de la connexion entrante à votre application sera celle du nœud ELB, pas le client d'origine. C'est ainsi que le trafic de réponse retourne à l'ELB pour être retourné au client.
En mode http, l'ELB ajoute (ou ajoute à) l'en- X-Forwarded-Fortête afin que votre application puisse identifier l'IP client d'origine, ainsi que X-Forwarded-Proto: [ http | https ]pour indiquer si la connexion client utilise SSL et X-Forwarded-Portpour indiquer le port frontal.
Mise à jour: ce qui précède fait référence à un type d'équilibreur de charge qui est maintenant connu sous le nom de "ELB Classic" ou ELB / 1.0 (trouvé dans la chaîne d'agent utilisateur qu'il envoie avec des contrôles d'intégrité HTTP).
Le nouvel équilibreur de couche 7, Application Load Balancer ou ELB / 2.0 fonctionne de la même manière en ce qui concerne le flux de trafic. La capacité de la couche 4 (TCP "transparente") est supprimée de l'ALB et les fonctionnalités de la couche 7 sont considérablement améliorées.
Le plus récent type d'équilibreur de charge, l'équilibreur de charge réseau, est un équilibreur de couche 3. Contrairement aux deux autres, il se comporte comme le NAT dynamique, ne gérant que les connexions entrantes (provenant de l'extérieur), mappant source-addr + port via EIP-addr + port vers instance-private-ip: adde + port - avec EIP lié à "l'équilibreur" - et contrairement aux deux autres types d'équilibreurs, les instances doivent se trouver sur des sous-réseaux publics et utiliser leurs propres adresses IP publiques pour cela.
Sur le plan conceptuel, le Network Load Balancer semble modifier réellement le comportement de la passerelle Internet - qui est, en soi, un objet logique qui ne peut pas être désactivé, remplacé ou subir une défaillance dans un sens significatif. Ceci contraste avec ELB et ALB, qui fonctionnent réellement sur les instances EC2 "cachées". NLB opère sur l'infrastructure réseau, elle-même, selon toutes les apparences.
and unlike the other two types of balancers, the instances need to be on public subnets, and use their own public IPs for this.Je suis très content de lire ceci. Pouvez-vous fournir une référence à ces informations?Selon la documentation AWS pour NLB, il s'agit de la couche 4 et non de la couche 3. De plus, les serveurs principaux ou cibles ne doivent pas nécessairement se trouver sur un sous-réseau public. En fait, les plages d'adresses IP des groupes cibles doivent être l'une des suivantes: Voici les types de cibles possibles:
instance Les cibles sont spécifiées par l'ID d'instance.
ip Les cibles sont spécifiées par l'adresse IP.
Lorsque le type cible est ip, vous pouvez spécifier des adresses IP à partir de l'un des blocs CIDR suivants:
Les sous-réseaux du VPC pour le groupe cible
10.0.0.0/8 (RFC 1918)
100.64.0.0/10 (RFC 6598)
172.16.0.0/12 (RFC 1918)
192.168.0.0/16 (RFC 1918)
Important
Vous ne pouvez pas spécifier d'adresses IP publiquement routables.
J'espère que ça aide.
la source