背景

コンテナイメージにおけるデプロイ戦略には、 Rolling update Blue/Green Deployment Canary Deployment という主要な3つの手法が知られています。

Amazon ECSは Rolling update をネイティブにサポートしております。また他の2つの手法も、AWS CodeDeployやAWS ALB / Route53などの別サービスと組み合わせることで実現可能です。

これまでAWSでは、Blue/Green Deploymentを実現するために、CodeDeployを使った方法が案内されていました。今回のリリースによりECSがネイティブにBlue/Green Deploymentをサポートしたことで、以下のような改善点があります。

ECSおよび周辺リソースのみで完結できる: CodeDeployによるBlue/Green Deploymentを行うには、CodeDeploy Application/Deployment、ECSを操作するためのIAMロール、 AppSpec などといったリソースが必要です。これらが一気に不要となり、運用コストが削減されます。
デプロイ戦略の切り替えが容易に可能: CodeDeploy利用時はRolling updateとBlue/Green Deploymentの手法を切り替える際、ECSサービスの再作成が必要な場合がありました。ネイティブではサービス作成後も切り替えが可能となり、運用コストの削減が見込めます。
Service Connectに対応: ECSはService Connectという機能でECSサービス間の通信を実現できます。CodeDeployはService ConnectによるBlue/Green Deploymentは非対応でしたので、本リリースでより高度なデプロイも実現可能となりました。
設定情報の集約: CodeDeployではELB/Target groupに関連する設定変更は AppSpec を介して行う必要がありました。ネイティブではこれらがECSサービス定義に統合されるため、より一貫性のある管理が可能です。

※参考:

dev.to

またこのほかにも、デプロイライフサイクルのステージごとにLambda関数で定義したロジックを用いて成否を判定したり（Deployment lifecycle hook）、テスト用Listener / Listener Ruleにより切り替え前に新環境を評価するDark Canaryの実現、といった機能も利用可能です。

なおAWSドキュメントではECSネイティブなBlue/Green Deploymentを推奨するほか、CodeDeployからECSネイティブへの移行方法も案内されています。そのため今後該当機能を利用する場合はECSネイティブの方を念頭に置くべきでしょう。

docs.aws.amazon.com