Amazon Application Recovery Controller（ARC）とは？旧Route 53 ARCの機能・料金とCLI手順【2026年】

Amazon Application Recovery Controller（ARC）は、AWS上のアプリケーションを「1つのアベイラビリティーゾーン（AZ）の障害」と「リージョン全体の障害」から短時間で復旧させるためのサービスです。2021年7月に「Amazon Route 53 Application Recovery Controller（Route 53 ARC）」として一般提供が始まり、現在はAmazon ARCの名称でゾーンシフト、ゾーンオートシフト、ルーティングコントロール、Region switchの4機能を持ちます。この記事では、4機能の違いと選び方、料金の月額試算、AWS CLIでの実行例を、2026年10月時点の公式ドキュメントとAPI定義に沿って整理します。

まとめ：ARCの4機能と選び方

• AZ障害には、まず追加料金のないゾーンシフト系を有効にします。対象はALB・NLB・EC2 Auto Scalingグループ・EKSクラスターで、データベースやストレージの冗長化・復旧は別途設計が必要です。
• リージョン障害に備えるなら、手順全体を自動化するRegion switch（1プラン月70 USD）が第一候補です。DNSの切り替えもRegion switchのRoute 53ヘルスチェック実行ブロックで足ります。切り替え機構そのものに100%の可用性SLAや安全ルールが必要な場合だけ、ルーティングコントロール（1クラスター1時間2.50 USD＝月約1,825 USD）を足します。
• 準備状況チェックは2026年4月30日で新規受付を終えました。新しく始める構成ではRegion switchのプラン評価で代替します。
• ARCは切り替えの実行役です。切り替え先のAZ・リージョンに容量が無ければ復旧しないため、事前のスケールと定期的な切り替え試験が前提になります。
• ARCが起動・スケール・昇格まで操作するのはAWSのリソースです。ルーティングコントロールはDNSの切り替えなので向き先をオンプレミスにもできますが、Google CloudやAzure側のリソースを動かす機能はありません。

以下、名称の経緯から順に、機能ごとの設定方法と費用を説明します。

ARCとは：Route 53 ARCからの経緯と4つの機能

ARCは2021年7月27日に、Route 53の機能群としてRoute 53 ARCの名前で一般提供が発表されました。当初の中心はルーティングコントロールと準備状況チェックで、その後ゾーンオートシフト（2023年11月30日）、Region switch（2025年8月1日）が加わっています。現在の公式ドキュメントと料金ページは「Amazon Application Recovery Controller（ARC）」の名称で統一されており、「route53 arc」「Route 53 ARC」で検索して見つかる古い資料も同じサービスを指します。

名称とCLIの名前空間の対応

名称は変わりましたが、AWS CLIとSDKのサービス名には旧名が残っています。CLIを書くときに迷いやすいので、機能ごとの名前空間を先に押さえておきます。

4機能の比較：範囲・起動者・料金・期限

公式ドキュメントの機能比較表を、選び方に効く項目に絞ると次のようになります。

AZ側の2機能は「行き先を選ばない」点が要点です。障害AZからトラフィックを外すだけで、残りのAZに振り分け直されます。リージョン側の2機能は行き先を明示し、期限を持たないため、切り戻しまで人が管理します。

ゾーンシフトによるAZ障害時のトラフィック退避

ゾーンシフトの動作はリソースごとに異なります。ロードバランサーでは障害AZへのトラフィックを退避させ、Auto Scalingグループでは新規容量の起動先やインスタンスの置換動作を制御します。デプロイ不良を特定AZに出してしまった場合や、AWS側の単一AZ障害で使います。料金はかかりません。

対応リソースとゾーンシフトの有効化

2026年10月時点の対応リソースは、EC2 Auto Scalingグループ、Amazon EKS、クロスゾーン負荷分散の有効・無効を問わないALBとNLBの4種類です。いずれもリソース側でARCとの連携を有効にする必要があります。以下のコードはAPI定義に沿った実行例で、ARNやリソース名、山括弧の値は自分の環境のものに置き換え、リージョンは東京（ap-northeast-1）を前提にしています。ロードバランサーの振り分けの基本はロードバランサーの仕組みと振り分け方式で解説しています。

# ALB・NLB：ロードバランサー属性でARC連携を有効化
aws elbv2 modify-load-balancer-attributes --region ap-northeast-1 \
  --load-balancer-arn arn:aws:elasticloadbalancing:ap-northeast-1:111122223333:loadbalancer/app/my-alb/0123456789abcdef \
  --attributes Key=zonal_shift.config.enabled,Value=true

# 既存のAuto Scalingグループ：AZ障害時の扱いもここで決める
aws autoscaling update-auto-scaling-group --region ap-northeast-1 \
  --auto-scaling-group-name my-asg \
  --availability-zone-impairment-policy '{"ZonalShiftEnabled": true, "ImpairedZoneHealthCheckBehavior": "IgnoreUnhealthy"}'

# 既存のEKSクラスター
aws eks update-cluster-config --region ap-northeast-1 --name my-eks-cluster --zonal-shift-config enabled=true

Auto Scalingグループの ImpairedZoneHealthCheckBehavior は IgnoreUnhealthy と ReplaceUnhealthy の2値です。IgnoreUnhealthy を選ぶと、シフト中のAZで不健全になったインスタンスを置き換えません。障害AZで置き換えを繰り返して起動失敗が積み上がるのを避けたいなら、こちらが無難です。EKSでは、シフト中に障害AZのノードがcordonされ、新しいPodが置かれなくなります。ただしEKS Fargateは対象外で、既存Podの退避やAZに固定された永続ボリュームの移動を行う機能でもありません。

start-zonal-shiftの実行と有効期限

ゾーンシフトには必ず期限を付けます。開始時に指定できるのは1分から72時間（3日）までで、実行中に更新すれば新しい期限を設定し直せます。API定義上、--expires-in の書式は数値に m（分）か h（時間）を付けた形だけで、3d のような日単位は受け付けません。

# AZ名とAZ IDの対応を確認（AZ名とIDの対応はアカウントごとに異なる）
aws ec2 describe-availability-zones --region ap-northeast-1 \
  --query "AvailabilityZones[].[ZoneName,ZoneId]" --output table

# apne1-az1 からトラフィックを外す（2時間で自動終了）
aws arc-zonal-shift start-zonal-shift --region ap-northeast-1 \
  --resource-identifier arn:aws:elasticloadbalancing:ap-northeast-1:111122223333:loadbalancer/app/my-alb/0123456789abcdef \
  --away-from apne1-az1 \
  --expires-in 2h \
  --comment "deploy rollback in az1"

# 期限の延長と、復旧後の取り消し
aws arc-zonal-shift update-zonal-shift --region ap-northeast-1 --zonal-shift-id <ID> --expires-in 12h
aws arc-zonal-shift cancel-zonal-shift --region ap-northeast-1 --zonal-shift-id <ID>

--away-from に渡すのは ap-northeast-1a のようなAZ名ではなく、apne1-az1 のようなAZ IDです。障害告知はAZ IDで出ることが多いので、自社アカウントの対応表を手順書に貼っておくと当日迷いません。公式のベストプラクティスも、障害時はコンソールよりCLIやAPIで操作するよう勧めています。

ゾーンシフトが効かない・遅れる条件

ゾーンシフトを開始しても、次の条件ではトラフィックが外れないか、外れきるまで時間がかかります。いずれも公式ドキュメントに明記されている挙動です。

• ロードバランサーがフェイルオープン中：全AZのターゲットが不健全だと、ロードバランサーは全ターゲットへ送り続けます。この状態ではシフトしても何も変わりません。
• 単一AZのターゲットグループ：ALBではゾーンシフトが機能しません。
• NLBの背後にALBを置いた構成：シフトはNLB側で開始します。ALB側で開始すると、NLBはALBへ送り続けます。
• 既存の接続：切り替えの仕組みはDNSの更新なので、新しい接続しか移りません。ALBのHTTPクライアントkeepaliveは既定で3,600秒で、公式は復旧目標に合わせて300秒程度へ下げる例を示しています。
• 複数のロードバランサーが同じターゲットを共有：クロスゾーン有効のロードバランサーでシフトすると、シフトしていない他のロードバランサーからもターゲット容量が減ります。

フェイルオープンの有無は、各AZのターゲットの正常性と、ロードバランサーのDNSフェイルオーバー・ルーティングの設定を確認して判断します。ALB・NLBの既定値と失敗理由の読み方はELBヘルスチェックの設定と失敗原因の調べ方にまとめています。

ゾーンオートシフトと週1回の練習実行

ゾーンオートシフトは、AWSが内部テレメトリ（AWSネットワーク、EC2、Elastic Load Balancingなど）でAZの障害を検知したとき、利用者に代わってゾーンシフトを始める機能です。AWSがAZの回復を判断すると自動で戻します。公式は全AZに事前スケール済みのリソース向けと位置づけ、シフト開始後のオンデマンドなスケールに頼るべきではないと明記しています。

練習実行の設定と結果の読み方

オートシフトを有効にするには、練習実行（practice run）の設定が必須です。ARCはリソースごとに週1回、約30分、実際に1つのAZからトラフィックを外します。設定には、アプリケーションの異常を検知するCloudWatchアラーム（結果アラーム）を最低1つ指定します。

# 1) 練習実行の設定（結果アラームは必須、ブロック日は任意・UTC）
aws arc-zonal-shift create-practice-run-configuration --region ap-northeast-1 \
  --resource-identifier arn:aws:elasticloadbalancing:ap-northeast-1:111122223333:loadbalancer/app/my-alb/0123456789abcdef \
  --outcome-alarms type=CLOUDWATCH,alarmIdentifier=arn:aws:cloudwatch:ap-northeast-1:111122223333:alarm:my-app-5xx \
  --blocked-dates 2026-12-31

# 2) オートシフトを有効化
aws arc-zonal-shift update-zonal-autoshift-configuration --region ap-northeast-1 \
  --resource-identifier arn:aws:elasticloadbalancing:ap-northeast-1:111122223333:loadbalancer/app/my-alb/0123456789abcdef \
  --zonal-autoshift-status ENABLED

練習実行の結果はAPI上 SUCCEEDED・FAILED・INTERRUPTED・CAPACITY_CHECK_FAILED・PENDING の5値です（ドキュメントの一部ページには「SUCCESSFUL」と書かれていますが、API定義の値は SUCCEEDED）。FAILED は結果アラームがALARMになったときだけで、AWS側のイベントやAWS FISの実験と重なって止まった場合は INTERRUPTED になります。

2025年6月30日からは、練習実行の開始時に残りのAZの容量が釣り合っているかを確認するキャパシティチェックが入りました。対象はロードバランサーとAuto Scalingグループで、偏っていると CAPACITY_CHECK_FAILED となり、トラフィックは動きません。この結果から容量配置の問題を検出できます。ただし、容量チェックだけでは実際の負荷を処理できるか判断できないため、練習実行の結果アラームや負荷試験も併せて確認します。AZ障害を意図的に起こして確かめたい場合は、AWS Fault Injection Service（FIS）の電源断シナリオと組み合わせます。

ルーティングコントロールによるリージョン切り替え

ルーティングコントロールは、Route 53のヘルスチェック状態をオン／オフで切り替えるスイッチです。このヘルスチェックをDNSのフェイルオーバーレコードに関連付けると、プライマリとスタンバイの切り替えを人の判断で確実に実行できます。DNSの基盤そのものはRoute 53プライベートホストゾーンと内部名前解決、Route 53側の課金はRoute 53の料金を実額で計算する記事を参照してください。

クラスターの仕組みと上限

スイッチの状態を保持するのが「クラスター」です。公式の説明では、1クラスターは5つのリージョンにまたがる冗長なエンドポイントの集合で、状態の変更は5リージョンで合意を取って反映されます。反映は平均5秒、最大15秒以内で、5つのうち少なくとも3つのエンドポイントに常に到達できることをARCが保証します。クラスターは利用者ごとの専有（シングルテナント）で、5リージョンのうち2つが落ちても動き続ける設計のため、切り替え機構そのものに100%の可用性SLAが付きます。Region switchのRoute 53ヘルスチェック実行ブロックはより安価な代替ですが、有効化するリージョンが使えることを前提にしています。

安全ルールは、たとえば「最低1つのセルは常にオン」という条件で、全ルーティングコントロールをオフにした際の意図しないフェイルオープンを防ぎます。障害時に安全ルールが想定外に切り替えを止めた場合は、--safety-rules-to-override で明示的に上書きできます。

データプレーンAPIによるルーティングコントロールの状態変更

クラスターやコントロールパネルの作成はグローバル機能ですが、CLIでは --region us-west-2 を指定します。一方、障害時の状態変更は、5つのリージョン別クラスターエンドポイントのどれかに直接送ります。公式は、コンソールではなくCLIやSDKで操作し、5つのエンドポイントを手元に控え、つながらなければ次のエンドポイントで再試行するよう勧めています。

# 平常時に5つのエンドポイントを取得して控えておく
aws route53-recovery-control-config --region us-west-2 describe-cluster \
  --cluster-arn arn:aws:route53-recovery-control::111122223333:cluster/abcd1234

# 障害時：控えたエンドポイントの1つへ状態変更を送る（--regionはそのエンドポイントのリージョン）
aws route53-recovery-cluster update-routing-control-state \
  --routing-control-arn arn:aws:route53-recovery-control::111122223333:controlpanel/0123abcd/routingcontrol/efgh5678 \
  --routing-control-state On \
  --region ap-northeast-1 \
  --endpoint-url https://host-xxxxxx.ap-northeast-1.example.com/v1

上の --endpoint-url は説明用の値です。実際の値は describe-cluster の ClusterEndpoints に出る5件を使います。ルーティングコントロールは作成直後 Off なので、切り替え試験の前に現在の状態を get-routing-control-state で確かめておきます。

Region switchによるリージョン切り替え手順のプラン化

Region switchは2025年8月1日に追加された機能で、リージョンを切り替えるときの手順全体を「プラン」として定義し、手動またはCloudWatchアラームを起点に実行します。ルーティングコントロールがDNSの向き先だけを切り替えるのに対し、Region switchはデータベースの昇格、コンピュートのスケール、DNSの切り替え、承認待ちといった手順を順番どおりに実行します。プランは対象の全リージョンに複製され、各リージョンのデータプレーンで動くため、離脱しようとしているリージョンに依存しません。

プラン・ワークフロー・実行ブロックの構成

プランは1つ以上の「ワークフロー」を持ち、ワークフローは「ステップ」の並び、ステップは1つ以上の「実行ブロック」でできています。同じステップ内のブロックは並列、ステップ同士は順番に実行されます。アクティブ／パッシブ構成ではフェイルオーバーとフェイルバック、アクティブ／アクティブ構成では片方のリージョンの切り離しと復帰に対応します。2026年10月時点の実行ブロックは18種類です。

実行モードは、両リージョンが健全なときの計画的な切り替え（graceful）と、障害時に必要な手順だけを走らせる切り替え（ungraceful）の2つです。ungracefulでは、たとえばAurora Global Databaseのブロックで、データ損失の可能性があるフェイルオーバーを選べます。復旧後に元のリージョンでリードレプリカを作り直す「post-recovery」ワークフローも定義できます。親プランに子プランを入れて複数アプリケーションの順序を制御できますが、階層は親子の2段までです。

プラン評価・実行レポートとstart-plan-execution

Region switchは、プランの作成・更新直後と、その後30分ごとにプラン評価を走らせ、IAM権限、リソース設定、稼働容量の問題を警告します。2025年12月19日には、各実行のタイムラインや目標復旧時間の計算をS3へ自動保存するプラン実行レポートが追加され、監査用の証跡を手で集める作業が不要になりました。さらに2026年10月14日の更新で、プライマリとスタンバイのサービスクォータの差を検査して引き上げ申請まで自動で出す機能と、EC2 Auto Scaling・ECSのスケール後にターゲットグループのヘルスチェック通過を待つ機能が加わりました。「起動はしたがクォータ不足で台数が揃わない」「起動直後でまだ受けられない」という復旧時の典型的な失敗を、事前に検出しやすくする機能です。ただしクォータの引き上げ申請は商用リージョンで1アカウント・1リージョンあたり同時5件までしか出さず、申請が承認されるまで警告は残ります。クォータが揃っていても、切り替え時の容量が確保される保証にはなりません。

# 障害時：有効化したいリージョン（ここでは大阪）のデータプレーンへ実行を送る
aws arc-region-switch start-plan-execution --region ap-northeast-3 \
  --plan-arn <PLAN_ARN> \
  --target-region ap-northeast-3 \
  --action activate \
  --mode ungraceful \
  --comment "tokyo impairment"

# 実行中のイベントを追う
aws arc-region-switch list-plan-execution-events --region ap-northeast-3 \
  --plan-arn <PLAN_ARN> --execution-id <EXECUTION_ID>

--action は activate・deactivate・postRecovery の3値、--mode は graceful・ungraceful の2値です。プランの作成・更新・削除（CreatePlan など）はデータプレーンのAPIではありません。障害が起きてからプランを直すのではなく、平常時に作り込んで試験しておく前提の作りです。東京と大阪の役割分担はAWS東京リージョンのAZ構成と大阪との使い分けで解説しています。

注意点が1つあります。Region switchはスケール系の実行ブロックで容量を確保しにいきますが、目標の容量が得られることは保証しません。リージョン障害時は他の利用者も同じリージョンへ一斉に寄せるため、止められない業務ではオンデマンドキャパシティ予約で切り替え先の容量を押さえておくよう、公式も勧めています。

準備状況チェックの新規受付終了と移行先

準備状況チェック（readiness check）は、切り替え先のリソースのクォータ、容量、ルーティングポリシーを監視し、フェイルオーバーできない状態への変化を知らせる機能でした。2026年4月30日に新規利用者への提供を終了し、既存利用者は引き続き使えます。AWSが示す移行先は、30分ごとに準備状態を評価するRegion switchのプラン評価です。ルーティングコントロール、ゾーンシフト、ゾーンオートシフト、Region switchには変更がありません。

ARCの料金と月額の試算

前払いや長期契約は無く、使った機能の分だけ課金されます。単価は2026年10月18日に公式の料金ページで確認した値で、月額は1か月730時間で計算しています。

差が大きいのはルーティングコントロールです。1クラスターに複数のルーティングコントロールを載せられるとはいえ、使わない月も約1,825 USDかかります。一方、業務アプリケーション3つをそれぞれRegion switchのプランにしても、ルーティングコントロールを併用しなければプラン料金は月210 USDです。DNSの切り替えをRoute 53ヘルスチェック実行ブロックで済ませられるなら、Region switchのほうが安く済む構成が多くなります。Route 53のヘルスチェックやクエリ、CloudWatchアラーム、スタンバイ側のリソースは別料金です。

ARCを使うべき構成・使わなくてよい構成

判断の軸は「切り替え先の受け皿が既にあるか」です。ARCは復旧の実行を確実にする道具で、冗長構成を作る機能ではありません。可用性の目標値の決め方は可用性と稼働率の計算、データベース単体のフェイルオーバー時間はRDSとAuroraのフェイルオーバー時間の比較で確かめられます。

単一AZの構成でルーティングコントロールを契約しても、切り替える先が無いため月約1,825 USDの固定費だけが残ります。逆に、マルチAZ構成でゾーンシフトを有効にしていないなら、無料で使える復旧手段を放置していることになります。まずロードバランサー属性の1行から始めるのが現実的です。

Route 53自体のAccelerated recoveryと混同しないことも大切です。これは事前に有効化したパブリックホストゾーンについて、AWSが米国東部（バージニア北部）の障害を検知してから約60分以内にDNS変更を再開することを目標とする仕組みで、公式は「AWSによるAPIの復旧を待たずにRTOを自分で管理したいなら、ルーティングコントロールかRegion switchのRoute 53ヘルスチェック実行ブロックを使う」と使い分けを示しています。過去のAWS大規模障害で何が止まったかはAWS障害の確認方法と原因・対策で整理しています。マルチAZ・マルチリージョン構成の設計から任せたい場合は、AWSを含むクラウドのインフラ構築支援も相談先の1つです。

よくある質問

ARCとは何の略ですか？

Amazon Application Recovery Controllerの略です。AWS上のアプリケーションを、AZ障害やリージョン障害から短時間で復旧させるための切り替えを担います。

Route 53 ARCとAmazon ARCは別のサービスですか？

同じサービスです。2021年7月にRoute 53 ARCとして提供が始まり、現在はAmazon ARCの名称になりました。AWS CLIでは、ルーティングコントロールの名前空間に route53-recovery- の旧名が残っています。

ゾーンシフトの利用に料金はかかりますか？

かかりません。ゾーンシフトとゾーンオートシフトは追加料金なしです。料金が発生するのはルーティングコントロールのクラスター（1時間2.50 USD）、Region switchのプラン（月70 USD）、既存利用者の準備状況チェック（1時間0.045 USD）です。

ARCは東京リージョンで使えますか？

使えます。ゾーンシフトとゾーンオートシフトは商用リージョンで提供され、東京（ap-northeast-1）も対象です。Region switchも東京・大阪を含む全商用リージョンで使えます。ルーティングコントロールの設定系CLIだけは --region us-west-2 を指定します。

ゾーンシフトは最大何日続けられますか？

開始時に指定できる期限は最大72時間（3日）です。実行中に更新すれば新しい期限を設定でき、不要になればいつでも取り消せます。

関連記事

• AWS障害の確認方法と原因・対策｜2025年10月の大規模障害から学ぶ実務ガイド
• 可用性とは？稼働率の計算と高可用性の設計をインフラ実装目線で解説【2026年版】
• ELBヘルスチェックの設定と失敗原因の調べ方｜ALB・NLBの既定値と理由コード
• AWS Fault Injection Service（FIS）とは？カオスエンジニアリングの仕組み・実験テンプレート・料金と採用判断を実装者目線で解説
• AWS東京リージョン（ap-northeast-1）とは｜AZ構成と指定方法・大阪との使い分け