Une entreprise dispose de 10 instances EC2 de serveurs web dans un groupe Auto Scaling au sein d'un VPC de production et de 10 serveurs web sur site. Une connexion Direct Connect de 10 Gbit/s relie le centre de données au VPC. La solution doit accepter le trafic HTTPS de milliers d'utilisateurs externes et répartir les sessions entre les serveurs AWS et les serveurs sur site. Chaque requête HTTPS doit rester associée au même serveur backend pour toute la durée de la session, quelle que soit la localisation du serveur. Quelle conception répond à ces exigences ?

La bonne réponse est de créer un ALB avec un type de cible IP et d'activer l'affinité de session. Un Application Load Balancer (ALB) est le choix approprié car il opère au niveau de la couche 7 (HTTP/HTTPS), ce qui est nécessaire pour le trafic HTTPS et l'affinité de session basée sur l'application. L'affinité de session (sticky sessions) garantit que les requêtes d'un utilisateur sont toujours envoyées au même serveur backend, qu'il soit sur AWS ou sur site, en utilisant des cookies. Le type de cible "ip" permet d'enregistrer des adresses IP, ce qui est essentiel pour inclure les serveurs sur site via Direct Connect. Les Network Load Balancers (NLB) opèrent au niveau de la couche 4 (TCP/UDP) et ne prennent pas en charge l'affinité de session basée sur l'application nécessaire pour les sessions HTTPS. Le type de cible "instance" ne permet pas d'enregistrer des serveurs sur site directement, car il attend des ID d'instance EC2.