Amazon Application Recovery Controller (ARC)
AZ 障害からの退避とマルチリージョン復旧を制御。Zonal Shift / Autoshift、Routing Control、Region Switch で切り替えと復旧手順を安全に実行する Amazon ARC。
- Zonal Shift / Autoshift で対応リソースのトラフィックを問題のある AZ から一時退避する。
- Routing Control と安全規則でマルチリージョンの流入を制御し、Region Switch で復旧手順を統制する。
- Readiness Check は2026年4月30日以降の新規顧客には提供されず、新規設計の前提にしない。
解決する課題
- マルチリージョン / AZ 構成にしたのに、いざという時に本当に切り替わるか自信が持てない
- 復旧先のキャパシティや設定がずれていて、フェイルオーバーした先で受けきれない
- 障害の最中はコントロールプレーンが不安定になりがちで、肝心なときに切替操作ができない
- DNSフェイルオーバーの自動化が、誤検知で意図しない切り替えを起こすのが怖い
主要概念と用語
- Zonal Shift: 操作者が対応リソースのトラフィックを指定 AZ から一時的に退避する。AZ 単位の障害や保守で、影響を受けていない AZ に処理を寄せる
- Zonal Autoshift: AWS が潜在的な AZ 障害を検知したときに退避を開始する。平常時の練習実行で、残りの AZ が負荷を受けられるか継続確認する
- Routing Control: 複数リージョンやセルへの流入可否を表すオン / オフの制御。Route 53 ヘルスチェックと DNS ルーティングへ連動できる
- 安全規則: Routing Control の危険な組み合わせを拒否するガードレール。全セル停止などの誤操作を防ぐ
- Region Switch: マルチリージョン復旧の手順を復旧計画として定義し、実行・監視・ロールバックを統制する
- Readiness Check: 復旧先の容量や構成差を監査する従来機能。2026年4月30日以降の新規顧客には提供されず、既存顧客のみ利用可能
仕様・制限・クォータ
- Zonal Shift / Autoshift は対応する AWS リソースが対象で、すべてのリソースを任意に退避できるわけではない
- AZ 退避後は残りの AZ で全負荷を処理するため、平常時から十分な余力と練習実行が必要になる
- Routing Control の状態は複数リージョンに分散した高可用なクラスターエンドポイントから操作する
- Routing Control は Route 53 ヘルスチェックを介して DNS のフェイルオーバーへ連動できるが、データ複製やアプリ復旧は行わない
- Region Switch の復旧計画には実行手順と承認・監視を組み込み、対象リージョン側の依存関係は利用者が整備する
- Readiness Check を新規顧客向けの設計要素として採用しない。既存利用者は移行方針と提供条件を公式情報で確認する
内部の仕組み
横にスクロール
AZ 単位の障害では、Zonal Shift が対応リソースへの新しいトラフィックを指定 AZ から退避します。Zonal Autoshift を有効にすると AWS の障害シグナルで退避を開始でき、練習実行により残りの AZ だけで負荷を処理できるか検証します。ARC が容量を増やすわけではないため、N 個の AZ で通常運用していても、1 AZ を外した状態で必要容量を満たす設計が前提です。
リージョン単位の復旧では Routing Control の高可用なクラスターエンドポイントから制御状態を変更し、その状態を Route 53 ヘルスチェックと DNS ルーティングへ反映できます。安全規則は全セル停止など危険な状態遷移を拒否します。Region Switch は、DNS や計算資源、依存サービスなど複数の手順を復旧計画として統制し、リージョン切り替えの実行状況を追跡します。
ARC はトラフィックの退避・切り替えを制御する面であり、データ複製、接続中セッションの移送、アプリの整合性回復を代行しません。Readiness Check は従来の構成監査機能ですが、2026年4月30日以降の新規顧客には提供されません。新規設計ではこの機能を中核にせず、Infrastructure as Code の差分検査、継続的な復旧試験、容量監視で準備状況を検証します。
単一 AZ の問題なら Zonal Shift / Autoshift、複数リージョンの流入制御なら Routing Control、複数手順を含む復旧なら Region Switch を検討します。障害範囲より大きい切り替えは、影響と復旧時間を不必要に増やします。
設計パターン / ベストプラクティス
- Zonal Autoshift の練習実行を使い、1 AZ を外した容量と依存関係を継続検証する
- リージョンごとに障害を閉じ込めるセルを作り、データ複製と依存サービスも同じ境界で設計する
- 安全規則で「最低 1 セルは有効」「全停止を禁止」などのガードレールを敷く
- Region Switch の復旧計画に判断点、承認、タイムアウト、ロールバック条件を明記する
- 切り替え演習を定期実施し、DNS、接続中セッション、データ整合性、待機側容量まで実測する
運用・監視
- Zonal Shift / Autoshift の開始・終了、Routing Control の状態変更、Region Switch の実行を監査する
- 練習実行の取消率や容量不足を追跡し、AZ を一つ失っても処理できる余力を維持する
- 障害時の切り替え手順を Runbook 化し、クラスターエンドポイントを使った操作を訓練する
- CloudWatch と Route 53 の状態を組み合わせ、切り替え前後の流入先とアプリ正常性を確認する
コスト
- ARC の料金は利用機能ごとに異なるため、Routing Control、Region Switch、既存顧客の Readiness Check を分けて見積もる
- 復旧先の計算資源、データ複製、監視、定期訓練の費用は ARC とは別に発生する
- 高可用な復旧基盤を常時維持する費用と、許容停止時間・損失額を比較して保護対象を決める
- 具体的な料金と無料提供の範囲は変わりうるため、最新の料金ページで対象機能ごとに確認する
セキュリティ
- ルーティングコントロールの切替やパネル操作はIAMで権限を分離し、本番切替を行える主体を限定する
- セーフティルールにより、権限を持つ操作者でも危険な一括停止を構造的に防ぐ
- すべての操作をCloudTrailに記録し、フェイルオーバーの意思決定を後から検証できるようにする
- 復旧先セルのセキュリティ設定(セキュリティグループ、暗号化など)も準備状況の一部として本番と整合させる
関連サービス・比較
| 観点 | Amazon ARC | Route 53 ヘルスチェック単体 |
|---|---|---|
| 主目的 | AZ 退避とマルチリージョン復旧制御 | エンドポイント死活監視 |
| 切替の主体 | 手動・AWS シグナル・復旧計画 | ヘルスチェック結果 |
| 安全性 | 安全規則・練習実行・実行追跡 | DNS 方針を利用者が設計 |
| 復旧手順 | Region Switch で複数手順を統制 | DNS 応答の切り替えのみ |
| 向く用途 | AZ 障害退避・重要システムの復旧 | 一般的な DNS 自動切替 |
ハンズオン / 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
# 既存顧客のみ: 準備状況チェックの結果を確認する
# 2026年4月30日以降の新規顧客には提供されない
aws route53-recovery-readiness get-readiness-check-status \
--readiness-check-name app-region-readiness
AWS Service
Amazon Application Recovery Controller (ARC)を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
ネットワーキング
比較で見る軸
クラウド: AWS / カテゴリ: ネットワーキング / 難易度: intermediate
導入後に効く点
Routing Control と安全規則でマルチリージョンの流入を制御し、Region Switch で復旧手順を統制する。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- ネットワーキング
- 難易度
- intermediate
- 関連資格
- ANS-C01 / SAP-C02 / SOA-C02
- 設計柱
- reliability / operational
判断チェックリスト
- 自社の用途が「ネットワーキング / reliability」に近いか確認する。
- 強みである「Zonal Shift / Autoshift で対応リソースのトラフィックを問題のある AZ から一時退避する。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。