Aplikacja internetowa działa na instancjach EC2 w prywatnych podsieciach w trzech Strefach Dostępności za ALB. SSL/TLS jest terminowany w ALB przy użyciu certyfikatów ACM. Podczas testów z pojedynczą instancją wszystko działało, ale po wdrożeniu produkcyjnym użytkownicy mogą się logować, jednak każde nowe żądanie internetowe restartuje proces logowania. Co powinien zrobić inżynier sieci, aby to naprawić?

Problem polega na tym, że każde nowe żądanie internetowe restartuje proces logowania, co wskazuje na utratę stanu sesji. Dzieje się tak, ponieważ ALB domyślnie rozkłada ruch równomiernie między instancje, a kolejne żądania od tego samego użytkownika mogą trafiać na różne instancje, które nie posiadają informacji o jego sesji. Włączenie stickiness (lepkości sesji) na poziomie grupy docelowej ALB rozwiązuje ten problem. Atrybut stickiness gwarantuje, że żądania od tego samego klienta będą kierowane do tej samej instancji przez określony czas. Użycie pliku cookie opartego na aplikacji jest odpowiednie, ponieważ aplikacja może zarządzać czasem trwania sesji. Pozostałe opcje są nieprawidłowe: Modyfikacja konfiguracji listenera ALB w celu włączenia stickiness na poziomie grupy jest nieprecyzyjna; stickiness konfiguruje się w grupie docelowej. Zastąpienie ALB Network Load Balancerem nie jest właściwym rozwiązaniem, ponieważ NLB działa na warstwie 4 i nie obsługuje stickiness opartego na plikach cookie HTTP/HTTPS, które są niezbędne do utrzymania sesji aplikacji. Usunięcie ALB i użycie Route 53 z polityką failover nie rozwiąże problemu utraty sesji, ponieważ Route 53 nie zarządza stanem sesji aplikacji.