グローバルな自動車部品製造企業が、オンプレミス東京データセンターのDR（Disaster Recovery：障害復旧）対策を強化しようとしています。現在の環境と要件は以下の通りです。 【現在の環境】 - 本番システム：VMware vSphere 7.0上の仮想マシン80台（SAP ERP、Oracle Database、カスタムJavaアプリケーション） - ストレージ：NetApp SAN（Storage Area Network：ネットワーク接続型ブロックストレージ）、総容量40TB - 現行DR：大阪第2データセンターへのVMware SRM（Site Recovery Manager）によるレプリケーション、RTO（Recovery Time Objective：目標復旧時間）4時間・RPO（Recovery Point Objective：目標復旧時点）15分 - ネットワーク：AWS東京リージョンへのAWS Direct Connect専用線（2Gbps） 【要件と制約】 - 日本の個人情報保護法（PIPA）により本番データは国内オンプレミス環境での維持が義務付けられており、AWSへの恒久移行は不可 - 改善目標：RTO 30分以内、RPO 5分以内 - オンプレミス本番環境を維持したままAWSをDRサイトとして活用する - DR訓練を本番環境への影響なしに定期実施できること - コスト最適化：DRサーバーは障害発生時のみ起動し、平時はストレージ・レプリケーション費用のみに抑えたい この要件を最も適切に満たすDRアーキテクチャはどれですか？
AWS Elastic Disaster Recovery（DRS）は継続的なブロックレベルレプリケーションにより実質的にRPO数秒・RTO数十分を実現します。本番環境をオンプレミスに維持したままAWSをDRサイトとして使用でき、PIPA規制要件を満たします。非破壊型ドリル機能により本番無影響でDR訓練が実施可能です。平時はステージングエリア（小型レプリケーションサーバーとEBSボリューム）のみ課金され、フルスペックEC2インスタンスは障害時にのみ起動するためコスト効率が高いです。 選択肢AのAWS Application Migration Service（MGN）は永続的なAWSへの「移行」専用サービスです。本番カットオーバーはオンプレミス廃止を意味しPIPA規制に違反します。テストカットオーバーはDRのための継続的スタンバイ維持には設計されていません。 選択肢CのAWS DataSyncはファイル・オブジェクトデータの転送ツールであり、ブロックレベルのVMレプリケーションには対応していません。障害時のVM Import変換処理には数時間かかりRTO 30分以内を達成不可能です。 選択肢DのVMware Cloud on AWS（VMC on AWS）は技術的には要件を満たせるが、VMC on AWSは専用ESXiホストが常時稼働するため継続的に高コストが発生します。「平時はストレージ費用のみ」というコスト要件を満たせず、DRSと比較して大幅にコストが高いです。