Une application web s'exécute sur des instances EC2 dans des sous-réseaux privés à travers trois zones de disponibilité derrière un ALB. SSL/TLS est terminé au niveau de l'ALB à l'aide de certificats ACM. Lors des tests avec une seule instance, tout a fonctionné, mais après le déploiement en production, les utilisateurs peuvent se connecter, mais chaque nouvelle requête web redémarre le flux de connexion. Que doit faire l'ingénieur réseau pour résoudre ce problème ?

Le problème décrit, où chaque nouvelle requête redémarre le flux de connexion, indique une perte de session. Cela se produit généralement lorsque les requêtes d'un même utilisateur sont acheminées vers différentes instances EC2, et que l'état de la session n'est pas partagé entre elles. L'ALB, par défaut, distribue les requêtes de manière équitable. Pour maintenir la session d'un utilisateur sur la même instance, il faut activer la persistance de session (sticky sessions) au niveau du groupe cible de l'ALB. L'utilisation d'un cookie basé sur l'application est préférable si l'application gère déjà ses propres sessions, car l'ALB peut alors s'aligner sur la durée de vie de ce cookie. Définir la durée sur la longueur maximale de la session de l'application garantit que la persistance dure aussi longtemps que nécessaire. Les autres options sont incorrectes car: La première option suggère d'activer la persistance au niveau du groupe, mais ne spécifie pas le type de cookie (ALB ou application) ni la configuration correcte. La deuxième option propose de remplacer l'ALB par un NLB, ce qui est inutile et ne résoudrait pas le problème de persistance de session au niveau applicatif, car le NLB opère à la couche 4. La quatrième option propose de supprimer l'ALB et d'utiliser Route 53, ce qui éliminerait la répartition de charge et la terminaison SSL/TLS, et ne résoudrait pas le problème de session.