大手小売企業が、オンプレミスの物理サーバー（RHEL 7）上のApache Tomcatで稼働するJava Webアプリケーション220本のコンテナ化を計画しています。アプリケーションの年齢は5〜15年で、コードの変更なしにAmazon ECSまたはAmazon EKSへの移行を実現する必要があります。 【要件】 ・アプリケーションコードの変更なしにコンテナ化する ・ECSタスク定義またはKubernetesマニフェスト（デプロイYAML）を自動生成する ・Amazon ECRへのイメージプッシュを含むCI/CDパイプライン統合を自動化する ・各アプリケーションの依存関係・ポートマッピング・環境変数を自動検出する 【制約】 ・移行期間は6ヶ月 ・アプリケーション開発チームは移行作業に参加できない ・運用チームのコンテナ・Docker知識は限られている ・220本すべてに対して手動でのDockerfile作成は工数的に不可能 このシナリオで最も適切なアプローチはどれですか？
AWS App2Container（A2C）は、コンテナ化されていないJavaおよび.NETアプリケーションを自動的にコンテナ化するためのコマンドラインツールです。実行中のTomcatプロセスを分析して依存関係・ポートマッピング・環境変数を自動検出し、Dockerイメージを生成します。ECSタスク定義またはKubernetesマニフェスト、CodePipelineのIaCテンプレートも自動生成するため、コンテナ知識が限られたチームが220本を効率的に処理できます。アプリケーションコードの変更も不要です。 選択肢Bは誤りです。Migration Hubはインベントリ管理・移行追跡ツールであり、コンテナ化機能を持ちません。Dockerfileの手動作成は220本のアプリケーションに対して非現実的で、開発チームが参加できないという制約にも違反します。 選択肢Cは誤りです。Elastic BeanstalkはWARファイルを直接デプロイできますが、ECSタスク定義やKubernetesマニフェストを生成するコンテナ化ツールではありません。「ECSまたはEKSへのコンテナ移行」という要件を満たしません。 選択肢Dは誤りです。EC2へのリフトアンドシフトはコンテナ化を実現しません。「段階的に手動でDockerfileを作成」という計画は6ヶ月の制約と手動作業不可という制約の両方に違反します。