小売企業が、オンプレミスで稼動する e コマースプラットフォームを AWS に移行することを決定しました。現在のシステムは以下の通りです。 ①Java EE アプリケーションサーバー（WebLogic 12c）× 20 台、各 32 コア/256GB RAM。 ②Oracle Database 12c RAC × 3 クラスター（合計 50TB）。 ③NFS ストレージ（NetApp）300TB、アプリケーションが共有ファイルシステムとして使用。 ④オンプレミス Active Directory（ユーザー数 50,000）。 ⑤専用線（1Gbps）でデータセンターと接続済み。移行要件： ①移行期間中のサービス停止を最大 4 時間に制限。 ②移行後 6 ヶ月以内に運用コストを 30% 削減。 ③WebLogic の特殊機能（EJB、JMS、JDBC 接続プール）への依存を長期的に排除する計画がある。この要件を満たす移行戦略として最も適切なものはどれですか？（2つ選択）
停止時間4時間・6ヶ月30%削減・長期的脱WebLogicの複合要件には、フェーズ1でRehost（現行スタックをAWSへ移行）、フェーズ2でモダナイゼーションを進める2段階戦略が現実的です。選択肢AとDはどちらもリホスト戦略で、4時間のダウンタイム制約内での移行完了が現実的なアプローチです。 選択肢BのECS FargateへのコンテナリゼーションはEJB（Enterprise JavaBeans：Javaの分散コンポーネント仕様）やJMS（Java Message Service：非同期メッセージング仕様）の依存解消に大規模なリファクタリングが必要です。EJB移行をフェーズ2に延期するとしても、コンテナ化自体が4時間のダウンタイム制約内での完遂には高リスクです。Aurora PostgreSQLへのDMS移行も並行実施するにはリスクが高すぎます。 選択肢CのStrangler FigパターンでWebLogic全機能をLambda + API Gateway + SQSに置き換え、50TBのOracle DBを完全移行し、さらにActive DirectoryをCognito User Poolsに置き換える作業を3ヶ月で完了させることは非現実的です。 選択肢EのElastic BeanstalkへのWebLogicデプロイは直接サポートされておらず、50TBのOracle DBのRDS for MySQLへの一括DMS移行も4時間制約内では非現実的です。