Une entreprise exécute sa logique métier principale sur un parc d'instances Amazon EC2 au sein d'un groupe Auto Scaling derrière un Application Load Balancer (ALB). L'enregistrement Route 53 api.example.com pointe vers l'ALB. L'équipe de développement doit déployer une mise à jour majeure de la logique métier de telle sorte que, pendant une fenêtre de test, seulement 10 % des clients reçoivent la nouvelle version, et chaque client doit utiliser de manière cohérente la même version pendant toute la durée de la fenêtre de test. Comment l'entreprise doit-elle déployer la mise à jour pour satisfaire ces exigences ?

La bonne approche est de créer un second groupe cible sur l'ALB existant pour la nouvelle version. L'ALB peut ensuite être configuré pour utiliser le routage pondéré (weighted routing) entre les groupes cibles, dirigeant 10 % du trafic vers le nouveau groupe cible et 90 % vers l'ancien. L'activation de la persistance de groupe cible (target-group stickiness) garantit que chaque client reste cohéremment sur la même version (ancienne ou nouvelle) une fois qu'il a été routé, répondant ainsi à toutes les exigences. Les autres options sont incorrectes car : Créer un second ALB et utiliser le routage pondéré de Route 53 ne garantit pas la persistance de session au niveau de l'ALB, car Route 53 ne gère pas la persistance des requêtes une fois qu'elles ont atteint un ALB. Utiliser une politique AutoScalingRollingUpdate mettrait à jour toutes les instances progressivement, mais ne permettrait pas de contrôler le pourcentage de trafic vers la nouvelle version ni de maintenir la persistance pour les clients entre les versions. Modifier l'algorithme de routage de l'ALB en fonction du nombre de requêtes en attente le plus faible (LOR) et activer la persistance de session de l'ALB ne permet pas de contrôler le pourcentage de trafic vers la nouvelle version de manière spécifique (10 % dans ce cas).