Eine Webanwendung läuft auf EC2-Instances in privaten Subnetzen über drei Availability Zones hinweg hinter einem ALB. SSL/TLS wird am ALB unter Verwendung von ACM-Zertifikaten terminiert. Beim Testen mit einer einzelnen Instance funktionierte alles, aber nach der Produktionsbereitstellung können sich Benutzer anmelden, doch jede neue Webanfrage startet den Anmeldevorgang neu. Was sollte der Netzwerkingenieur tun, um dies zu beheben?

Das Problem, dass sich Benutzer anmelden, aber jede neue Anfrage den Anmeldevorgang neu startet, deutet auf einen Verlust der Session-Persistenz hin. Dies geschieht, wenn Anfragen von demselben Benutzer nicht immer an dieselbe Backend-Instanz gesendet werden, was die Session-Informationen unterbricht. Die Aktivierung der Stickiness auf der Zielgruppe des Application Load Balancers (ALB) stellt sicher, dass Anfragen von einem bestimmten Client für eine konfigurierte Dauer an dieselbe EC2-Instanz weitergeleitet werden. Ein anwendungsbasiertes Cookie ist hierfür die geeignete Methode. Die maximale Anwendungs-Session-Länge sollte als Dauer eingestellt werden, um die Session-Integrität zu gewährleisten. Die Änderung der ALB-Listener-Konfiguration ist nicht der richtige Ort für Stickiness. Ein Network Load Balancer (NLB) arbeitet auf Schicht 4 und bietet keine anwendungsbasierte Stickiness. Das Entfernen des ALB und die Verwendung von Route 53 löst das Problem der Session-Persistenz nicht und würde die SSL/TLS-Terminierung auf die EC2-Instanzen verlagern, was komplexer und weniger skalierbar ist.