ALB vs. NLB vs. GLB: Wann Sie welchen verwenden

Elastic Load Balancing (ELB) verteilt eingehenden Anwendungsdatenverkehr automatisch auf mehrere Ziele – EC2-Instanzen, Container, Lambda-Funktionen oder IP-Adressen. ELB ist ein verwalteter Service. Das bedeutet, dass AWS die Bereitstellung, Skalierung und Verfügbarkeit des Load Balancers selbst über mehrere AZs hinweg übernimmt.

AWS bietet unter dem Dach von ELB drei Load-Balancer-Typen an: Application Load Balancer (ALB), Network Load Balancer (NLB) und Gateway Load Balancer (GWLB). Jeder arbeitet auf einer anderen Schicht des OSI-Modells und ist für unterschiedliche Anwendungsfälle optimiert.

Der ALB arbeitet auf Layer 7 (HTTP/HTTPS) des OSI-Modells. Er kann HTTP-Header, Pfade, Query-Strings, Hostnamen und Cookies auswerten, um intelligente Routing-Entscheidungen zu treffen. Der ALB ist die bevorzugte Wahl für Webanwendungen, Microservices und API-Endpunkte, die inhaltsbasiertes Routing benötigen.

Wichtige ALB-Funktionen: pfadbasiertes Routing (/api/* an eine Zielgruppe, /static/* an eine andere), hostbasiertes Routing (verschiedene virtuelle Hosts an unterschiedliche Backends), Routing anhand von HTTP-Headern und Query-Strings, WebSocket-Unterstützung sowie HTTP/2-Unterstützung. Der ALB kann an EC2-Instanzen, Container (ECS/EKS), Lambda-Funktionen und IP-Adressen routen.

Der NLB arbeitet auf Layer 4 (TCP/UDP/TLS). Er routet Pakete anhand der Daten des IP-Protokolls, ohne den Anwendungsinhalt zu untersuchen. Der NLB ist für extreme Leistung ausgelegt: Er verarbeitet Millionen von Anfragen pro Sekunde bei extrem niedriger Latenz (typischerweise unter 100 Mikrosekunden).

Wichtige NLB-Funktionen: statische IP-Adressen pro AZ (eine Elastic IP pro Subnetz), TLS-Pass-Through (Weiterleitung verschlüsselten Datenverkehrs ohne Entschlüsselung), Beibehaltung der Client-IP-Adresse und Unterstützung von UDP-Protokollen (z. B. DNS, RADIUS und Gameserver). Der NLB kann kein inhaltsbasiertes Routing durchführen und keine HTTP-Header untersuchen.

Der GWLB arbeitet auf Layer 3 (Netzwerkschicht) und dient ausschließlich zur Bereitstellung, Skalierung und Verwaltung virtueller Netzwerk-Appliances von Drittanbietern – Firewalls, Systeme zur Erkennung und Verhinderung von Eindringversuchen (IDS/IPS) sowie Systeme zur Deep Packet Inspection.

Der GWLB verwendet das GENEVE-Protokoll (Port 6081), um Datenverkehr zu kapseln und an Ihre Appliance-Flotte zu senden. Die Appliance untersucht das Paket und gibt es über denselben GWLB-Endpunkt zurück. Der Datenverkehr fließt transparent, ohne dass Routing-Änderungen in der Quell-VPC erforderlich sind. Dies ist das Standardmuster, um eine zentrale Sicherheitsprüfung in Datenverkehrsflüsse von AWS-VPCs einzufügen.

Wählen Sie den ALB, wenn:

• Sie inhaltsbasiertes Routing für HTTP/HTTPS benötigen (Pfad, Host, Header, Query-String)
• Ihr Backend Lambda-Funktionen oder ECS-Container umfasst
• Sie WebSocket- oder HTTP/2-Verbindungen benötigen
• Sie AWS WAF für die Sicherheit von Webanwendungen auf der Load-Balancer-Ebene integrieren möchten
• Sie eine Microservices-Architektur mit vielen Services unter verschiedenen URL-Pfaden entwickeln
• Sie eine SSL/TLS-Terminierung am Load Balancer benötigen

Der ALB ist bei den meisten Fragen zur Load-Balancer-Auswahl für Webanwendungen und REST-APIs in der SAA-C03-Prüfung die richtige Antwort.

Wählen Sie den NLB, wenn:

• Sie extreme Leistung benötigen (Millionen von Anfragen pro Sekunde, Latenz im Submillisekundenbereich)
• Sie statische IP-Adressen benötigen, die Partner oder Firewalls per Allowlist freigeben können
• Sie UDP-Datenverkehr verarbeiten müssen (Gaming, DNS, RADIUS, IoT)
• Sie TLS-Pass-Through ohne Entschlüsselung am Load Balancer verwenden möchten (Ende-zu-Ende-Verschlüsselung bis zum Ziel)
• Sie die Quell-IP des Clients nativ auf TCP-Ebene beibehalten müssen
• Sie AWS PrivateLink verwenden, um Services für andere VPCs oder Konten bereitzustellen (für PrivateLink ist ein NLB erforderlich)

Wählen Sie den GWLB, wenn Sie Folgendes benötigen:

• Einfügen von Firewall-Appliances von Drittanbietern (Palo Alto, Fortinet, Check Point) in den Datenverkehrsfluss Ihres Netzwerks
• Durchführen einer Deep Packet Inspection auf VPC-Ebene für sämtlichen eingehenden oder ausgehenden Datenverkehr
• Horizontales Skalieren einer Flotte von IDS/IPS-Appliances mit automatischem Load Balancing

Architektur: Der Datenverkehr fließt von der Quell-VPC → GWLB-Endpunkt → Appliance-VPC (dort verteilt der GWLB den Datenverkehr auf Appliance-Instanzen) → die Appliance gibt den Datenverkehr an den GWLB zurück → der GWLB leitet ihn an das ursprüngliche Ziel weiter. Quelle und Ziel nehmen die dazwischenliegende Prüfung nicht wahr.

Zonenübergreifendes Load Balancing verteilt den Datenverkehr gleichmäßig auf alle registrierten Ziele in allen aktivierten AZs, unabhängig davon, in welcher AZ der Load-Balancer-Knoten die Anfrage empfangen hat. Ohne zonenübergreifendes Load Balancing verteilt der Knoten jeder AZ den Datenverkehr nur auf Ziele in seiner eigenen AZ.

Beim ALB ist zonenübergreifendes Load Balancing standardmäßig aktiviert und verursacht keine zusätzlichen Kosten. Beim NLB ist es standardmäßig deaktiviert – die Aktivierung verursacht Gebühren für den Datenverkehr zwischen AZs. Beim GWLB ist zonenübergreifendes Load Balancing standardmäßig deaktiviert. Aktivieren Sie Cross-Zone LB, wenn die Anzahl der Ziele in den AZs unterschiedlich ist, um Überlastung einzelner Ziele zu vermeiden.

Schnelle Vergleichstabelle für die Prüfung:

• OSI-Schicht: ALB = 7 (HTTP), NLB = 4 (TCP/UDP), GWLB = 3 (IP)
• Protokolle: ALB = HTTP, HTTPS, WebSocket; NLB = TCP, UDP, TLS; GWLB = alle IP-Protokolle über GENEVE
• Statische IP: ALB = Nein (verwenden Sie das Muster NLB + ALB); NLB = Ja (1 pro AZ); GWLB = Nicht zutreffend
• WAF-Integration: ALB = Ja; NLB = Nein; GWLB = Nein
• Lambda-Ziel: ALB = Ja; NLB = Nein; GWLB = Nein
• Connection Draining: Alle drei unterstützen eine Deregistrierungsverzögerung

Der ALB lässt sich nativ mit AWS WAF zum regionalen Schutz integrieren (im Gegensatz zu WAF auf CloudFront für den globalen Edge-Schutz). Wenn Sie eine WAF-Web-ACL an einen ALB anhängen, können Sie HTTP-Anfragen filtern, bevor sie Ihre Anwendung erreichen – und SQL-Injection, XSS, bekannte schädliche IPs sowie Clients mit übermäßig vielen Anfragen blockieren.

Verwenden Sie ALB + WAF, wenn Sie eine Sicherheitsprüfung auf der Load-Balancer-Ebene wünschen (z. B. zum Schutz von APIs, die nicht über CloudFront bereitgestellt werden). WAF-Web-ACLs, die an ALBs angehängt sind, müssen sich in derselben Region wie der ALB befinden und den REGIONAL-Geltungsbereich haben (anders als CloudFront WAF, das den Geltungsbereich CLOUDFRONT in us-east-1 erfordert).

AWS PrivateLink verwendet einen NLB, um Services in einer VPC für Verbraucher in anderen VPCs oder AWS-Konten bereitzustellen, ohne VPC-Peering, ein Internet-Gateway oder NAT zu benötigen. Der Serviceanbieter erstellt vor seinem Service einen NLB und erstellt einen VPC Endpoint Service. Verbraucher erstellen in ihrer VPC einen Interface VPC Endpoint, der auf den Service verweist.

Der Datenverkehr fließt über das private Netzwerk von AWS und durchquert niemals das Internet. PrivateLink ist das Standardmuster für SaaS-Anbieter auf AWS und für die Bereitstellung gemeinsam genutzter Services (z. B. eines zentralen Sicherheitsservices) für mehrere interne AWS-Konten.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: ALB routet auf Layer 7 (HTTP) mithilfe inhaltsbasierter Regeln, WAF-Integration und Lambda-Zielen, NLB routet auf Layer 4 (TCP/UDP) mit statischen IPs und extremem Durchsatz, und GWLB stellt virtuelle Netzwerk-Appliances auf Layer 3 mithilfe von GENEVE bereit. Ordnen Sie den Load Balancer den Anforderungen an Protokolle und Funktionen zu. Als Nächstes beschäftigen wir uns mit Zielgruppen und Zustandsprüfungen.