ARC Region Switchの概要と活用ポイント
はじめに
Amazon Application Recovery Controller（ARC）は、AWSリージョン障害時にアプリケーションのトラフィックを迅速かつ安全に別リージョンへ切り替えるためのサービスです。ARCのRegion Switch機能では、事前に定義した「プラン」に基づき、複数リージョン間でのフェイルオーバー処理を自動化・可視化できます。プランは「Workflow」「Trigger」「Step」などの構成要素から成り、CloudWatch Alarmによる自動実行や手動承認ステップ、LambdaやAuroraなどのAWSサービスとの連携も可能です。
本記事では、ARCの基本概念と、実際の構成・設計におけるポイント、そして従来の独自構成との比較を通じて、ARC導入によるメリットを整理します。
ARC Region Switchの構成要素
Plan
- リージョン切替の全体設計を定義する単位
- Recovery Time Objective（RTO）や対象リージョン、IAMロールなどを指定
※ここで設定したRTOについて、このRTOに間に合うようにARC側で処理してくれる、というものではありません。
あくまで目標として設定することで後々切り替えを行ってから、その実績と目標を比較して達成度合いを見てくれるというもののようです。
Trigger
- CloudWatch Alarmを条件として、プランを自動実行
-
Minimum delay between plan executionsにより連続実行を制御
※Minimum delay between plan executionsがあることにより例えばシステムが不安定な状態となって短時間に何度もCloudwatch Alarmのステータスが変更したとしてもその都度切り替え処理が発生することを防ぐことが可能になります。
Workflow
- 各リージョンごとに定義されるステップ群
- Activate / Deactivate のアクションを持つ
- 並列実行や手動承認、Lambdaなど多様なステップを組み合わせ可能
このWorkflowは2025/8時点ではAWS Step Functionsの簡易版のようなイメージです。
特にAWSサービスとの連携に関してAWS Step Functionsのように充実しているわけではなく、EC2やECS・RDSなどあくまでマルチリージョンの切り替えにおいて処理が発生する可能性の高いものに限定されています。
ただその分機能全体がシンプルで直感的に操作しやすいとも言えます。
また、ワークフローは切替元リージョン・切替先リージョンで同じ処理を行うことも、別々の処理を行うこともどちらも可能です。
Plan評価ステータスの意味
Plan評価というのは、作成されたPlanが実行可能な状態になっているかどうか、を検証した結果です。
ステータスとしては以下のようなものがあります。
| ステータス | 説明 |
|---|---|
| Passed | プランは正常で、実行可能 |
| Action Required | 構成に問題があり、修正が必要 |
| Pending Evaluation | 評価が未完了 |
| Unknown | 評価結果が取得できない |
例として私が作成したPlanではIAMRoleに何の権限も持たないダミーのものを設定したところ、IAM権限が不足しているということで以下のように問題がある旨指摘がされます。
評価結果は GetPlanEvaluationStatus API またはコンソール上で確認可能です。
Triggerの制約と設計ポイント
Triggerは作成したPlanに対して、何をトリガに実行するか設定するための項目です。
| 項目 | 内容 |
|---|---|
| 対応条件 | CloudWatch Alarm のみ（EventBridgeは非対応） |
| 条件数 | 最大10個まで設定可能 |
| 実行間隔 |
minDelayMinutesBetweenExecutions で制御 |
| 実行アクション | Activate / Deactivate を指定可能 |
なお、Triggerとは別に即時でリージョン切り替えを手動実行することも可能です。
使用可能なWorkflowコンポーネント一覧（2025/8時点）
ワークフローでは利用できるコンポーネントが限定されており以下の通りとなっています。
自システム固有で必要な処理を組み込む場合はCustom action Lambda execution blockを用いてLambda内で処理を実装することになります。
| コンポーネント名 | ブロック名 | 説明 | 主な用途 | 関連サービス |
|---|---|---|---|---|
| CustomActionLambda | Custom action Lambda execution block | Lambda関数を実行 | カスタム処理、通知 | AWS Lambda |
| ManualApproval | Manual approval execution block | 手動承認ステップ | オペレーターによる確認 | IAM Role |
| AuroraGlobalDatabase | Amazon Aurora Global Database execution block | Aurora Global DBの切替 | DBフェイルオーバー | Amazon Aurora |
| EC2AutoScaling | Amazon EC2 Auto Scaling group execution block | EC2 ASGの容量増加 | インスタンススケール | EC2 Auto Scaling |
| ARCRoutingControl | ARC routing control execution block | ARC Routing ControlのON/OFF | トラフィック切替 | Route 53 ARC |
| ARCRegionSwitchPlan | ARC Region switch plan execution block | 別のRegion Switch Planを実行 | ネスト構成 | ARC |
| Parallel | Parallel execution block | 複数ステップを並列実行 | 並列処理 | 任意のステップ群 |
| ECSServiceScaling | Amazon ECS service scaling execution block | ECSサービスのスケーリング | コンテナ拡張 | Amazon ECS |
| EKSResourceScaling | Amazon EKS resource scaling execution block | EKSリソースのスケーリング | Kubernetes拡張 | Amazon EKS |
| Route53HealthCheck | Amazon Route 53 health check execution block | Route 53ヘルスチェック監視 | 健全性確認 | Amazon Route 53 |
このWorkflowの実装に関して、GUIで操作できるので簡単そうには見えますが切り替えの内容は当然その環境の知見を持っていることが前提となっているので、例えばビジネスサイドの人が簡単に作れる、というような思想のものではなくAWS環境を正しく理解したエンジニアが行う必要があると思います。
Workflowの設計とリージョン間連携
切替手順によってはリージョンAで処理を行い、リージョンBで後続処理を行ってから、再度リージョンAで別の処理を行う、というようなことが必要になるケースもあるかと思います。
しかし2025/8時点でにおいてARCのRegion SwitchではWorkflow間の明示的な順序制御を行う標準的な機能はありません。
もしそれが必要な場合には複数のWorkflowを作成したうえで以下のようなものを組み合わせて実装する必要があります。
- ManualApprovalステップを挟む
- Parallelステップで並列実行
- Nested Planステップで別プランを呼び出す
- Lambdaステップで外部制御を挟む
独自構成 vs ARC：処理ステップの比較
私のチームでは以前に東阪マルチリージョン切り替えの効率化を行う仕組みを独自実装した経験があります。
それについて具体的な内容は以下の記事をご覧頂ければと思います。
この記事を基に、切り替えに必要となる各種処理に関してARCを用いることでどこまで対応できそうかを整理した結果が以下です。
| 処理ステップ | 従来（独自構成） | ARCでの対応 | 備考 |
|---|---|---|---|
| NACLによるネットワーク遮断 | 手動またはLambdaで制御 | × : カスタムLambdaが必要 | ARCにはNACL操作機能なし |
| Aurora Global DBの分離・スタンドアロン化 | Lambdaで制御 | 〇 : AuroraGlobalDatabaseステップで対応可能 |
switchoverOnly / failover の選択可 |
| Systems Manager Parameter Storeの更新 | Lambdaで制御 | × : カスタムLambdaが必要 | ARCはSSM操作不可 |
| Fargateによるアプリケーション起動 | Lambdaで制御 | 〇 : Lambdaステップで起動可能 | 起動処理をLambdaに委任 |
| DNSレコードの切替 | Route 53 API + Lambda | 〇 : Route53HealthCheckステップで一部対応 | ヘルスチェックベースの切替は可能 |
| Step Functionsによるステップ管理 | ネスト構成で設計 | 〇 : Workflow + Parallelステップで代替可能 | 並列・順序制御が可能 |
| 手動承認 | Step Functions + SNS通知 | 〇 : ManualApprovalステップで対応可能 | IAMロール指定で承認制御可能 |
| 実行ログの可視化 | CloudWatch Logs + Step Functions | 〇 : ARCのExecution画面で統合表示 | ステップ単位で状態確認可能 |
この整理の通り、NACLやParameter Storeの変更を行う場合にはLambdaで実装することが必要にはなりますが多くの処理をARCの中で完結させることが可能となっています。
独自実装した際にはかなり多くの工数をかけていましたので、Region Switchによりその効率化が期待できるのではないかと考えています。
また、Region SwitchはGUIで設定したものをコードとして出力することが可能ですので、類似システムへの横展開も容易であるといううれしいポイントもあります。
まとめ
ARCの導入により、従来の独自構成で必要だった複雑な制御やステップ設計を、より少ない工数で、より安全に、再利用可能な形で構築できるようになりました。特に、Triggerによる自動実行、Workflowによるステップ管理、Plan評価による事前検証などは、運用負荷の軽減に大きく貢献します。
今後は、ARCをベースにしたDR切替の標準化・横展開を進めることで、より多くのシステムに高可用性を提供できると考えています。