Amazon ANS-C01: Load Balancing und Traffic-Management — Lernleitfaden

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

Teil des AWS Advanced Networking Specialty ANS-C01 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Grundkonzept

Load Balancing in AWS arbeitet auf zwei grundlegenden Schichten: L4 (Transport) und L7 (Anwendung). Der Network Load Balancer (NLB) bietet eine L4-Verteilung (TCP/UDP/TLS) und ist für extreme Leistung optimiert, wobei die Quell-IP des Clients erhalten bleibt und Millionen gleichzeitiger Verbindungen mit sehr geringer Latenz und Verbindungsfluktuation unterstützt werden. Der Application Load Balancer (ALB) arbeitet auf L7 (HTTP/HTTPS/WebSocket und HTTP/2/gRPC), bietet Host- und pfadbasiertes Routing, Header-Inspektion, HTTP-basierte Zustandsprüfungen und Cookie-Stickiness und führt eine TLS-Terminierung durch, wenn er mit Zertifikaten in ACM konfiguriert ist. Der Gateway Load Balancer (GWLB) ist ein speziell entwickelter Load Balancer zur Skalierung von virtuellen Appliances von Drittanbietern (Firewalls, IDS/IPS) unter Verwendung der GENEVE-Kapselung und Gateway Load Balancer Endpoints (GWLBe), was eine Inline-Verkehrsinspektion ohne manuelle Skalierung der Appliances ermöglicht.

Listener und Listener-Regeln sind die L4/L7-Einstiegspunkte, die Protokolle/Ports auf Zielgruppen (Target Groups) abbilden. Ein Listener auf einem ALB kann komplexe Regeln haben, die Host, Pfad, Header und Quell-IP-CIDR prüfen und an verschiedene Zielgruppen weiterleiten. Ein ALB kann auch TLS auslagern (terminieren) und die Header X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Port an die Ziele weiterleiten. Ein NLB-Listener ist typischerweise ein TCP/UDP/TLS-Listener, der den Verkehr an Zielgruppen weiterleitet, ohne den Payload zu parsen (es sei denn, Sie aktivieren die TLS-Terminierung am NLB). Bei Verwendung von TCP-Passthrough bleibt die Ende-zu-Ende-TLS-Verschlüsselung erhalten, sodass das Backend Zertifikate für Mutual TLS (mTLS) bereitstellen und validieren muss. Zielgruppen (Target Groups) sind die Verknüpfung zwischen einem Load-Balancer-Listener und dem Satz von Endpunkten (Instanz, IP oder Lambda) und stellen Attribute wie Protokoll/Port/Pfad für die Zustandsprüfung, Verzögerung bei der Deregistrierung (Connection Draining) und Stickiness-Eigenschaften bereit.

Wichtige Dienste und Konfiguration

Wählen Sie den richtigen Balancer für die Verkehrseigenschaften und Sicherheitsanforderungen. Verwenden Sie einen ALB, wenn Sie Host-/pfadbasiertes Routing, HTTP/HTTPS-Funktionen wie WebSockets oder HTTP/2/gRPC mit anwendungsorientiertem Routing und Cookie-basierte Stickiness benötigen. Konfigurieren Sie ALB-Listener mit CreateListener oder über AWS::ElasticLoadBalancingV2::Listener, fügen Sie Zertifikate aus ACM an und legen Sie Listener-Regeln mit CreateRule und Bedingungen (Field=path-pattern, host-header, http-header) fest. Aktivieren Sie Stickiness für ALB-Zielgruppen mit ModifyTargetGroupAttributes, indem Sie Key=stickiness.enabled,Value=true und Key=stickiness.lb_cookie.duration_seconds,Value=<seconds> setzen, um vom Load Balancer generierte Cookies zu verwenden.

Verwenden Sie einen NLB für TCP-Verbindungen mit hohem Durchsatz und langer Lebensdauer und wenn die Beibehaltung der Quell-IP des Clients am Backend erforderlich ist. Erstellen Sie einen NLB mit aws elbv2 create-load-balancer –name my-nlb –type network –subnets <subnet-ids> und fügen Sie einen TCP-Listener mit aws elbv2 create-listener –load-balancer-arn <arn> –protocol TCP –port 443 –default-actions Type=forward,TargetGroupArn=<tg-arn> hinzu. Für Passthrough-TLS und mTLS konfigurieren Sie den NLB-Listener als TCP, sodass TLS vom Backend terminiert wird. Setzen Sie den Zieltyp der Zielgruppe auf target-type ip, wenn Sie Pod-IPs für Kubernetes registrieren. Verwenden Sie ModifyTargetGroupAttributes, um Key=deregistration_delay.timeout_seconds,Value=<seconds> zu setzen und Connection Draining zu ermöglichen. Für NLB können Sie bei Bedarf auch Quell-IP-Affinität (Stickiness der Zielgruppe) aktivieren.

Ein Gateway Load Balancer wird mit CreateLoadBalancer Type=gateway konfiguriert und durch Zielgruppen Ihrer Appliance-Instanzen (oder Scale-Sets in einer Auto-Scaling-Gruppe) gestützt. Er verwendet einen Gateway Load Balancer Endpoint in den Consumer-VPCs, um den Verkehr zu den Appliances in der Service-VPC zu leiten. Verwenden Sie dieses Muster, wenn Sie eine transparente Inspektion benötigen und die Appliances automatisch mit dem Verkehrsaufkommen skalieren sollen. Erstellen Sie Listener auf Port 6081 (GENEVE-Kapselung) und registrieren Sie die ENIs der Appliances in der GWLB-Zielgruppe.

Zu den Betriebseinstellungen, die Sie programmatisch steuern müssen, gehören zonenübergreifendes Load Balancing (Cross-Zone Load Balancing), die Verzögerung bei der Deregistrierung (Connection Draining) und die Anpassung der Zustandsprüfungen (Health Check Tuning). Für zonenübergreifendes Balancing setzen Sie Attribute am Load Balancer (aws elbv2 modify-load-balancer-attributes –load-balancer-arn <arn> –attributes Key=load_balancing.cross_zone.enabled,Value=true), um eine gleichmäßige Verkehrsverteilung über alle AZs sicherzustellen und eine ungleiche Auslastung der Kapazität pro AZ zu vermeiden. Legen Sie Intervall, Timeout und Schwellenwerte für „healthy/unhealthy“ (intakt/nicht intakt) bei den Zustandsprüfungen für Zielgruppen fest, um „Flapping“ (schnelle Statuswechsel) während Autoscaling-Ereignissen zu vermeiden.

Entwurfsmuster und Kompromisse

Für End-to-End-TLS und gegenseitige TLS (mTLS), bei denen der Datenverkehr verschlüsselt bleiben und Client-Zertifikate dem Backend vorgelegt werden müssen, ist L4-Passthrough mit einem NLB und TCP-Listenern zu bevorzugen. Dadurch bleibt die TLS-Sitzung intakt, sodass Backends die X.509-Zertifikate der Clients validieren können. Konfigurieren Sie die Zielgruppen (Target Groups) für die Verwendung von IP-Zielen, damit die IP-Adressen der Kubernetes-Pods direkt registriert werden können und der AWS Load Balancer Controller den Lebenszyklus der Ziele verwalten kann. Der Kompromiss besteht darin, dass L7-Funktionen des ALB wie Host-/Pfad-basiertes Routing, Integrationen mit der Web Application Firewall und native HTTP-Cookie-Stickiness auf der Load-Balancer-Ebene verloren gehen.

Wenn Sie inhaltsbasiertes Routing, TLS-Terminierung und erweiterte HTTP-Funktionen benötigen, verwenden Sie einen ALB und terminieren Sie TLS am ALB (mit von ACM verwalteten Zertifikaten). Um die Client-IP für die Protokollierung und für WAF-Regeln beizubehalten, lesen Sie den X-Forwarded-For-Header aus, den der ALB einfügt, oder verwenden Sie eine Schicht, die die ursprüngliche Client-IP in die Header injiziert. Wenn der Betriebssystem-/Netzwerk-Stack des Backends die Client-IP auf Socket-Ebene sehen muss, verwenden Sie einen NLB (oder aktivieren Sie das Proxy Protocol, um die ursprüngliche IP zu übergeben). Beachten Sie jedoch, dass das Proxy Protocol in der Zielgruppe aktiviert sein muss und Ihre Anwendung oder Ihr Proxy (z. B. Envoy) es verarbeiten können muss.

Die Handhabung von Sticky Sessions in einer Autoscaling-Umgebung erfordert sorgfältige Überlegungen. Die ALB-Cookie-Stickiness kann einen Client für eine bestimmte Dauer an ein Ziel binden, was eine ausgewogene Skalierung über Pods hinweg behindern kann, wenn der Sitzungs-Traffic hoch ist. Alternative Muster umfassen die Verwendung von kurzzeitiger Stickiness in Kombination mit der Externalisierung des Sitzungszustands nach ElastiCache (Redis) oder DynamoDB oder die Verwendung eines Sidecar-Proxys (Envoy) zur Handhabung der Sitzungsaffinität mit konsistentem Hashing. Connection Draining (Deregistrierungsverzögerung) ist für ein kontrolliertes Herunterfahren (Graceful Shutdown) entscheidend: Setzen Sie deregistration_delay.timeout_seconds auf eine Dauer, die länger ist als die längste RPC/HTTP-Anfrage, um abrupte Beendigungen und Client-Fehler während der Pod-Terminierung zu vermeiden. Konfigurieren Sie Kubernetes preStop-Hooks, um den Lebenszyklus des Pods mit der Deregistrierung zu koordinieren.

GWLB ist das geeignete Muster, wenn Sie eine skalierbare Inline-Inspektion über viele VPCs hinweg benötigen und zentralisierte Sicherheitskontrollen wünschen. Kombinieren Sie GWLB bei Bedarf mit Transit-Gateway- oder VPC-Peering-Architekturen. Die Kosten und die betriebliche Komplexität der Appliance-Verwaltung sind die Kompromisse im Vergleich zur Nutzung von Managed Services wie AWS Network Firewall.

Häufige Fallstricke und Entscheidungskriterien

Ein häufiger Fehler ist die Beendigung von TLS am ALB, ohne die nachgelagerten Anforderungen an die Client-Authentifizierung oder die ursprüngliche Quell-IP zu berücksichtigen. Wenn Backends das Client-Zertifikat oder die wahre Quell-IP auf der TCP-Ebene (für Protokollierung oder Autorisierung) benötigen, beenden Sie TLS am Backend über NLB-Passthrough oder verwenden Sie das Proxy Protocol und stellen Sie sicher, dass die Anwendung es parst. Ein weiterer häufiger Fallstrick ist die Aktivierung von Sticky Sessions ohne externen Session-Speicher bei Verwendung des Horizontal Pod Autoscaler: Wenn Pods auf- oder abskalieren, kann die Sticky-Affinität Hotspots und verschwendete Kapazität erzeugen; bevorzugen Sie zustandslose Backends oder externalisieren Sie den Sitzungszustand.

Betriebsfehler entstehen auch durch falsch konfigurierte Health Checks und Deregistrierungsverzögerungen, die zu Anfrageverlusten während der Skalierung führen. Legen Sie die Pfade und Schwellenwerte für Health Checks immer so fest, dass sie die Aufwärmphase der Anwendung widerspiegeln, und verwenden Sie deregistration_delay.timeout_seconds, um langlebigen Verbindungen ein ordnungsgemäßes Beenden (Draining) zu ermöglichen. Cross-Zone Load Balancing sollte bewusst eingestellt werden: Die Aktivierung reduziert die Tail-Latenz und gleicht die Last aus, kann aber die Kosten für den zonenübergreifenden Datentransfer erhöhen; bewerten Sie dies anhand der AZ-Kapazität und der Traffic-Muster. Schließlich führt GWLB einen Kapselungs- (GENEVE) und Appliance-Management-Overhead ein – automatisieren Sie die Registrierung der Appliance mithilfe der AWS-APIs (CreateTargetGroup/RegisterTargets) und instrumentieren Sie sie mit CloudWatch-Metriken, um Autoscaling-Richtlinien zu steuern.

Praktisches Problem: Anwendungsfallszenario

Unternehmen: Acme Telemetry. Herausforderung: Bereitstellung einer Ende-zu-Ende-Verschlüsselung für einen gRPC-Dienst (gRPC über TLS auf TCP-Port 443), der in einem Amazon EKS-Cluster bereitgestellt wird, Unterstützung von Tausenden gleichzeitiger, langlebiger Verbindungen, Verwendung von Kubernetes Cluster Autoscaler und HPA sowie die Anforderung von mutual TLS (mTLS), sodass das Client-Zertifikat vom Backend validiert wird (d. h., der Datenverkehr darf von keinem zwischengeschalteten Load Balancer entschlüsselt werden).

1. Ansatz zur Umsetzung des Anwendungsfalls: Stellen Sie einen Network Load Balancer mit einem TCP-Listener auf Port 443 und einer Zielgruppe vom Typ „ip“ bereit, die auf Pod-IPs verweist. Erstellen Sie den NLB mit

undefined

, erstellen Sie die Zielgruppe mit

undefined

, registrieren Sie die Ziele über die Annotationen des AWS Load Balancer Controllers für Kubernetes (

undefined

), sodass der Controller die Pod-IPs automatisch registriert, und erstellen Sie den Listener mit

undefined

. Setzen Sie das Zielgruppenattribut deregistration_delay.timeout_seconds auf einen angemessenen Wert (z. B. 300) mit

undefined

, um ein ordnungsgemäßes Draining (graceful draining) zu ermöglichen.

2. Backend-TLS- und mTLS-Konfiguration: Beenden Sie TLS und führen Sie mutual TLS auf der Pod-Ebene durch. Stellen Sie Envoy-Sidecars bereit oder lassen Sie die gRPC-Server TLS direkt akzeptieren, indem Sie Serverzertifikate und CA-Bundles in Kubernetes Secrets speichern und in den Pod einbinden (mounten). Konfigurieren Sie die Backends so, dass sie Client-Zertifikate gegen Ihre CA validieren, und konfigurieren Sie die Health Checks so, dass sie TCP verwenden, um eine TLS-Beendigung am Load Balancer zu vermeiden. Stellen Sie sicher, dass die Lebenszyklus-Hooks von HPA und Cluster Autoscaler mit der Deregistrierung der Zielgruppe koordiniert werden, indem Sie preStop-Hooks implementieren, die es den Pods ermöglichen, das Draining vor dem Beenden abzuschließen.

3. Skalierbarkeit und betriebliche Steuerung: Aktivieren Sie bei Bedarf Cross-Zone Load Balancing auf dem NLB mit

undefined

, um Verbindungen gleichmäßig über die AZs zu verteilen. Überwachen Sie gleichzeitige Verbindungen und Flussraten mit CloudWatch-Metriken (NetworkPackets, ActiveFlowCount für NLB) und legen Sie Autoscaling-Richtlinien für die Appliance (falls ein Sidecar verwendet wird) und für die Worker-Nodes fest. Verwenden Sie ModifyTargetGroupAttributes für das Connection Draining und passen Sie die Health-Check-Intervalle an, um eine schnellere Fehlererkennung ohne Flapping zu erreichen. Automatisieren Sie schließlich die Zertifikatsrotation mithilfe von AWS Secrets Manager und der Kubernetes-Integration von cert-manager.

Begründung seitens AWS: Der NLB im TCP-Modus erhält die TLS-Sitzung Ende-zu-Ende aufrecht, sodass das Backend die mTLS-Validierung durchführen kann; seine L4-Architektur ist für Millionen gleichzeitiger Flüsse und langlebige Verbindungen ausgelegt, und die Verwendung des Zieltyps „ip“ ermöglicht es dem AWS Load Balancer Controller, Pod-IPs direkt zu registrieren, was es HPA/Cluster Autoscaler ermöglicht, transparent zu skalieren. Connection Draining (deregistration_delay) und Health Checks verhindern Anfrageverluste während der Pod-Terminierung, und Cross-Zone Balancing stellt eine gleichmäßige Verteilung über die AZs sicher, wobei ein Kompromiss zwischen den Kosten für den Inter-AZ-Transfer und der Leistung eingegangen wird.

← DNS und Route 53 · Alle Domänen · Netzwerksicherheit und Compliance →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →