Die Pfeile im Diagramm geben nur die Richtung des Verbindungsaufbaus an - nicht den Verkehrsfluss.
Ja, der Rückverkehr geht über die ELB zurück.
Es handelt sich jedoch nicht um ein statusbehaftetes NAT, sondern um einen TCP-Verbindungsproxy. Die ELB-Computer akzeptieren TCP-Verbindungen an den konfigurierten Überwachungsports, beenden die SSL-Sitzung, falls dies konfiguriert ist, und stellen eine neue TCP-Verbindung zum Back-End-Server her. Wenn der Listener für HTTP konfiguriert ist, arbeitet der ELB in einem Payload-fähigen Modus, der HTTP-Anforderungen analysiert, protokolliert und an das Back-End weiterleitet. Andernfalls ist er payload-unabhängig und stellt eine neue TCP-Verbindung 1: 1 zum Back-End her für jede eingehende Verbindung und "Zusammenbinden der Pipes" (ohne Kenntnis oder Änderung auf HTTP-Ebene).
In beiden Fällen ist die Quelladresse der eingehenden Verbindung zu Ihrer Anwendung die des ELB-Knotens und nicht die des ursprünglichen Clients. Auf diese Weise kehrt der Antwortverkehr zur Rückgabe an den Client an die ELB zurück.
Im http-Modus fügt der ELB den X-Forwarded-ForHeader hinzu (oder hängt ihn an), damit Ihre Anwendung die ursprüngliche Client-IP identifizieren kann, um X-Forwarded-Proto: [ http | https ]anzugeben, ob die Client-Verbindung SSL verwendet, und X-Forwarded-Portum den Front-End-Port anzugeben.
Update: Das Obige bezieht sich auf einen Typ von Load Balancer, der jetzt als "ELB Classic" oder ELB / 1.0 bekannt ist (in der Benutzeragentenzeichenfolge enthalten, die mit HTTP-Integritätsprüfungen gesendet wird).
Der neuere Layer 7-Balancer, Application Load Balancer oder ELB / 2.0 funktioniert in Bezug auf den Verkehrsfluss ähnlich. Die Layer 4-Funktion ("transparentes" TCP) wurde aus ALB entfernt und die Layer 7-Funktionen wurden erheblich verbessert.
Der neueste Typ von Load Balancer, der Network Load Balancer, ist ein Layer 3-Balancer. Im Gegensatz zu den beiden anderen verhält es sich sehr ähnlich wie dynamisches NAT, verarbeitet nur eingehende (von außen stammende) Verbindungen und ordnet Quell-Adr + Port über EIP-Adresse + Port der Instanz-Private-IP: ADDE + Port - mit der EIP zu an den "Balancer" gebunden - und im Gegensatz zu den beiden anderen Balancertypen müssen sich die Instanzen in öffentlichen Subnetzen befinden und hierfür ihre eigenen öffentlichen IP-Adressen verwenden.
Konzeptionell scheint der Network Load Balancer tatsächlich das Verhalten des Internet-Gateways zu ändern - das selbst ein logisches Objekt ist, das nicht deaktiviert, ersetzt oder in einem sinnvollen Sinne fehlerhaft behandelt werden kann. Dies steht im Gegensatz zu ELB und ALB, die tatsächlich auf "versteckten" EC2-Instanzen arbeiten. NLB arbeitet anscheinend auf der Netzwerkinfrastruktur selbst.
and unlike the other two types of balancers, the instances need to be on public subnets, and use their own public IPs for this.Ich bin sehr froh, das zu lesen. Können Sie einen Verweis auf diese Informationen geben?Gemäß der AWS-Dokumentation für NLB handelt es sich um Schicht 4 und nicht um Schicht 3. Außerdem müssen sich die Backend- oder Zielserver nicht in einem öffentlichen Subnetz befinden. Tatsächlich müssen die IP-Adressbereiche der Zielgruppen eine der folgenden sein: Folgende Zieltypen sind möglich:
Instanz Die Ziele werden durch die Instanz-ID angegeben.
ip Die Ziele werden durch die IP-Adresse angegeben.
Wenn der Zieltyp IP ist, können Sie IP-Adressen aus einem der folgenden CIDR-Blöcke angeben:
Die Subnetze der VPC für die Zielgruppe
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)
Wichtig
Sie können keine öffentlich routbaren IP-Adressen angeben.
Ich hoffe das hilft.
quelle