AWS Resilience Hub入門｜アプリケーションの回復力をRPO/RTO目標で自動評価してアーキテクチャの弱点を可視化する実践ガイド

「このシステムのRTOは本当に4時間以内で達成できますか」—— 設計レビューや監査でそう問われたとき、即答できるエンジニアは意外と少ない。DR計画はある。バックアップも設定している。マルチAZ構成も組んでいる。でも、現在のリソース構成が本当にRTO/RPO目標を満たせるかどうかは、誰かが手でチェックするしかない—— そんな状態になっていないだろうか。

AWS Resilience Hubは、その「手動評価」をコードで置き換えるサービスだ。アプリケーションを構成するリソースを自動検出し、あなたが定義したRPO/RTO目標と照らし合わせて、アーキテクチャの弱点を定量的に評価してくれる。インフラをコードで管理するようになったのに、耐障害性評価だけは依然として人間の目視と勘に頼っている——そのギャップを埋めるサービスだ。

この記事では、AWS Resilience Hubの仕組みと使い方を、オンプレミスのBCP評価との対比を交えながら解説する。評価ポリシーの定義からアセスメントの実行・推奨事項の読み方、そしてCI/CDパイプラインへの組み込みまで、現場で使える知識をまとめた。

なぜResilience Hubが必要なのか（オンプレとの違い）

オンプレ時代、BCP（事業継続計画）の作成と評価は「文書管理の作業」だった。ネットワーク図・サーバー構成図を眺めながら「この回線が切れたら…」「このストレージが止まったら…」と、担当者が頭の中でシミュレーションして評価コメントをWordに書いていた。

クラウドに移行しても、多くのチームはこのやり方を引き継いでいる。年に1回のBCPレビュー、半年に1回のDR訓練。それ自体は悪くないが、クラウドではインフラが日々変化する。新しいサービスをデプロイする。オートスケーリングの設定を変える。RDSのインスタンスタイプを変更する。そのたびに「RTO/RPO目標への影響は？」を手動で評価しているチームは、ほとんどいない。

これを構成ドリフト（Configuration Drift）と呼ぶ。書いてあるDR計画と、実際に動いているシステムのギャップが時間とともに広がっていく現象だ。実際に障害が起きて初めて「あ、ここがボトルネックだった」と気づく。

AWS Resilience Hubは、この構成ドリフトを継続的に検出する仕組みを提供する。CloudFormationスタックやTerraformのstateファイルからリソースを自動インポートし、設定したRPO/RTO目標と照らし合わせて評価する。アーキテクチャを変更するたびに再評価できるし、CI/CDパイプラインに組み込んで「変更がRTO目標を悪化させる場合はデプロイをブロック」するゲートとして使うこともできる。

AWS Well-Architectedフレームワークの信頼性の柱に「障害からの回復力」があるが、Resilience Hubはその評価を自動化するツールとも言える。

AWS Resilience Hubの主要概念を理解する

まず使い方を理解する前に、4つの主要概念を押さえておこう。

1. アプリケーション（Application）

Resilience Hubでは、評価の対象を「アプリケーション」という単位で管理する。1つのアプリケーションに、そのサービスを構成する複数のAWSリソースをまとめてインポートする。

リソースのインポート元として、以下の3つが使える：

・AWS CloudFormation スタック: テンプレートで管理しているリソースをそのまま取り込める。複数スタックをまとめて1つのアプリケーションに統合することも可能。
・Terraform（S3バックエンド）: Terraformを使っている場合は、S3に保存しているtfstateファイルを指定することでリソースを自動検出できる。ただし、ローカルstateはサポートされていないため、S3バックエンドへの移行が前提になる。
・AWS Resource Groups: タグベースでリソースをまとめているなら、Resource Groupsから取り込める。

1つのAWS環境では、webアプリ・バッチ処理・データパイプラインなど複数のシステムが稼働しているはずだ。それぞれを別々のアプリケーションとして定義することで、システムごとの評価ができる。

2. 評価ポリシー（Resiliency Policy）

評価ポリシーは、「何を目標としているか」を定義するものだ。RPO（目標復旧時点）とRTO（目標復旧時間）を、障害の種類ごとに設定する。

障害の種類は4段階ある：

それぞれに対してRTO・RPOの目標値を設定する。たとえば「AZ障害はRTO 2時間・RPO 15分、リージョン障害はRTO 8時間・RPO 1時間」のように階層的に設定できる。当然、リージョン障害の目標は緩めに、Software障害の目標は厳しめに設定するのが一般的だ。

ポリシーは自作できるほか、AWSが用意したプリセット（「ミッションクリティカル」「重要システム」「通常システム」など）を使うこともできる。まずはプリセットで試してみて、自社の要件に合わせて調整するのがおすすめだ。

3. アセスメント（Assessment）

アセスメントが実際の「評価実行」だ。定義したアプリケーションのリソース構成をスキャンし、評価ポリシーと照らし合わせて弱点を検出する。オンデマンド実行と、日次/週次のスケジュール実行の両方に対応している。

スキャンが完了すると、0～100のResilience Scoreが算出される。100が完全に目標を満たしている状態。スコアが低いほど、RTO/RPO目標から乖離している箇所が多い。

4. 推奨事項（Recommendations）

アセスメント後に提示されるのが推奨事項だ。3つのカテゴリに分類される：

・Alarm recommendations: 検知が不十分なリソースへのCloudWatchアラーム追加提案。ALBのエラーレート監視が設定されていない、RDSのCPU使用率アラームがない、といった具体的な指摘が来る。
・SOP（Standard Operating Procedures）recommendations: 障害対応手順書の提案。AWS Systems Manager Automation Runbookのテンプレートとして提供され、そのまま実行できる形になっている。
・Test recommendations: AWS FIS（Fault Injection Service）と連携した障害注入テストの提案。「このEC2インスタンスを強制停止してRTO目標を達成できるか検証せよ」といったテストシナリオが自動生成される。

基本的な使い方（コンソール操作）

1. アプリケーションを定義する

AWSマネジメントコンソールで「Resilience Hub」を検索して開く。「Create application」ボタンをクリックし、以下を設定する：

・アプリケーション名（例: web-app-production）
・リソース取り込みソース（CloudFormation / Terraform / Resource Groups）
・評価の頻度（Daily / Weekly / On-demand only）

CloudFormationスタックを選んだ場合は、対象スタックをリストから選択する。複数のスタックを組み合わせることもできる。たとえば「ネットワーク層スタック」「アプリ層スタック」「DB層スタック」の3つをまとめて1つのアプリケーションとして定義する使い方が一般的だ。

Terraformを使っている場合は、S3バケットとtfstateのパスを指定する。クロスアカウントのリソースを含む場合は、アクセス権限の設定が別途必要になる。

# AWS CLI でアプリケーションを作成する例
aws resiliencehub create-app \
  --name "web-app-production" \
  --description "本番Webアプリケーション（フロント+API+DB）" \
  --assessment-schedule "Daily" \
  --policy-arn "arn:aws:resiliencehub:ap-northeast-1:123456789012:resiliency-policy/my-policy"

2. 評価ポリシーを設定する

「Resiliency policies」メニューから「Create policy」をクリックする。ポリシー名と、障害種別ごとのRTO・RPOを入力する。

単位は時間または分で指定できる。たとえば以下のような設定になる：

この数値は業界やシステムの重要度によって大きく異なる。金融系のミッションクリティカルなシステムであれば、AZレベルでもRTO 1時間・RPO 5分以下を求めることもある。自社のSLAやSLOと整合する値を設定することが重要だ。

3. アセスメントを実行する

アプリケーション画面で「Run assessment」をクリックするか、スケジュール設定をしていれば自動で実行される。スキャンは対象リソース数にもよるが、数十のリソースなら数分で完了する。

# AWS CLI でアセスメントを起動する
aws resiliencehub start-app-assessment \
  --app-arn "arn:aws:resiliencehub:ap-northeast-1:123456789012:app/app-id" \
  --app-version "release"

# アセスメントの状態を確認する
aws resiliencehub describe-app-assessment \
  --assessment-arn "arn:aws:resiliencehub:ap-northeast-1:123456789012:app-assessment/assessment-id"

結果画面では、各コンポーネント（EC2、RDS、Lambda等）ごとのRTO/RPOの達成状況が色分けで表示される。赤が「目標未達」、黄が「要注意」、緑が「達成」だ。

4. 推奨事項を確認して対応する

「Recommendations」タブを開くと、カテゴリ別に推奨事項が並んでいる。優先度の高いものから対応していく。

たとえばアラーム推奨事項では「Application Load BalancerのHTTP5xxエラーレートが5%を超えたときのアラームが未設定です。以下のCloudFormationテンプレートをデプロイしてください」といった形で、すぐ使えるコードが提示される。

SOP推奨事項では、「RDSフェイルオーバーのRunbook」「EC2インスタンス再起動のRunbook」など、Systems Manager Automation との連携が提案される。推奨事項から直接Runbookをアカウントに追加できるため、複雑な設定は不要だ。

テスト推奨事項では、AWS FIS（Fault Injection Service）のテンプレートが生成される。「このAZのEC2を停止してAZ障害をシミュレートし、RTO目標を達成できるか検証してください」というテストシナリオをワンクリックで実行できる。

料金の仕組み（コスト感覚を掴む）

AWS Resilience Hubの料金は、評価対象のリソース数と実行頻度で決まる。2026年9月時点の参考値を示す（最新料金はAWS公式の料金ページで確認すること）。

EC2×5台、RDS×2台、Lambda×10関数、ALB×1台など、合計20リソース程度の構成で月次スケジュールアセスメントを実行する場合、月額$0.04程度になる計算だ。中規模システム（50リソース程度）でも月$1未満で運用できることが多い。

コスト上の注意点が2つある。まず、対象リソースに何が含まれるか事前に把握しておくこと。CloudFormationスタックが想定より多くのリソースを持っていると、思わぬ課金になる場合がある。事前にスタックのリソース一覧を確認しておこう。

次に、AWS FISと連携したテストの実行は別途FISの料金がかかる。テスト推奨事項を全件実施すると、FIS側の課金が加算されるため注意が必要だ。

応用・実務Tips

【Tips 1】CI/CDパイプラインに組み込む

Resilience Hubの真価は、CI/CDパイプラインへの統合で発揮される。インフラ変更のたびにアセスメントを自動実行し、スコアが閾値を下回ったらデプロイをブロックするゲートとして使える。

AWS CodePipelineを使った例を示す：

# CodeBuildのbuildspec.ymlにアセスメントを追加する例
post_build:
  commands:
    # アセスメント起動
    - ASSESSMENT_ARN=$(aws resiliencehub start-app-assessment \
        --app-arn $APP_ARN \
        --app-version "release" \
        --query "assessment.assessmentArn" --output text)
    # 完了を待機（最大10分）
    - |
      for i in $(seq 1 20); do
        STATUS=$(aws resiliencehub describe-app-assessment \
          --assessment-arn $ASSESSMENT_ARN \
          --query "assessment.assessmentStatus" --output text)
        [ "$STATUS" = "Success" ] && break
        sleep 30
      done
    # スコアチェック（75未満はデプロイ失敗）
    - SCORE=$(aws resiliencehub describe-app-assessment \
        --assessment-arn $ASSESSMENT_ARN \
        --query "assessment.resiliencyScore.score" --output text)
    - |
      if (( $(echo "$SCORE < 75" | bc -l) )); then
        echo "Resilience score $SCORE is below threshold. Deployment blocked."
        exit 1
      fi

このゲートがあれば、「先週のデプロイ後からRTO目標が達成できなくなっていた」という事故を事前に防げる。リリースのたびに耐障害性が担保されているか自動チェックされるのは、オンプレ時代には実現しにくかったアプローチだ。

【Tips 2】マルチアカウント環境での活用

本番・ステージング・開発でAWSアカウントを分けている場合（環境分離設計）、Resilience HubはAWS Organizationsと連携してマルチアカウントのリソースをまとめて評価できる。

クロスアカウントのリソースをアプリケーションに含める場合は、対象アカウントにResilienceHub専用のIAMロールを作成し、評価を実行するアカウントからAssumeRoleできるよう設定する。本番アカウントへのアクセスを最小限に抑えるため、読み取り専用のポリシーのみ付与するのが基本だ。

【Tips 3】Well-Architectedレビューのインプットとして使う

AWS Well-Architectedフレームワークのレビューを定期的に実施しているチームは、Resilience Hubのスコアとレポートをそのままインプットとして使える。「信頼性の柱」の評価項目の多くが、Resilience Hubの推奨事項と対応しているからだ。

アセスメント結果のPDFエクスポートが可能なので、レビュー会議の事前資料として配布するのもよい。「スコア68点、改善優先事項TOP5」という形で定量的に議論できるようになる。

【Tips 4】DR訓練のシナリオ策定に使う

DR戦略の検証において、Resilience HubのTest recommendationsは訓練シナリオの骨格として機能する。「AZレベルの障害」「特定EC2の強制停止」「RDSフェイルオーバー」など、推奨事項で提示されたシナリオをAWS FISで実際に実行することで、マルチAZ構成が本当に機能するかを実証できる。

よくあるトラブルと対処法

トラブル1: リソースが正しく検出されない

CloudFormationスタックを指定したのに、一部のリソースが検出されない場合がある。主な原因は以下の2つだ。

・ネストされたスタック（Nested Stack）の未検出: 親スタックを指定しても、ネストされた子スタックのリソースが含まれないことがある。子スタックを別途追加するか、Resource Groupsでタグベースにまとめ直すと解決できる。
・サポート対象外リソース: Resilience Hubが評価できるリソースは対応サービスに限られる。EC2・RDS・ELB・Lambda・DynamoDB等は対応済みだが、一部のニッチなサービスは対象外の場合がある。評価対象外のリソースはコンソールで「Unsupported」と表示される。

トラブル2: スコアが低いが何から手をつけるかわからない

推奨事項が大量に出てきたとき、どこから着手すべきか迷いやすい。優先順位の付け方は2段階で考える。

まず「Critical」ラベルが付いた推奨事項を最優先にする。RTOまたはRPOの目標から大幅に乖離しているリソースが対象になっている。次に、「Alarm recommendations」から着手するとコストパフォーマンスが高い。アラームの追加はコードで数時間あれば対応でき、検知能力が上がることでスコアが大きく改善することが多い。

トラブル3: アセスメントがエラーで終了する

アセスメントがSuccessではなくFailedで終わる場合、IAMの権限不足が最も多い原因だ。Resilience HubがリソースをスキャンするためにはDescribe系のアクションが必要だ。

# Resilience Hubに必要な最低限のIAMポリシー（代表的なサービス）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "rds:Describe*",
        "elasticloadbalancing:Describe*",
        "lambda:List*", "lambda:Get*",
        "dynamodb:Describe*", "dynamodb:List*",
        "cloudwatch:Describe*", "cloudwatch:List*",
        "cloudformation:Describe*", "cloudformation:List*",
        "s3:GetBucketVersioning", "s3:GetBucketReplication",
        "backup:Describe*", "backup:List*",
        "route53:List*",
        "ecs:Describe*", "ecs:List*"
      ],
      "Resource": "*"
    }
  ]
}

AWSのマネージドポリシー「AWSResilienceHubAsssessmentExecutionPolicy」を使うと、必要な権限を一括で付与できる。手動でポリシーを組む場合の参考にしてほしい。

トラブル4: TerraformのstateがS3にない

ローカルstateを使っているTerraformプロジェクトは、Resilience Hubからリソースをインポートできない。この場合は、まずTerraformのバックエンドをS3に移行する必要がある。

# Terraform backend設定をS3に変更する
terraform {
  backend "s3" {
    bucket = "my-terraform-state-bucket"
    key    = "production/webapp/terraform.tfstate"
    region = "ap-northeast-1"
  }
}

# バックエンド移行コマンド
terraform init -migrate-state

本記事のまとめ

AWS Resilience Hubは、「インフラはコードで管理しているのに、耐障害性評価だけは手動」というギャップを埋めるサービスだ。評価ポリシーにRPO/RTO目標を定義し、アセスメントを実行することで、アーキテクチャの弱点を定量的に可視化できる。

コストは中規模システムでも月額数ドル以内に収まることがほとんどで、導入コストは低い。まずはCI/CDではなくオンデマンドアセスメントから試してみて、自システムのResilienceスコアがどのくらいかを把握するところから始めるとよい。その数字を見てから、改善の優先順位を考える。それだけでも、オンプレ時代の「なんとなく安全だろう」という感覚評価から、定量的なアーキテクチャ管理へ一歩前進できる。