SSL-Terminierung und Sticky Sessions

SSL/TLS-Terminierung bedeutet, dass der Load Balancer eingehenden HTTPS-Datenverkehr entschlüsselt, die Klartext-HTTP-Anfrage (für Routing-Entscheidungen) untersucht und die Anfrage optional erneut verschlüsselt, bevor sie an das Backend weitergeleitet wird. Wenn die Terminierung am ALB erfolgt, können Ihre Anwendungsserver unverschlüsselten HTTP-Datenverkehr vom Load Balancer empfangen, wodurch die Konfiguration des Backends vereinfacht wird.

Die Terminierung am Load Balancer reduziert den CPU-Aufwand auf Anwendungsservern (kein TLS-Handshake pro Verbindung), ermöglicht inhaltsbasiertes Routing (für das HTTP-Header gelesen werden müssen) und zentralisiert die Zertifikatsverwaltung.

AWS Certificate Manager (ACM) stellt SSL/TLS-Zertifikate ohne zusätzliche Kosten bereit, verwaltet und verlängert sie. ALB und NLB lassen sich direkt in ACM integrieren: Sie wählen ein ACM-Zertifikat in der Konfiguration des HTTPS-Listeners aus, und der Load Balancer präsentiert es den Verbindungsanforderungen der Clients.

ACM-Zertifikate werden vor ihrem Ablauf automatisch verlängert – ohne manuelle Verlängerung und ohne Ausfallzeiten aufgrund abgelaufener Zertifikate. Bei öffentlichen Zertifikaten validiert ACM den Domainbesitz per DNS-Validierung (CNAME-Eintrag in Route 53) oder per E-Mail-Validierung. Für die interne Nutzung kann ACM Private CA private Zertifikate ausstellen.

SNI (Server Name Indication) ist eine TLS-Erweiterung, die es einer einzelnen IP-Adresse (und damit einem einzelnen ALB- oder NLB-Listener) ermöglicht, mehrere TLS-Zertifikate für unterschiedliche Domainnamen bereitzustellen. Der Client fügt den Hostnamen, den er erreichen möchte, in die TLS-ClientHello-Nachricht ein, woraufhin der Load Balancer das passende Zertifikat auswählt.

ALB unterstützt SNI nativ: Sie können einem einzelnen HTTPS-Listener mehrere ACM-Zertifikate zuweisen. Der ALB wählt anhand des SNI-Hostnamens des Clients automatisch das richtige Zertifikat aus. Dadurch sind weder ein separater Listener noch ein separater Load Balancer pro Domain erforderlich, was echtes virtuelles Hosting mit SSL ermöglicht.

ALB und NLB unterstützen konfigurierbare SSL-Sicherheitsrichtlinien, die festlegen, welche TLS-Protokollversionen und Cipher Suites der Load Balancer von Clients akzeptiert. AWS stellt vordefinierte Richtlinien bereit (z. B. ELBSecurityPolicy-TLS13-1-2-2021-06), die aktualisiert werden, sobald neue Schwachstellen entdeckt werden.

Compliance-Anforderungen können bestimmte TLS-Versionen vorschreiben: PCI-DSS 3.2.1 erfordert mindestens TLS 1.2; viele moderne Standards empfehlen, TLS 1.0 und 1.1 vollständig zu deaktivieren. Verwenden Sie eine Richtlinie, die veraltete Protokolle und schwache Cipher Suites ausschließt. Bevorzugen Sie Richtlinien mit TLS 1.3, um Forward Secrecy und eine bessere Leistung zu erreichen.

Zwei unterschiedliche TLS-Ansätze bei ALB:

• SSL-Terminierung (am häufigsten): Der ALB entschlüsselt die Daten am Load Balancer und leitet sie über unverschlüsseltes HTTP an die Targets weiter. Dies ist einfach, ermöglicht die Untersuchung für das Routing und reduziert die CPU-Auslastung der Server. Der Backend-Datenverkehr ist innerhalb der VPC unverschlüsselt.
• Ende-zu-Ende-TLS: Der ALB entschlüsselt die Daten und verschlüsselt sie vor der Weiterleitung an die Targets erneut (HTTPS zwischen ALB und Target). Dies erfordert mehr CPU-Leistung und Zertifikate auf den Targets, gewährleistet aber in strengen Compliance-Szenarien die Verschlüsselung innerhalb der VPC.

Im TLS-Pass-Through-Modus für NLB entschlüsselt der NLB überhaupt nichts, sondern leitet rohes TCP an das Target weiter, das TLS verarbeitet. Der Anwendungsserver verwaltet sein eigenes Zertifikat.

Sticky Sessions (auch Session Affinity genannt) stellen sicher, dass alle Anfragen desselben Clients innerhalb einer Target-Gruppe konsistent an dasselbe Target weitergeleitet werden. Dies ist für zustandsbehaftete Anwendungen erforderlich, die Sitzungsdaten im Speicher einzelner Server ablegen (statt in einem gemeinsam genutzten Cache wie ElastiCache).

Ohne Sticky Sessions könnte ein zustandsloser Load Balancer Anfrage 1 an Server A (der die Sitzung speichert) und Anfrage 2 an Server B (der keine Sitzungsdaten besitzt) senden. Dadurch könnte der Benutzer als abgemeldet erscheinen oder Inhalte seines Warenkorbs verlieren. Sticky Sessions binden einen Client für die Dauer der Sitzung an ein bestimmtes Target.

ALB unterstützt zwei Arten von Cookies für Sticky Sessions:

• Dauerbasierte Sitzungsbindung (vom Load Balancer erzeugtes Cookie): Der ALB erzeugt ein Cookie namens AWSALB (für ALB) und legt eine Ablaufdauer fest. Das Cookie enthält eine verschlüsselte Referenz auf das Target. Der Client sendet dieses Cookie bei nachfolgenden Anfragen mit.
• Anwendungsbasierte Sitzungsbindung: Dabei wird ein vorhandenes, von Ihrer Anwendung gesetztes Cookie verwendet. Der ALB liest den von Ihnen angegebenen Cookie-Namen, erzeugt in seinem eigenen Cookie eine verschlüsselte Version und verwendet diese für das Sticky Routing, während das ursprüngliche Anwendungscookie erhalten bleibt.

Konfigurieren Sie die Sitzungsbindung pro Target-Gruppe mit einer Dauer von 1 Sekunde bis zu 7 Tagen.

Sticky Sessions lösen zwar das Problem zustandsbehafteter Anwendungen, bringen jedoch Nachteile mit sich:

• Ungleichmäßige Lastverteilung: Einige Targets erhalten möglicherweise mehr Datenverkehr, wenn bestimmte Clients ungewöhnlich aktiv sind, wodurch der Zweck des Load Balancing beeinträchtigt wird
• Einschränkungen bei der Skalierung: Wird ein an Sticky Sessions gebundenes Target fehlerhaft, werden die Sitzungen unterbrochen. Der Client muss eine neue Sitzung mit einem neuen Target beginnen und verliert dabei möglicherweise im Speicher gehaltene Sitzungsdaten
• Geringere Elastizität: Sticky Sessions erschweren das Leeren und Beenden von Instances während Scale-in-Ereignissen

Best Practice: Vermeiden Sie die Notwendigkeit von Sticky Sessions, indem Sie den Sitzungsstatus in ElastiCache oder DynamoDB auslagern. Dadurch wird Ihre Anwendung wirklich zustandslos und vollständig horizontal skalierbar.

NLB unterstützt TLS-Listener auf Port 443 (oder einem beliebigen anderen Port) zur TLS-Terminierung, ähnlich wie ALB. Der NLB entschlüsselt den Datenverkehr, verschlüsselt ihn optional erneut und leitet ihn an die Targets weiter. Alternativ kann der NLB verschlüsselten TCP-Datenverkehr ohne Entschlüsselung durchreichen, wenn Sie einen TCP-Listener konfigurieren. In diesem Modus verarbeitet der Anwendungsserver TLS Ende zu Ende.

Die TLS-Terminierung des NLB mit ACM bietet dieselben Vorteile bei der Zertifikatsverwaltung wie ALB, jedoch ohne Funktionen auf HTTP-Ebene. Verwenden Sie die NLB-TLS-Terminierung, wenn Sie statische IP-Adressen mit TLS-Terminierung benötigen oder wenn Ihr Backend-Protokoll nicht HTTP-basiert ist (z. B. ein benutzerdefiniertes TCP-Protokoll).

Wenn ein Target mit Sticky Sessions deregistriert wird (z. B. während eines Scale-in von Auto Scaling), ermöglicht Connection Draining den Abschluss laufender Anfragen. Neue Anfragen von Sticky-Clients, die das AWSALB-Cookie für das auslaufende Target weiterhin besitzen, werden jedoch automatisch einem neuen Target zugewiesen. Das Cookie für Sticky Sessions wird für diesen Client ungültig gemacht.

Diese Kombination aus Deregistrierungsverzögerung und Cookie-Invalidierung sorgt für einen kontrollierten Übergang: Bestehende lang laufende Anfragen werden abgeschlossen, während neue Anfragen dieser Clients reibungslos an gesunde Targets umgeleitet werden, ohne für den Endbenutzer wie Fehler zu erscheinen.

Prüfungsrelevante Best Practices:

• Verwenden Sie ACM-Zertifikate zur automatischen Verlängerung – verwalten Sie Zertifikate auf Load Balancern niemals manuell
• Verwenden Sie Sicherheitsrichtlinien mit TLS 1.2+; deaktivieren Sie TLS 1.0/1.1 für die PCI-/HIPAA-Compliance
• Bevorzugen Sie zustandslose Architekturen (Sitzungen in ElastiCache/DynamoDB) gegenüber Sticky Sessions
• Verwenden Sie SNI bei ALB, um mehrere Domains über einen Listener bereitzustellen, ohne mehrere Zertifikate auf separaten Load Balancern zu benötigen
• Für strenge Compliance-Anforderungen (Daten innerhalb der VPC müssen verschlüsselt sein): Verwenden Sie HTTPS-Target-Gruppen mit Ende-zu-Ende-TLS und nicht nur eine Terminierung am Load Balancer

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

In dieser Lektion haben Sie gelernt: Die SSL/TLS-Terminierung von ALB mit ACM-Zertifikaten bietet automatische Verlängerung und SNI für mehrere Domains, SSL-Sicherheitsrichtlinien steuern TLS-Versionen und Cipher Suites für Compliance-Anforderungen, und Sticky Sessions leiten Benutzer an dasselbe Target weiter und eignen sich damit für zustandsbehaftete Anwendungen, sollten aber möglichst durch das Auslagern des Sitzungsstatus in ElastiCache ersetzt werden. Als Nächstes behandeln wir Auto Scaling Groups und Launch Templates.