Une application web utilise un Application Load Balancer (ALB) pour acheminer le trafic vers des instances EC2 réparties sur trois zones de disponibilité. Une nouvelle version de l'application a été déployée dans une zone de disponibilité pour des tests. En cas de problème, l'entreprise doit détourner le trafic de cette zone de disponibilité jusqu'à ce que le déploiement soit annulé, tout en maintenant l'application disponible et stable. Quelle approche offre le comportement requis avec la plus grande efficacité opérationnelle ?

La désactivation de l'équilibrage de charge inter-zones sur le groupe cible de l'ALB garantit que le trafic reste dans la zone de disponibilité où il a été reçu. Ensuite, le lancement d'un décalage zonal (zonal shift) sur l'ALB permet de détourner tout le trafic entrant de la zone de disponibilité affectée vers les zones saines, isolant ainsi le problème sans impacter la disponibilité globale de l'application. Cette approche est efficace car elle est automatisée et réversible. Les autres options sont moins efficaces ou inappropriées : Supprimer manuellement les instances est une opération manuelle, sujette aux erreurs et non réversible facilement. Configurer le groupe cible pour hériter de l'ALB et lancer un décalage zonal ne fonctionnerait pas comme prévu car l'équilibrage de charge inter-zones de l'ALB distribuerait toujours le trafic aux instances des zones saines, même si le décalage zonal est actif. Le trafic serait toujours envoyé à la zone affectée s'il n'y a pas de décalage zonal. Supprimer le sous-réseau est une action drastique qui pourrait entraîner des problèmes de connectivité et n'est pas une solution temporaire pour détourner le trafic.