Ein DevOps-Team stellt eine ECS-Anwendung hinter einem ALB mit CodeDeploy im Blue/Green-Modus (all-at-once) bereit. Eine kürzlich erfolgte Veröffentlichung führte zu einem starken Anstieg der Antwortzeiten und erforderte ein Rollback. Das Team wünscht sich einen Bereitstellungsansatz, der es ihm ermöglicht, eine neue Version zu beobachten, bevor der gesamte Traffic umgeleitet wird, und schnell ein Rollback durchzuführen, wenn die Antwortzeiten steigen. Welche Kombination von Schritten erfüllt dies?

Die Auswahl von CodeDeployDefault.ECSCanary10Percent5Minutes ermöglicht es, zunächst nur 10% des Traffics für 5 Minuten auf die neue Version umzuleiten. Dies bietet ein Beobachtungsfenster, bevor der gesamte Traffic umgeschaltet wird, und erfüllt die Anforderung, eine neue Version zu beobachten. Die Erstellung eines CloudWatch-Alarms für die ALB TargetResponseTime-Metrik, der bei Überschreitung eines Schwellenwerts ein Rollback auslöst, ist entscheidend, um bei steigenden Antwortzeiten schnell reagieren zu können. Dies automatisiert das Rollback basierend auf der kritischen Metrik, die im Problem genannt wurde. CodeDeployDefault.ECSLinear10PercentEvery3Minutes leitet den Traffic schrittweise um, bietet aber kein dediziertes Beobachtungsfenster, bevor der nächste Schritt erfolgt. Alarme für UnHealthyHostCount oder TargetConnectionErrorCount sind zwar nützlich, adressieren aber nicht direkt das Problem der steigenden Antwortzeiten, das im Szenario beschrieben wird.