Amazon Route 53 Application Recovery Controller

解決する課題

• マルチリージョン/AZ構成にしたのに、いざという時に本当に切り替わるか自信が持てない
• 復旧先のキャパシティや設定がずれていて、フェイルオーバーした先で受けきれない
• 障害の最中はコントロールプレーンが不安定になりがちで、肝心なときに切替操作ができない
• DNSフェイルオーバーの自動化が、誤検知で意図しない切り替えを起こすのが怖い

主要概念と用語

• 準備状況チェック（Readiness Check）: 復旧先のリソースが本番と同等に整っているかを継続的に監査する仕組み。容量や設定の食い違いを事前に可視化する
• リカバリーグループ / セル: アプリ全体を表すグループと、リージョンやAZ単位の独立した区画（セル）。セルごとの準備状況を束ねて確認する
• ルーティングコントロール: 各セルへトラフィックを流すかどうかを表すオン/オフのスイッチ。状態の変更がRoute 53のヘルスチェックを通じてDNSへ反映される
• ルーティングコントロールパネル: 複数のルーティングコントロールをまとめる入れ物
• セーフティルール: 切替操作のガードレール。同時にすべてを落とさない、最低1つは有効に保つ、といった条件を強制する
• クラスター: ルーティングコントロールの状態を保持・提供する、複数リージョンに分散した高可用なエンドポイント群

仕様・制限・クォータ

• 大きく準備状況（Readiness）とルーティングコントロールの2つの機能で構成される
• ルーティングコントロールの状態は、複数リージョンに分散した5つのクラスターエンドポイントから提供され、障害時でも操作できるよう設計されている
• ルーティングコントロールの状態変更は、Route 53のヘルスチェックを介してDNSのフェイルオーバーに連動する
• クラスターは時間課金、準備状況チェックは監査対象の単位で課金されるなど、機能ごとに料金体系が分かれる
• リソース数やパネル数などにはクォータがあり、必要に応じて引き上げを申請する

内部の仕組み

ARCの肝は、コントロールプレーンとデータプレーンを切り分けて高可用にしている点です。ルーティングコントロールの状態は専用のクラスターで保持され、このクラスターは複数のAWSリージョンにまたがる5つのエンドポイントから状態を提供します。障害でいずれかのリージョンが不調でも、残りのエンドポイント経由で状態を読み書きでき、最も壊れてほしくない切替操作を守ります。

ルーティングコントロールをオン/オフすると、その状態が紐づくRoute 53ヘルスチェックの結果として扱われ、フェイルオーバールーティングがDNS応答を切り替えます。つまり「人が押すスイッチ」をヘルスチェックの形に変換し、Route 53の既存のDNSフェイルオーバー機構に乗せている、という構造です。

一方の準備状況チェックは、復旧先のセルが本番と同等かを継続監査し、容量や設定のドリフトを検出します。これは「切り替わるか」ではなく「切り替えた先が受けきれるか」を担保する役割です。

設計パターン / ベストプラクティス

• アプリを**セル（リージョン/AZ単位）**に分け、セルごとにルーティングコントロールを用意する
• 準備状況チェックを常時回し、復旧先の容量・設定ドリフトを切替前に解消しておく
• セーフティルールで「最低1セルは有効を維持」「全停止を禁止」などのガードレールを敷く
• 切替演習を定期実施し、リハーサル済みの状態を保つ（リハーサルしていない復旧計画は信用しない）
• 状態の読み取りには、リージョンに依存しないクラスターエンドポイント全体を順に試す実装にする

運用・監視

• ルーティングコントロールの状態変更は監査ログとして残し、誰がいつ切り替えたかを追跡する
• 準備状況がNOT READYになったセルをアラート化し、復旧能力の劣化を早期に把握する
• 障害時の切替手順をRunbook化し、クラスターエンドポイントを使った操作をすぐ実行できるようにする
• CloudWatchやヘルスチェックの状態と組み合わせ、切替の前後で配信先が想定どおり変わったか確認する

コスト

• クラスターはルーティングコントロールの可用性を支える基盤で、稼働時間に対して課金される
• 準備状況チェックは監査対象の単位に応じた課金で、対象を増やすほど費用が増える
• 高可用なフェイルオーバー基盤を常時維持するための固定的なコストがかかるため、保護対象を重要システムに絞ると効率的
• 具体的な料金は変動するため、最新の料金ページで対象機能ごとに見積もる

セキュリティ

• ルーティングコントロールの切替やパネル操作はIAMで権限を分離し、本番切替を行える主体を限定する
• セーフティルールにより、権限を持つ操作者でも危険な一括停止を構造的に防ぐ
• すべての操作をCloudTrailに記録し、フェイルオーバーの意思決定を後から検証できるようにする
• 復旧先セルのセキュリティ設定（セキュリティグループ、暗号化など）も準備状況の一部として本番と整合させる

関連サービス・比較

ハンズオン / CLI例

# ルーティングコントロールの現在の状態を確認する
# クラスターの可用なエンドポイント(リージョン)を指定して読み取る
aws route53-recovery-cluster get-routing-control-state \
  --routing-control-arn arn:aws:route53-recovery-control::123456789012:controlpanel/abcd1234/routingcontrol/efgh5678 \
  --region us-west-2

# プライマリセルを無効化し、セカンダリセルを有効化して切り替える
aws route53-recovery-cluster update-routing-control-states \
  --update-routing-control-state-entries \
    RoutingControlArn=arn:aws:route53-recovery-control::123456789012:controlpanel/abcd1234/routingcontrol/primary,RoutingControlState=Off \
    RoutingControlArn=arn:aws:route53-recovery-control::123456789012:controlpanel/abcd1234/routingcontrol/secondary,RoutingControlState=On \
  --region us-west-2

# 準備状況チェックの結果を確認する
aws route53-recovery-readiness get-readiness-check-status \
  --readiness-check-name app-region-readiness