物流会社がオンプレミスWindows Server 2016で稼働する.NET Framework 4.7製Webアプリケーション（30のサービスコンポーネントがCOM+（Windowsのコンポーネントトランザクション基盤）とMSMQ（Microsoft Message Queuing：Windowsのメッセージキューサービス）で密結合）のAWSへの移行を計画しています。要件は以下のとおりです。 (1) ストラングラーフィグパターン（既存モノリスを稼働させながら機能を段階的に新サービスへ移行するアーキテクチャパターン）で18ヶ月かけてコンポーネントを段階的にコンテナ化 (2) コンテナ化中も既存モノリスを継続稼働 (3) 旧モノリスと新コンテナ間のトラフィックを段階的に%単位で切り替え (4) コードの大幅な書き直しは不可 (5) Windowsコンテナのサポートが必要 これらの要件を最も満たすアプローチはどれですか？
AWS App2ContainerはWindowsの.NETアプリケーションを自動分析してDockerfileとECS/EKS用デプロイアーティファクトを生成するツール。コードの書き直しなしにコンテナ化できるため「大幅な書き直し不可」要件を満たす。Amazon ECS Windows FargateはWindowsコンテナをフルマネージドで実行でき、モノリスと並行稼働が可能。ALBの加重ターゲットグループにより旧モノリスと新コンテナへのトラフィック比率を%単位で段階制御でき、ストラングラーフィグパターンの実装に最適。Amazon ECS Service ConnectによりECSネイティブにコンポーネント間の通信とサービスディスカバリを管理できる（AWS App MeshはEOL：2026年9月30日廃止・新規顧客受付は2024年9月24日停止済み）。 選択肢BのMGNはサーバー単位のリフト＆シフトツールであり、30コンポーネントをストラングラーフィグパターンで段階的にコンテナ化する用途には対応していない。Elastic BeanstalkもコンポーネントレベルでのBlue/Greenトラフィック分割制御は提供しない。 選択肢Cの.NET 8へのリプラットフォームはCOM+等のWindows固有APIを利用している既存コードの全面書き直しを必要とするため、コード変更不可の要件に根本的に反する。 選択肢DのLambdaは最大実行時間15分の制限があり、COM+ベースの長時間同期トランザクションには不適切。各コンポーネントのLambda化は実質的なリファクタリングを必要とし、コード書き直し不可の要件に反する。