ある企業は Amazon ECS（Fargate）上で稼働する API を AWS CodePipeline と AWS CodeDeploy で Blue/Green デプロイしています。新バージョンへ一度に全トラフィックを移すのではなく、最初の数分は 10% のみを新タスクセットに流し、アプリケーション固有の指標（カスタム CloudWatch メトリクスの 5xx エラー率）が悪化した場合は自動でロールバックしたいと考えています。さらに、本番トラフィックを流す前に新タスクセットへ合成リクエストを送って疎通確認を行いたいです。最小限の運用負荷でこれらを実現する構成はどれですか？
ECS の Blue/Green デプロイで段階的なトラフィック移行を行うには、CodeDeploy の事前定義デプロイ設定 CodeDeployDefault.ECSCanary10Percent5Minutes が最適です。最初に 10% を新タスクセットへ移し、5 分後に残り 90% を移行します。 デプロイグループにロールバックトリガーとして CloudWatch アラームを関連付けると、カスタム 5xx メトリクスのアラーム発火時に自動でロールバックされます。 本番トラフィックを流す前の疎通確認は、ライフサイクルフックの BeforeAllowTraffic で Lambda を実行して新タスクセットへ合成リクエストを送り、検証に失敗したらデプロイを停止できます。 選択肢Bの CodeDeployDefault.ECSAllAtOnce は段階移行ではなく全トラフィックを一度に移すため、Canary 要件を満たしません。 選択肢Cの手動承認は「自動ロールバック」の要件と運用負荷最小化に反し、過剰な作り込みになります。 選択肢Dの ECS ローリングアップデートは CodeDeploy の Blue/Green ではないため、ValidateService や BeforeAllowTraffic といった CodeDeploy のライフサイクルフックは使えません。