Application Recovery Controller（ARC）と DNS フェイルオーバー

ARC が解く問題

Application Recovery Controller（ARC） は、複数リージョン・複数 AZ にまたがるアプリケーションで、フェイルオーバー時に本当に安全に切り替えられるかを 準備状況（readiness） と ルーティング制御 の両面から支援します。

Route 53 の フェイルオーバールーティング＋ヘルスチェックだけでも「プライマリが死んだらセカンダリ」は実現できますが、実運用では次のような論点が残ります。

• セカンダリ側のキャパシティやスケール設定は本当にフェイルオーバーに耐えるか。
• 部分的な障害や誤検知でフラッピングしないか。
• 手動オーバーライドや段階的な切戻しをどう安全に行うか。

ARC はこれらに対して 準備状況チェック と ルーティングコントロール を提供します。SAA では 用語の意味合いと Route 53 単体との差が主な出題レベルです。

主要な構成要素（名前と役割）

用語	意味するもの（抽象）
セル（Cell）	アプリが独立して動く単位（例: あるリージョンの ALB＋Auto Scaling＋DB など）。AZ 単位など入れ子にもできる、という説明が資料でよく使われます。
リカバリグループ	フェイルオーバーを考えるシステム全体の束。複数セルを含む。
リソースセット	セルを横断して、同じ役割（例: フロントの ALB 群）をまとめた単位。
準備状況チェック	リソースセットが復旧やフェイルオーバーに備えて適切かを評価。
準備状況ルール	評価に使うルール（サービスごとに定義された基準と結びつく）。
クラスター	ルーティングコントロール用のエンドポイントを束ね、制御面の可用性を高める単位（複数リージョンにエンドポイントを持つ、という説明がなじむ）。
コントロールパネル	ルーティングコントロールをグルーピングする UI／論理単位。
ルーティングコントロール	DNS のフェイルオーバー挙動とヘルスチェックと連携し、どこへ出すかを制御するスイッチのようなもの。
安全ルール	誤ったフェイルオーバーや準備不足への切替を防ぐガードレール。

用語は多いですが、試験では 「準備を見てから／安全に切替」 という二段構えを覚えておくと文章が読みやすくなります。

Route 53 フェイルオーバー単体との関係

• Route 53 … DNS 応答とヘルスチェックによる切替の土台。
• ARC … その上に 準備状況とルーティングコントロール、安全ルールを載せ、運用上の安全を厚くする。

問題文に 「RTO を最優先にしたい」「アクティブ／パッシブだが待機系の準備を厳密に見たい」 などが出たら、ARC の選択肢を疑う、という読み方ができます。

設定の流れ（概念レベル）

細部はコンソールに譲りますが、概念の順序は次のような整理が学習資料でよく使われます。

1. リカバリグループとセルを定義し、リソースセットをセルに関連付ける。
2. 準備状況チェックをリソースセットに対して構成する。
3. クラスター／コントロールパネル／ルーティングコントロールを用意し、安全ルールを関連付ける。
4. Route 53 のフェイルオーバーと ヘルスチェックを、設計したルーティングコントロールと結びつける。

試験では 「どの順で何を定義するか」 の細部より、どのコンポーネントが何のためにあるかが問われやすいです。

あわせて読む（サイト内）

• フェイルオーバーとヘルス
• 信頼性の指標（RTO/RPO）
• ELB の信頼性機能

公式ドキュメント（短い導線）

• What is Application Recovery Controller?
• Route 53 Application Recovery Controller
• Readiness checks