Een webapplicatie draait op EC2-instances in private subnets verspreid over drie Availability Zones achter een ALB. SSL/TLS wordt beëindigd bij de ALB met behulp van ACM-certificaten. Tijdens het testen met een enkele instance werkte alles, maar na de implementatie in productie kunnen gebruikers inloggen, maar elke nieuwe webrequest herstart de inlogprocedure. Wat moet de netwerkengineer doen om dit op te lossen?

Het probleem waarbij gebruikers na elke nieuwe request opnieuw moeten inloggen, duidt op een gebrek aan sessiepersistentie. De applicatie verliest de sessiestatus tussen requests. De correcte oplossing is om stickiness (sessie-affiniteit) in te schakelen op de ALB target group. Dit zorgt ervoor dat requests van dezelfde gebruiker consequent naar dezelfde EC2-instance worden gerouteerd, waardoor de sessiestatus behouden blijft. Het gebruik van een applicatie-gebaseerde cookie is ideaal omdat de applicatie de sessieduur kan bepalen. De andere opties zijn incorrect: Het wijzigen van de ALB listener configuratie voor group-level stickiness is geen standaardoptie en biedt niet de granulariteit van target group stickiness. Het vervangen van de ALB door een NLB is onnodig en een NLB werkt op laag 4, wat minder geschikt is voor applicatie-specifieke sessiebeheer. Het verwijderen van de ALB en het gebruik van Route 53 met certificaten op elke instance is een fundamentele architectuurwijziging die het probleem van sessiepersistentie niet oplost en de complexiteit onnodig verhoogt.