ある金融サービス企業は、クリティカルな決済処理を担うLambda関数の新バージョンをデプロイしようとしています。以下の要件があります。 ①新バージョンへのトラフィックを段階的に移行する（最初は全体の10%を新バージョンへ、エラー率が上昇しなければ10分後に残りの90%も移行） ②エラー率がCloudWatchアラームのしきい値を超えた場合、自動的に旧バージョンへロールバックする ③運用チームの手動介入を最小化する これらの要件を最も効率的に満たすデプロイ構成はどれですか？
AWS CodeDeployはLambdaデプロイをネイティブサポートしており、Canary（一定割合を先行投入→残りを一括移行）とLinear（均等に段階的移行）という2種類のデプロイ設定を提供します。CodeDeployDefault.LambdaCanary10Percent10Minutesを使用すると最初に10%を新バージョンに移行し、10分後に残りの90%を一括移行できます。デプロイグループにCloudWatchアラームを関連付けることで、エラー率上昇時にCodeDeployが自動でロールバック（Lambdaエイリアスのルーティングを元に戻す）する仕組みが組み込まれています。 選択肢BのALBはHTTPリクエストのルーティング用途であり、Lambdaの内部バージョン管理とは設計思想が異なります。Lambda関数を2つ並列運用する構成は管理が煩雑です。 選択肢CLambda@EdgeはCloudFrontのエッジロケーションでコードを実行するサービスであり、Lambda関数のバージョン間トラフィック分割を管理するものではありません。また手動ロールバックが必要です。 選択肢DのStep Functionsで定期的にLambda設定を更新することは技術的に可能ですが、CodeDeployのような組み込みの自動ロールバック機能がなく、運用負荷が大幅に増加します。