Une équipe DevOps déploie une application ECS derrière un ALB en utilisant CodeDeploy avec un déploiement bleu/vert « all-at-once ». Une version récente a provoqué une forte augmentation des temps de réponse et a nécessité un rollback. L'équipe souhaite une approche de déploiement qui lui permette d'observer une nouvelle version avant de basculer tout le trafic et de revenir rapidement en arrière si les temps de réponse augmentent. Quelle combinaison d'étapes répond à ce besoin ?

La modification de la configuration de déploiement CodeDeploy en CodeDeployDefault.ECSCanary10Percent5Minutes permet de diriger un petit pourcentage (10%) du trafic vers la nouvelle version pendant une courte période (5 minutes) avant de basculer tout le trafic. Cela offre une période d'observation cruciale pour détecter les problèmes. La création d'une alarme CloudWatch sur la métrique ALB TargetResponseTime est essentielle car l'objectif est d'identifier les augmentations de temps de réponse. L'association de cette alarme au groupe de déploiement CodeDeploy et la configuration d'un rollback automatique garantissent une réponse rapide et automatisée en cas de dégradation des performances, répondant ainsi au besoin de revenir rapidement en arrière. CodeDeployDefault.ECSLinear10PercentEvery3Minutes est moins adapté car il bascule le trafic par étapes plus petites et plus fréquentes, ce qui peut ne pas offrir une période d'observation suffisante avant que tout le trafic ne soit basculé. ALB UnHealthyHostCount et ALB TargetConnectionErrorCount sont des métriques importantes, mais TargetResponseTime est la plus pertinente pour détecter une augmentation des temps de réponse, qui était le problème initial.