グローバル金融サービス会社がus-east-1（プライマリ）とeu-west-1（セカンダリ）でアクティブ/パッシブ構成の取引システムを運用しています。以下の要件を満たすフェイルオーバー方式を検討しています。 ①セカンダリリージョンのデータベースレプリケーションラグが許容範囲内かを自動検証してからフェイルオーバーする ②スプリットブレインを防止するためのセーフティガードを実装する ③オペレーターが単一の操作でフェイルオーバーを実行・取り消しできる ④フェイルオーバー制御のためのコントロールプレーン自体が高可用である 最もこれらの要件を満たすソリューションはどれですか？
Route 53 Application Recovery Controller（ARC）は、計画的・非計画的フェイルオーバーを安全に実行するために設計されたサービスです。 レディネスチェック（Readiness Checks）機能は、データベースのレプリケーションラグ・Auto Scalingキャパシティ・ターゲットグループの状態など、セカンダリリージョンの準備状態を継続的に監視します。 ルーティングコントロール（Routing Controls）はセーフティルールを設定することでスプリットブレインを防止し、オペレーターはAWSコンソール・CLI・SDKから単一操作でフェイルオーバーまたはロールバックが可能です。ARCのコントロールプレーン自体が複数のAWSリージョンにわたる高可用な設計になっているため、プライマリリージョン障害時にも操作継続できます。 選択肢BのRoute 53フェイルオーバールーティングポリシーはエンドポイントのヘルスチェックに基づく自動切り替えを提供しますが、データベースレプリケーションラグのレディネス検証やスプリットブレイン防止のセーフティルール機能はありません。 選択肢CのSystems Manager Automationはカスタムフェイルオーバーロジックを実装できますが、コントロールプレーン自体の高可用性確保・セーフティルール・レディネスチェックをすべてカスタム実装する必要があり運用負荷が高くなります。 選択肢DのGlobal Acceleratorはレイテンシ最適化とヘルスチェックによる自動フェイルオーバーを提供しますが、データベースのレプリケーションラグを検証するレディネスチェック機能やスプリットブレイン防止のセーフティルール機能はありません。