グローバルEC企業が、us-east-1で運用する基幹オーダー処理システムをマルチリージョン構成に強化しようとしています。現在の構成は次の通りです：Aurora MySQL クラスター（ライター1台＋リーダー2台）、複数のECS Fargateマイクロサービス（複数サービスにまたがる複雑なトランザクション処理）、ElastiCache Redis クラスター（セッションキャッシュ）、DynamoDB Global Tables（us-east-1/eu-west-1でセッションデータを管理）。ピーク時に毎時5万件のオーダーを処理しています。 新たなビジネス要件：RTO（目標復旧時間）≦ 15分、RPO（目標復旧時点）≦ 1分。予算制約として、セカンダリリージョン（eu-west-1）のインフラコストはプライマリリージョンの30%以内。すべてのデータはAWSマネージドサービス上に保持する規制要件があります。 すべての要件を最小コストで満たす構成はどれですか？
Aurora MySQLをAurora Global Databaseに変換して（リージョン間RPO < 1秒、RTO < 1分）、ElastiCacheにGlobal Datastoreを有効化し、eu-west-1のECS Fargateサービスをプライマリの25%キャパシティで常時起動してAuto ScalingでフェイルオーバーRTO内にフルキャパシティへスケールアウトするよう設定し、Route 53 Application Recovery Controller（ARC）のReadiness CheckとRoutingコントロールでフェイルオーバーを自動オーケストレーションします。Aurora Global Databaseはリージョン間でRPO（目標復旧時点）< 1秒・RTO（目標復旧時間）< 1分を実現し、ElastiCache Global Datastoreもサブ秒レプリケーションに対応します。セカンダリを25%キャパシティで起動しAuto Scalingを設定することでコスト30%制約を満たしながらRTO 15分内にフルキャパシティへスケールアウト可能です。Route 53 ARCはReadiness Checkで切り替え前の準備状態を検証し、シンプルなフェイルオーバーより信頼性の高いフェイルオーバーを実現します。 選択肢Bは、セカンダリリージョンのECS Fargateをフルキャパシティで常時運用するため、コスト30%制約を超過します。 選択肢Cは、AuroraクロスリージョンリードレプリカのRPOが数分単位となりRPO 1分の要件を満たせません。また別クラスターへのDMSレプリケーションはAurora Global Databaseより管理負荷が高くなります。 選択肢Dは、AuroraリカバリをAWS Backupのスナップショットに依存するため復旧RPOが数時間単位となりRPO 1分要件を満たせません。またAWS Elastic Disaster Recovery（DRS）はEC2ベースのワークロード向けであり、ECS Fargateには適用できません。