AWSレジリエンス/DR運用Vol1｜Resilience Hub・RTO/RPO

1. この記事について

AWSで本番システムを運用していると、「フェイルオーバー構成は組んだ、Backupも設定した、でも本当にRTOを満たせているか数字で言えない」という状況に直面しがちです。DR構成の有無は確認できても、回復性を定量測定して継続的に統制する仕組みがないと、障害発生のたびに手探りとなります。

AWS Resilience Hubはこの課題に正面から応えるサービスです。アプリケーションを登録してResiliency Policyを設定するだけで、推定RTO/RPOを継続的にアセスメントし、目標からの逸脱（ドリフト）を検知し、FIS実験の推奨まで生成してくれます。

本記事はAWSレジリエンス/DR本番運用シリーズのVol1として、Resilience Hubを中心とした回復性の測定・統制の上流設計を扱います。FIS実験の個別テンプレート、Backupのクロスリージョン手順、マルチリージョン構成パターン、Aurora DRといった実装詳細は既存記事が扱っています。本記事はそれらを束ねるナビゲーション起点として機能します。

既存のDR対策（Backup設定・フェイルオーバー構成・マルチリージョン展開）だけでは「DR対策を実施した」という事実は確認できても、「障害が発生したとき本当に目標RTO内に復旧できるか」を定量的に保証できません。実際に障害が起きてから初めて「BackupのRPOが要件の4時間を超えていた」「フェイルオーバーに想定の3倍の時間がかかった」という事実が判明するケースは珍しくありません。設定していること（手段）と達成できていること（結果）の間のギャップを閉じることが、本記事の核心的なテーマです。

Resilience Hubはこのギャップを構造的に解決します。アプリケーション構成をリソースグループとして登録し、Resiliency Policyで目標RTO/RPOを定義するだけで、推定RTO/RPOを継続的にアセスメントし、不足しているコンポーネントや設定を「推奨」として出力します。さらにFIS実験の推奨を自動生成し、定期的なドリフト検知でポリシーからの逸脱を継続監視します。本記事はResilience Hubをナビゲーション起点として、既存の実装記事群を上流設計から統合する方法を段階的に解説します。

1-1. 本記事のゴール

本記事を読み終えたとき、以下の状態になることを目標としています。

• AWS Resilience Hubがどのように回復性を測定・統制するかの全体像を理解している
• RTO/RPOの定義方法と4つのDR戦略の選択基準を説明できる
• Resiliency Policyを設計し、コードとして管理する手順を実施できる
• 既存のFIS・Backup・マルチリージョン・Aurora DR記事を「構成部品」として参照し、Resilience Hubで統合管理する設計イメージを持てる

単なる機能紹介ではなく、SRE/インフラチームが明日から実運用に適用できることを優先します。コード例はAWS CLIとCloudFormation/Terraformで示します。

本シリーズVol1の成果物はResiliency Policyのコード定義とアセスメント実行環境です。Vol2以降でFIS連携・クロスリージョンDR・ドリフト検知の運用を順次扱います。

1-2. 読者像

本記事は以下のような方を想定読者とします。

メイン対象

• AWS本番環境を運用しており、DR対策（Backup・フェイルオーバー構成・マルチリージョン）は実施済みだが、RTO/RPOを定量的に確認する仕組みがない方
• 上長やステークホルダーへ「本番環境の回復性がSLOを満たしているか」を定期報告する必要があるSRE・インフラエンジニア
• レジリエンス基盤の標準化を推進するプラットフォームチームのメンバー

前提知識

• AWSの主要サービス（EC2・RDS・Lambda・CloudFormation）の基本的な理解
• VPC・サブネット・リージョン・AZの概念
• AWS CLIの基本操作（aws configure済み）

本記事では扱わないこと

FIS実験の具体的なテンプレート設計、Backupジョブの設定手順、マルチリージョン構成のインフラ実装は本記事の範囲外です。それぞれ既存記事を参照してください（1-3節参照）。

本記事が解決する具体的なユースケース

本記事が対象とする典型的な課題を以下に示します。自分のチームの状況に当てはまるものがあれば、その節から読み始めることも可能です。

ユースケース1: FISでカオス試験はやっているが、RTO/RPO目標が未定義のまま

FIS実験でEC2インスタンス停止やAZ障害を注入しているにもかかわらず、「何秒以内に復旧すればOKか」という目標値を定義していないケースです。試験は実施できても合否判定基準がなければ、回復性の改善に向けた意思決定ができません。Resilience HubのResiliency Policyで目標を明文化し、FISのアセスメント推奨と組み合わせることで、試験の合否判定基準が定まります（§2→§4）。

ユースケース2: Backupは設定済みだが、実際のRPOが要件を満たすか検証できていない

日次バックアップを設定済みでも、「最大24時間分のデータロスが許容できるか」をビジネスレイヤーと合意していないケースです。Resilience HubはBackupの設定状況をリソースグループ単位で評価し、実際のRPO推定値をアセスメント結果として出力します。ステークホルダーへの定量報告に活用できます（§3→§6）。

ユースケース3: マルチリージョン構成にしたが、回復性ドリフトを検知する仕組みがない

マルチリージョン構成を展開後、インフラ変更が重なるたびに「本当に回復性が維持されているか」の確認が手作業になっているケースです。Resilience Hubの定期アセスメントでドリフトを自動検知し、EventBridgeとSecurity Hubに連携させることで継続的な統制ループが構築できます（§6）。

1-3. 既存DR記事との棲み分け — 本記事の独立軸

AWSのDR・レジリエンス関連記事は複数あります。本記事がどの層を担当するかを以下に整理します。

本記事の独立軸は「測定と統制」です。FIS実験・Backup手順・マルチリージョン構成がどれほど適切に設計されていても、Resilience Hubによるアセスメントなしには「目標RTO/RPOを本当に達成できているか」を継続的に確認できません。本記事はその測定基盤を構築します。

設計思想として、本記事はトップダウンのアプローチを取ります。ビジネス要件からRTO/RPOを定義し、Resiliency Policyに落とし込み、アセスメントで測定し、ドリフトを検知するという流れが上流設計です。既存記事の個別手順はこの上流設計があって初めて「どのDR戦略に適合するか」が明確になります。

各既存記事との具体的な連携シナリオ

本記事と既存記事を組み合わせる代表的なシナリオを示します。

シナリオ1: 本記事のRTO/RPO目標設定→FIS記事のカオス試験実施→Backup記事のデータ保護確立

1. 本記事の§2でResiliency Policyを設定し、推定RTO/RPOをアセスメント
2. §3のアセスメント結果の「FIS推奨」をもとに、FIS記事のテンプレートで障害注入試験を実施
3. FIS試験で判明したデータロスリスクに対し、Backup記事のクロスリージョン手順でデータ保護を強化
4. Resilience Hubで再アセスメントし、推定RPOが要件を満たすか確認

この流れにより、カオス試験が「回復性改善サイクル」の一部として機能するようになります。

シナリオ2: 本記事のResiliency Policy→マルチリージョン記事の構成選択→ドリフト検知ループ

1. 本記事の§2でRTO目標（例: 15分）に対応するDR戦略（Active-Passive等）をResiliency Policyで定義
2. マルチリージョン記事の構成パターンを参照し、Resiliency Policyに合致するインフラを選択・展開
3. 展開後、本記事の§6でドリフト検知を設定し、インフラ変更のたびにアセスメントを自動実行
4. ドリフト検知がトリガーされた際はResiliency Policyを起点に修正箇所を特定

これらのシナリオが示すとおり、本記事は個別実装記事の「入口」と「統制基盤」の両方として機能します。

カオスエンジニアリング（FIS）の記事を読む

1-4. 記事の読み方

本記事は§2から§8まで順を追って読む構成ですが、目的に応じて以下の読み方を推奨します。

初めてResilience Hubを触る方（概念把握優先）

§2（RTO/RPO戦略）→§3（アセスメントパイプライン）→§8（まとめ）の順で読むことで、Resilience Hubの全体像を短時間で把握できます。各章の実装詳細は後回しにして、まず測定・統制の考え方を理解するアプローチです。

本番環境への実装を急ぐ方（実装優先）

§3（アセスメント実行）→§4（FIS検証）→§5（クロスリージョン）→§6（ドリフト検知）の順で読み、コード例を手元の環境で試しながら進めることを推奨します。§2のRTO/RPO設計は事前に一読してから実装に入ると、Resiliency Policyの設定判断がスムーズになります。

すでに個別記事（FIS・Backup等）を読んでいる方（統合設計優先）

§2でResiliency Policyの設計思想を確認した後、§7の実戦統合パターンに進み、既存DR資産をどのように統合するかを確認してください。各記事との連携シナリオ（1-3節）も参照すると、統合設計の全体イメージをより具体的に描くことができます。

2. RTO/RPO戦略とResiliency Policy設計

回復性設計の出発点は、ビジネス要件をRTO（Recovery Time Objective：目標復旧時間）とRPO（Recovery Point Objective：目標復旧時点）に翻訳し、Resiliency Policyとして明文化することです。この工程を省略すると、DR構成が「なんとなくフェイルオーバーできる」状態にとどまり、SLO未達を検知する基準が存在しない状況に陥ります。

本章では、4つのDR戦略の選択基準とコスト比較、Resilience Hubが管理するResiliency Policyの設計方法、そしてポリシーをコードで管理して複数アプリに適用する手順を扱います。

2-1. RTO/RPOと4つのDR戦略

AWSはDisaster Recoveryの戦略を4つに分類しています。選択の軸はコストと復旧速度（RTO/RPO）のトレードオフです。

4つの中断タイプ別RTO/RPO推定

Resilience Hubは、障害の影響範囲に応じて4つの中断タイプを定義します。Resiliency Policyでは各タイプに対してRTO/RPOを個別に設定します。

中断タイプは階層的に捉えます。ApplicationはInfrastructure障害から波及することが多く、AZ障害はInfrastructure喪失を内包します。Resiliency PolicyでRegionレベルのRTO目標を厳しくするほど、コストが上昇します。

4つのDR戦略：復旧速度とコストの比較

Backup & Restore

最もシンプルで低コストのアプローチです。スタンバイ環境を持たず、障害発生後にバックアップから環境を再構築します。

• RTO：数時間〜数日（環境再構築の所要時間に依存）
• RPO：最後のバックアップ時点（1日1回なら最大24時間分のデータ損失）
• コスト：最低（スタンバイリソース不要、ストレージコストのみ）
• 適用例：開発環境・ステージング環境・コスト最優先の非クリティカルシステム

Pilot Light

最小限のスタンバイ環境（データ同期のみ稼働）を維持し、障害時にスケールアウトする戦略です。

• RTO：数十分（インスタンス起動・設定適用時間が支配的）
• RPO：分単位（継続的レプリケーションに依存）
• コスト：低〜中（データ同期用のリソースのみ常時稼働）
• 適用例：重要なデータは保護しつつコストを抑えたいシステム

Warm Standby

縮退スペック（本番の1/4〜1/2規模）のスタンバイ環境を常時稼働させ、障害時にスケールアップします。

• RTO：数分（スケールアップ時間のみ）
• RPO：秒〜分（ほぼリアルタイムのレプリケーション）
• コスト：中〜高（スタンバイリソースの常時稼働）
• 適用例：SLAで数分のRTOを要求されるビジネスクリティカルシステム

Multi-site Active-Active

複数リージョンで本番スペックの環境を同時稼働させ、障害発生時は即座にトラフィックを切り替えます。

• RTO：秒〜数分（DNS/ロードバランサーの切り替え時間のみ）
• RPO：ゼロに近い（同期的レプリケーション）
• コスト：最高（全リソースを複数リージョンで二重に保持）
• 適用例：金融・医療・EC等、ダウンタイムが直接的な損失につながるシステム

コスト比はあくまで概算であり、構成するサービスや規模によって大きく変動します。Resilience Hubのアセスメントを活用して、実際の構成が選択した戦略のRTO/RPO目安を満たしているかを継続的に検証することが重要です。

Resiliency PolicyをAWS CLIで作成する

DR戦略の選択後、Resilience Hubに対してResiliency Policyを作成します。以下は「Warm Standby」相当のポリシーをAWS CLIで作成する例です。

aws resiliencehub create-resiliency-policy \
  --policy-name "production-warm-standby" \
  --tier "MissionCritical" \
  --policy '{
 "AZ": {
"rtoInSecs": 300,
"rpoInSecs": 60
 },
 "Hardware": {
"rtoInSecs": 900,
"rpoInSecs": 300
 },
 "Software": {
"rtoInSecs": 180,
"rpoInSecs": 60
 },
 "Region": {
"rtoInSecs": 3600,
"rpoInSecs": 900
 }
  }' \
  --region ap-northeast-1

tier パラメータは MissionCritical / Critical / Important / CoreServices / NonCritical から選択します。tierはドキュメント参照用のメタデータであり、実際の評価はpolicyオブジェクト内のRTO/RPO値で決まります。

作成後に返される policyArn はアプリケーション登録時に使用します（§3で扱います）。

2-2. Resiliency Policyの設計

Resiliency PolicyはResilience HubにおけるSLO（Service Level Objective）の定義です。アプリケーションに紐付けることで、アセスメント時に「推定RTO/RPOが目標を満たしているか」の判定基準として機能します。

ResiliencyPolicy APIの主要フィールド

APIのキーが AZ / Hardware / Software / Region となっており、Resilience Hubコンソールの表示（Application/Infrastructure/AZ/Region）と名称が異なる点に注意してください。Hardware = Infrastructure（EC2等のVM/HW障害）、Software = Application（プロセス/サービス障害）に対応します。

可用性SLOからRTO/RPOを逆算する方法

可用性99.99%（フォーナイン）から逆算する場合の手順を示します。

年間ダウンタイム上限の計算：

365日 × 24時間 × 60分 × (1 - 0.9999) ≒ 52.6分/年
1ヶ月換算：52.6分 ÷ 12 ≒ 4.4分/月

この月間ダウンタイム上限を基にRTOを設定します。月に最大1回の障害が発生すると仮定すれば、RTO = 4分（240秒）が出発点になります。ただし、RPOはデータ損失に関わる別の指標であり、可用性SLOとは独立して業務要件から設定します。

4レイヤー別の目標値設定指針

実用的なResiliency Policy設計では、以下の考え方で各レイヤーの目標値を設定します。

• Software（Application）：発生頻度は高いが影響範囲の小さい障害。AutoScalingやECSのヘルスチェックで自動復旧するため、RTO目標を最も厳しくできます（秒〜数分）。
• Hardware（Infrastructure）：インスタンス障害。予備インスタンスの起動時間が支配的（数分〜数十分）。
• AZ：AZ退避（Zonal Shift）のDNS伝播時間が支配的（数分〜数十分）。
• Region：DR戦略の選択が直接RTO/RPOを決定します。Backup & Restoreなら数時間、Multi-site Active-Activeなら数分が現実的な目標値です。

上位レイヤーのRTO/RPOは下位レイヤー以上（同じか緩い）に設定するのが一般的です（Region ≥ AZ ≥ Hardware ≥ Software）。

2-3. ポリシーのコード化と再利用

Resiliency PolicyをコードとしてCloudFormationまたはTerraformで管理することで、複数アプリケーションへの適用を一元管理できます。

CloudFormationによるResiliency Policyの定義

AWSTemplateFormatVersion: '2010-09-09'
Description: Resilience Hub Resiliency Policy

Parameters:
  PolicyName:
 Type: String
 Default: production-warm-standby

Resources:
  ResiliencyPolicy:
 Type: AWS::ResilienceHub::ResiliencyPolicy
 Properties:
PolicyName: !Ref PolicyName
Tier: MissionCritical
Policy:
  AZ:
 RtoInSecs: 300
 RpoInSecs: 60
  Hardware:
 RtoInSecs: 900
 RpoInSecs: 300
  Software:
 RtoInSecs: 180
 RpoInSecs: 60
  Region:
 RtoInSecs: 3600
 RpoInSecs: 900
Tags:
  Environment: production
  Team: sre
  ManagedBy: cloudformation

Outputs:
  PolicyArn:
 Value: !GetAtt ResiliencyPolicy.PolicyArn
 Export:
Name: !Sub '${AWS::StackName}-PolicyArn'

OutputsでPolicyArnをエクスポートしておくことで、アプリケーションスタック側からFn::ImportValueで参照できます。

TerraformによるResiliency Policyの定義

resource "aws_resiliencehub_resiliency_policy" "production" {
  name = "production-warm-standby"
  tier = "MissionCritical"

  policy {
 az {
rto_in_secs = 300
rpo_in_secs = 60
 }
 hardware {
rto_in_secs = 900
rpo_in_secs = 300
 }
 software {
rto_in_secs = 180
rpo_in_secs = 60
 }
 region {
rto_in_secs = 3600
rpo_in_secs = 900
 }
  }

  tags = {
 Environment = "production"
 Team  = "sre"
 ManagedBy= "terraform"
  }
}

output "policy_arn" {
  value = aws_resiliencehub_resiliency_policy.production.arn
}

タグ戦略と複数アプリへの適用

Resiliency Policyは複数のアプリケーションに適用できます。実運用では以下のタグ戦略を推奨します。

ポリシーを環境別（production/staging）とSLOティア別（mission-critical/standard）の2軸で作成し、アプリケーションはその組み合わせから適切なポリシーを選択する設計にすると、ポリシー数を抑えつつ細粒度な制御が可能です。

複数アプリへの一括適用例（AWS CLI）：

POLICY_ARN="arn:aws:resiliencehub:ap-northeast-1:123456789012:resiliency-policy/production-warm-standby"

for APP_ARN in $(aws resiliencehub list-apps \
  --query 'appSummaries[?tags.PolicyTier==`mission-critical`].appArn' \
  --output text); do
  aws resiliencehub update-app \
 --app-arn "$APP_ARN" \
 --policy-arn "$POLICY_ARN"
  echo "Updated: $APP_ARN"
done

タグ PolicyTier: mission-critical を付与したアプリケーションに一括でポリシーを適用できます。

3. Resilience Hub アセスメントパイプライン

Resilience Hubはアプリケーションを登録し、Resiliency Policyに対して回復性をアセスメントします。本章では登録からアセスメントレポート、推奨事項の確認までのパイプラインを扱います。

3-1. アプリケーションの登録とアセスメント実行

オンボードの3経路

Resilience HubへのアプリケーションオンボードはCloudFormation、Terraform、AppRegistryの3経路をサポートしています。既存の構成管理手法に合わせて選択できます。

CloudFormation経由（最もシンプル）

既存のCloudFormationスタックをそのままResilience Hubに登録できます。コンソールから「アプリケーションの作成」→「CloudFormationスタックのインポート」と進み、対象スタックを選択します。スタックが複数リージョンにまたがる場合は、クロスリージョンスタックとして一括登録できます。

# CloudFormationスタックからアプリを作成する例
aws resiliencehub create-app \
  --name "my-ecommerce-app" \
  --policy-arn "arn:aws:resiliencehub:ap-northeast-1:123456789012:resiliency-policy/xxxxxxxx" \
  --description "本番ECサイトのResilience Hub管理対象アプリ"

登録後にスタック名を指定してリソースをインポートします。

aws resiliencehub import-resources-to-draft-app-version \
  --app-arn "arn:aws:resiliencehub:ap-northeast-1:123456789012:app/xxxxxxxx" \
  --source-arns '["arn:aws:cloudformation:ap-northeast-1:123456789012:stack/my-prod-stack/xxxxxxxx"]'

Terraform経由（Terraform State連携）

Terraformで管理しているリソースはTerraform Stateファイルを直接インポートします。Stateファイル（.tfstate）をS3バケットに配置し、Resilience HubコンソールからそのS3パスを指定してインポートします。

aws resiliencehub import-resources-to-draft-app-version \
  --app-arn "arn:aws:resiliencehub:ap-northeast-1:123456789012:app/xxxxxxxx" \
  --terraform-sources '[{"s3StateFileUrl":"s3://my-terraform-state/prod/terraform.tfstate"}]'

AppRegistry経由（タグベース管理）

AWS Service Catalog AppRegistryにアプリケーションを登録している場合は、AppRegistry経由でResilience Hubに連携できます。AppRegistryのアプリケーションARNを指定すると、タグで紐付いたリソースが自動的にインポートされます。マイクロサービス構成で複数スタックにまたがるアプリの管理に適しています。

アセスメントの3種類

定期スケジュール（自動）

コンソールの「アプリケーション設定」→「スケジュール」タブから、日次・週次・月次のアセスメントスケジュールを設定できます。スケジュールアセスメントはEventBridge Schedulerを内部で利用しており、指定時刻に自動実行されます。定常的な回復性監視に活用します。

オンデマンド（手動）

即時アセスメントが必要な場合はコンソールの「アセスメントを実行」ボタンか、AWS CLIで開始します。インフラ構成変更後の確認やゲームデー前の状態確認に使います。

# オンデマンドアセスメントの開始
aws resiliencehub start-app-assessment \
  --app-arn "arn:aws:resiliencehub:ap-northeast-1:123456789012:app/xxxxxxxx" \
  --app-version "release" \
  --assessment-name "pre-gameday-check-20260606"

CI/CD統合トリガー

デプロイパイプラインから自動実行するパターンです。インフラ変更のたびに回復性への影響を即時確認できます。詳しくは3-3節で扱います。

アセスメント実行の流れ

アセスメントを開始すると、Resilience Hubは次の順序で処理を行います。

1. リソース解決 — 登録されたアプリのリソース構成を最新状態にリフレッシュします
2. AppComponent分析 — EC2/RDS/ELB等のリソースをAppComponent（アプリの機能単位）にマッピングします
3. RTO/RPO推定 — 各AppComponentについて、4種類の中断タイプごとにRTO/RPOを推定します
4. Policy照合 — 推定値をResiliency Policyの目標値と照合し、CONFORMEDかNOT_CONFORMEDを判定します
5. 推奨事項生成 — SOP（標準操作手順）、アラーム追加、FIS実験等の回復性向上策を生成します

中規模構成（リソース50〜100程度）のアセスメント完了時間は5〜15分を目安とします。

# アセスメント結果の一覧取得
aws resiliencehub list-app-assessments \
  --app-arn "arn:aws:resiliencehub:ap-northeast-1:123456789012:app/xxxxxxxx" \
  --query 'assessmentSummaries[*].[assessmentName,complianceStatus,resiliencyScore]' \
  --output table

3-2. アセスメントレポートの読み方

Resiliency Score（0〜100）の見方

アセスメント完了後にコンソールで確認できる「Resiliency Score」は0〜100のスコアで回復性の総合評価を示します。スコアは各AppComponentの回復性評価を加重集計したものです。本番運用の目安として80以上を基準に置くチームが多く見られます。

スコアが下がった際は、コンソールの「スコアの内訳」から、どのAppComponentのどの中断タイプが低評価の要因かを特定できます。スコア下降を検知したらEventBridge経由でSNS通知を受け取る設定を入れておくと、構成変更による回復性劣化を早期に察知できます。

4つの中断タイプ別RTO/RPO推定結果

Resilience Hubは4種類の中断タイプそれぞれについてRTO/RPOを推定します。コンプライアンス状況はタイプごとに独立して判定されます。

アセスメントレポートの「コンプライアンス」タブでは、各タイプの推定RTO/RPOと目標値が表形式で並びます。たとえば「AZ中断: 推定RTO 45分 / 目標RTO 60分 → CONFORMED」のような形で確認できます。4タイプのうち1つでもNOT_CONFORMEDとなると、全体のコンプライアンス状態がPolicyBreachedになります。

RTO/RPOドリフトメトリクスの読み方

「ドリフト」タブでは前回アセスメントからの推定RTO/RPOの変化量を確認できます。

読み方の例として、次のようなドリフト表示を考えます。

AppComponent: checkout-api
中断タイプ: Infrastructure
前回推定RTO: 2h 20m
今回推定RTO: 3h 00m
RTOドリフト: +40m（目標2h → NOT_CONFORMED に変化）

「RTOドリフト +40m」は前回アセスメントから40分悪化したことを意味します。インフラ構成変更（例: Multi-AZ設定が外れたRDSへの変更）がRTO悪化の要因であることが多く、Resilience Hubがその変更を検知して差分を可視化します。ドリフト量を週次レポートとして共有することで、設計意図と実際の構成のずれを早期に検出できます。

各コンポーネントの評価詳細

「AppComponent」タブでは、EC2インスタンス、RDSクラスター、ELB、SQSキューなど各コンポーネントごとの評価が確認できます。コンポーネントを選択すると、RTO/RPOが推定された根拠（例: Multi-AZ設定なし→AZ障害時のフェイルオーバー時間が長い）が表示されます。

推奨事項タブには、そのコンポーネントに対して「Multi-AZを有効化する」「ElastiCacheをレプリケーション設定にする」「スナップショット間隔を短縮する」といった具体的な改善策が示されます。各推奨事項には優先度（High/Medium/Low）と対応するコンプライアンス改善効果が付記されています。

3-3. 推奨事項とCI/CD統合

Recommended SOPs（標準操作手順）の活用

アセスメント完了後にResilience Hubが生成するRecommended SOPsは、障害発生時の対処手順を自動生成したものです。SOPはRunbookとしてSystems Manager Automation（SSM）に直接エクスポートでき、オンコールチームの初動対応時間を短縮します。

コンソールの「推奨事項」→「SOP」タブから各SOPを確認し、「SSMドキュメントのエクスポート」を選択するとSSMオートメーションドキュメントとして保存できます。

# 推奨事項の一覧を取得する
aws resiliencehub list-app-component-recommendations \
  --assessment-arn "arn:aws:resiliencehub:ap-northeast-1:123456789012:app-assessment/xxxxxxxx" \
  --query 'componentRecommendations[*].{component:appComponentName}' \
  --output json

SOPに加えてアラーム推奨（CloudWatch Alarm追加）やFIS実験推奨も同一画面から確認できます。特にFIS実験推奨については4章で詳述します。

CodePipeline/GitHub Actionsへの統合

CodePipeline統合のポイント

CodePipelineのPost-deployステージにLambda関数を配置し、start-app-assessmentを呼び出してアセスメントを実行します。アセスメント完了（5〜15分）を待機して結果を取得し、PolicyBreachedとなった場合にパイプラインを失敗させます。

# CI/CD向け: アセスメント完了を待機して結果を確認するシェル例
ASSESSMENT_ARN=$(aws resiliencehub start-app-assessment \
  --app-arn "$APP_ARN" \
  --app-version "release" \
  --assessment-name "ci-check-$(date +%Y%m%d%H%M%S)" \
  --query 'assessment.assessmentArn' --output text)

for i in $(seq 1 30); do
  STATUS=$(aws resiliencehub describe-assessment \
 --assessment-arn "$ASSESSMENT_ARN" \
 --query 'assessment.assessmentStatus' --output text)
  [ "$STATUS" = "Success" ] && break
  [ "$STATUS" = "Failed" ] && { echo "アセスメント失敗"; exit 1; }
  sleep 30
done

COMPLIANCE=$(aws resiliencehub describe-assessment \
  --assessment-arn "$ASSESSMENT_ARN" \
  --query 'assessment.complianceStatus' --output text)
[ "$COMPLIANCE" = "PolicyBreached" ] && { echo "回復性目標未達: パイプライン停止"; exit 1; }

GitHub Actions統合

GitHub ActionsのワークフローファイルにAWS認証（OIDC）とアセスメント実行ステップを追加します。aws-actions/configure-aws-credentialsでIAMロールを引き受け、上記のシェルスクリプトをステップとして組み込む構成が最もシンプルです。PRマージ後のデプロイパイプラインに組み込むことで、リリースごとの回復性確認を自動化できます。

アセスメント結果のSlack/SNS通知設定

アセスメント完了時の自動通知はEventBridgeルールとSNSトピックを組み合わせて設定します。

# EventBridgeルール: アセスメント完了イベントをSNSに転送
aws events put-rule \
  --name "resilience-hub-assessment-complete" \
  --event-pattern '{
 "source": ["aws.resiliencehub"],
 "detail-type": ["Resilience Hub Application Assessment Result"]
  }'

SNS通知の本文にはアセスメントARN、Resiliency Score、コンプライアンス状態（PolicyMet/PolicyBreached）が含まれます。LambdaでこのSNSイベントを受け取り、Slack Incoming Webhookに整形して送信することで、アセスメント完了の即時通知が実現できます。通知メッセージにはコンソールへの直リンクを含めると、レポート確認までの時間を短縮できます。

4. FIS連携とゲームデーによる回復性検証

アセスメントで推定したRTO/RPOが実際の障害で達成できるかは、FIS（Fault Injection Service）による実験で検証します。本章ではResilience HubのFIS推奨機能とゲームデー統合を扱います。

4-1. Resilience HubのFIS推奨機能

FIS推奨統合は2024年12月のGAで正式提供が開始されました。アプリケーションをResilience Hubにオンボードすると、Resilience HubはそのアーキテクチャをAppComponent単位で解析し、リスクの高いコンポーネントに対してFIS実験テンプレートを推奨します。推定RTO/RPOだけでは確認できない実際の障害耐性を、実験で検証するサイクルを起点となります。

推奨生成の仕組み

アセスメント完了後、Resilience Hubは各AppComponentの構成情報（インスタンスタイプ、Multi-AZ設定、RDSフェイルオーバー設定、ELBのヘルスチェック設定等）を解析します。単一障害点（SPOF）やフェイルオーバー未検証の構成を検出すると、そのコンポーネント向けのFIS実験テンプレートを自動生成して推奨します。

推奨される実験の種類は構成によって異なります。RDSがシングルAZ構成の場合は「RDSインスタンス停止実験」、EC2がAuto Scalingグループに属さない場合は「EC2インスタンス終了実験」、ELBターゲットが1台のみの場合は「ターゲット強制切り離し実験」といった形で、アプリの弱点に対応した実験が推奨されます。

コンソールからの実験開始手順

推奨FIS実験はコンソールから数クリックで開始できます。

1. Resilience Hubコンソールで対象アプリを開きます
2. 「推奨事項」→「FIS実験」タブを選択します
3. 推奨された実験テンプレートの一覧が表示されます
4. 実験対象のテンプレートを選択し「FIS実験を作成」をクリックします
5. Resilience HubがFIS実験テンプレートを自動作成し、FISコンソールに遷移します
6. FISコンソールで実験を開始します

# FIS推奨実験テンプレートの一覧をCLIで確認する
aws resiliencehub list-app-component-recommendations \
  --assessment-arn "arn:aws:resiliencehub:ap-northeast-1:123456789012:app-assessment/xxxxxxxx" \
  --query 'componentRecommendations[*].recommendationItems[?targetDestination==`FIS`]' \
  --output json

推奨実験の更新タイミング

FIS推奨はアセスメントごとに更新されます。アプリの構成変更（例: Multi-AZ有効化による改善）を行った後にアセスメントを再実行すると、改善済みの項目は推奨リストから除外されます。逆に新たなSPOFが生じた場合は新しい推奨実験が追加されます。

4-2. ゲームデーの設計と実行

ゲームデーの目的

ゲームデーは2つの目的を兼ねる定期イベントです。1つ目は機能リリース前の回復性検証で、本番と同等のトラフィックが流れる環境で実際の障害を注入し、RTO/RPO目標を達成できることを確認します。2つ目はオンコール訓練で、障害シナリオを事前に設計してチームが実際に対応することで、障害対応のスキルと連絡フローを磨きます。

検証サイクルの設計

Resilience Hub推奨に基づくゲームデーの実行サイクルは次のように設計します。

フェーズ1: 事前準備（ゲームデーの1週間前）

1. アセスメントを実行して最新のFIS推奨実験一覧を取得します
2. 今回のゲームデーで検証する実験シナリオを選定します（推奨High優先度から選ぶ）
3. 実験対象リソースとブラストラジウス（影響範囲）を確認します
4. FIS実験テンプレートをコンソールまたはCLIで事前作成します
5. ロールバック手順とエスカレーションフローをRunbook（SSM SOP）に記録します

フェーズ2: 実験実施（ゲームデー当日）

# FIS実験の開始（事前作成のテンプレートから）
aws fis start-experiment \
  --experiment-template-id "EXT-xxxxxxxxxxxxxxxx" \
  --tags '{"purpose":"game-day","date":"20260606"}'

実験開始後はCloudWatchダッシュボードでRTO/RPO達成状況をリアルタイム監視します。目標時間内にサービスが復旧したか、アラームが期待通りに発火したかを記録します。

フェーズ3: フィードバックと改善（ゲームデーの翌日）

1. 実験結果をResilience Hubに記録します（コンソールの「ゲームデー」タブ）
2. Resiliency Scoreへの影響（スコアが改善・維持・悪化したか）を確認します
3. RTO/RPO未達項目をバックログに登録し、次のスプリントで対応します
4. 翌週のアセスメントで改善効果を確認します

SOPと実験テンプレートの連携

FIS実験と合わせてResilience Hubが推奨するSOPを使うと、実験中の対応手順が標準化されます。たとえば「RDSフェイルオーバー実験」に対応するSOPには「Multi-AZフェイルオーバー開始の確認→CloudWatchアラーム確認→接続復旧確認」の手順が含まれており、ゲームデーのRunbookとしてそのまま活用できます。

ゲームデー結果のResiliency Scoreへの反映

ゲームデーで実際のRTO/RPOを計測した結果が推定値と乖離していた場合は、その結果をフィードバックとしてResilience Hubに記録できます。コンソールの「ゲームデー」タブから実験結果（達成RTO/RPO）を入力すると、次回アセスメントの推定精度改善に活用されます。

# ゲームデー結果の記録（コンソールからのフィードバック送信）
# CLIでは describe-assessment の結果に基づき、
# 実績値との差分をカスタムメトリクスとしてCloudWatchに記録する方法が一般的
aws cloudwatch put-metric-data \
  --namespace "ResilienceHub/GameDay" \
  --metric-data '[{"MetricName":"ActualRTOMinutes","Value":45,"Unit":"Count"}]'

4-3. 既存FIS記事との棲み分け

本記事とFIS記事の役割分担

本記事（Resilience Hub中心）と既存のカオスエンジニアリング記事（FIS個別手順中心）は、回復性検証の異なるレイヤーを担います。

両者は補完関係にあります。Resilience Hubが「どのコンポーネントに何の実験が必要か」を上流で決定し、FIS個別手順でその実験を詳細に実装します。

連携フローの例

実際の運用では次のように連携します。

1. Resilience Hubのアセスメントで「checkout-api AppComponentのAZ障害耐性が低い」と検出
2. Resilience HubがFIS推奨として「EC2インスタンス停止実験（AZ-a）」を提示
3. 本記事の手順に従い、コンソールからFIS実験テンプレートを生成して実行
4. 実験の詳細なテンプレート設計（IAMロール設定、停止ターゲット選定、監視設定）が必要な場合は既存FIS記事を参照
5. 実験結果をResilience Hubにフィードバックし、次回アセスメントで改善を確認

参照ガイド

FIS実験テンプレートの詳細な実装手順（IAMロール設定、実験アクションの構成、ターゲット選定のフィルタリング等）は既存のカオスエンジニアリング記事を参照してください。本記事ではResilience Hub推奨に基づく検証ループ（何を検証するかの上流統制）に焦点を当てています。

FIS実験テンプレートの詳細を読む

5. クロスリージョンDRと復旧制御

Resilience Hubのアセスメントが「リージョン障害時のRTO/RPOを目標内に収めるには、クロスリージョンBackupとフェイルオーバー制御が必要」と推奨した場合、その実装は本章で扱う2つのコンポーネントに委ねられます。AWS Backupはデータを保護し、Amazon Application Recovery Controller（ARC）はトラフィックの切り替え制御を担います。本章では各コンポーネントの設定例と組み合わせ方を解説します。

5-1. AWS Backupによるクロスリージョン保護

AWS BackupはS3・EBS・RDS・DynamoDB・EFSなど複数サービスのバックアップを統合管理し、クロスリージョンコピーを自動化します。Resilience HubはアセスメントでBackupの設定状況を評価し、RTO/RPO目標との乖離を検出します。

クロスリージョンコピーの設定

BackupPlanにクロスリージョンコピーアクションを追加することで、プライマリリージョン（例: ap-northeast-1）からDRリージョン（例: us-east-1）へ自動コピーが実行されます。CLIでのBackupPlan作成例を示します。

aws backup create-backup-plan \
  --backup-plan '{
 "BackupPlanName": "cross-region-dr-plan",
 "Rules": [{
"RuleName": "daily-backup",
"TargetBackupVaultName": "primary-vault",
"ScheduleExpression": "cron(0 2 * * ? *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 180,
"Lifecycle": {"DeleteAfterDays": 35},
"CopyActions": [{
  "DestinationBackupVaultArn": "arn:aws:backup:us-east-1:123456789012:backup-vault:dr-vault",
  "Lifecycle": {"DeleteAfterDays": 90}
}]
 }]
  }' \
  --region ap-northeast-1

CloudFormationでの定義例は以下のとおりです。

BackupPlan:
  Type: AWS::Backup::BackupPlan
  Properties:
 BackupPlan:
BackupPlanName: cross-region-dr-plan
BackupPlanRule:
  - RuleName: daily-backup
 TargetBackupVaultName: !Ref PrimaryVault
 ScheduleExpression: "cron(0 2 * * ? *)"
 StartWindowMinutes: 60
 CompletionWindowMinutes: 180
 Lifecycle:
DeleteAfterDays: 35
 CopyActions:
- DestinationBackupVaultArn: !Sub >-
 arn:aws:backup:us-east-1:${AWS::AccountId}:backup-vault:dr-vault
  Lifecycle:
 DeleteAfterDays: 90

Vault Lockによる改ざん防止

AWS BackupのVault Lock（WORM: Write Once Read Many）を有効化すると、保存期間内のバックアップデータを削除・変更できなくなります。ランサムウェア攻撃やオペレーションミスによるバックアップ消去を防ぐ重要な設定です。

Vault Lockには2つのモードがあります。Governance Modeは適切なIAM権限を持つユーザーが設定を変更できるモードで、テスト・段階的導入に適しています。Compliance Modeは設定後に変更・削除が一切できないモードで、規制要件（PCI DSS・HIPAA等）対応に使われます。

# Vault Lock設定（Governance Mode）
aws backup put-backup-vault-lock-configuration \
  --backup-vault-name dr-vault \
  --min-retention-days 7 \
  --max-retention-days 365 \
  --region us-east-1

Compliance ModeはCooling-off期間（デフォルト72時間）を経過すると変更不可になるため、十分なテストを行ってから適用してください。Governance Modeで運用実績を積んだ後にCompliance Modeへ移行するのが一般的です。

Resilience HubとのBackup連携

Resilience HubはアプリのAppComponentに関連するリソースのバックアップ設定を評価します。例えば「RDSインスタンスのRPO目標が1時間だが、バックアップスケジュールが24時間間隔」の場合、アセスメントでNon-Compliantとマークされます。Resilience Hubの推奨事項にBackupスケジュールの短縮が含まれている場合、BackupPlanのScheduleExpressionを調整することでコンプライアンスを達成できます。

クロスリージョンBackupの詳細な実装手順（バックアップ対象リソースの選定・保持ポリシーの設計・コスト試算）は既存の専門記事を参照してください。

AWS Backupクロスリージョン詳細を読む

5-2. Application Recovery Controller（ARC）による復旧制御

Amazon Application Recovery Controller（ARC）はアプリケーションのフェイルオーバーと復旧を制御するサービスです。ARCはReadiness Check・Routing Control・Zonal Shiftの3つのコンポーネントで構成されています。それぞれの役割と最新の提供状況を正確に理解した上で設計に組み込む必要があります。

Routing Controlによるフェイルオーバー制御

Routing Controlはリージョン間フェイルオーバーの手動・自動切り替えを提供します。Route53 ARCクラスター内のコントロールパネルにルーティングコントロールを作成し、Route53ヘルスチェックと紐付けることでDNSフェイルオーバーを制御します。

料金は$2.50/時（1クラスターあたり）で、1アカウントあたり最大2クラスターまで作成できます。高可用性を確保するため、クラスターは複数の独立したロケーション（コントロールプレーン）にまたがって配置されます。フェイルオーバー時にクラスター自体が影響を受けないよう、コントロールプレーンはプロダクションリージョンとは独立しています。

# Routing Controlの状態確認
aws route53-recovery-control-config list-routing-controls \
  --control-panel-arn arn:aws:route53-recovery-control::123456789012:controlpanel/xxxx

# フェイルオーバー実行（Routing ControlをOFFに切り替え）
aws route53-recovery-cluster update-routing-control-state \
  --routing-control-arn arn:aws:route53-recovery-control::123456789012:controlpanel/xxxx/routingcontrol/yyyy \
  --routing-control-state Off \
  --region ap-northeast-1

Zonal Shiftによるアベイラビリティゾーン退避

Zonal ShiftはAZ単位でのトラフィック退避機能です。特定のAZで障害が発生した際に、そのAZへのトラフィックを即座に他のAZへ移動させます。追加料金なしで利用でき、数分以内にAZ障害から退避できる点が特長です。対応ロードバランサーはApplication Load Balancer（ALB）とNetwork Load Balancer（NLB）です。

# Zonal Shiftの開始（AZ: apne1-az1 からの退避）
aws arc-zonal-shift start-zonal-shift \
  --resource-identifier "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:loadbalancer/app/my-alb/xxxx" \
  --away-from apne1-az1 \
  --expires-in 2h \
  --comment "AZ障害対応のためZonal Shift実行"

# Zonal Shiftの状態確認
aws arc-zonal-shift list-zonal-shifts \
  --region ap-northeast-1

Routing Control vs Zonal Shift の使い分け

リージョン全体の障害や計画的なDR切り替えにはRouting Controlを、AZ単位の障害には追加料金なしのZonal Shiftを優先的に活用するのが基本方針です。両者を組み合わせることで、AZ障害からリージョン障害まで段階的な復旧制御体制を構築できます。

5-3. フェイルオーバーの自動化

手動フェイルオーバーはオペレーション遅延のリスクがあります。障害発生から対応まで数十分かかることも珍しくなく、RTOを分単位で達成するにはヘルスチェックと自動フェイルオーバーを組み合わせた自動化が不可欠です。

Route53ヘルスチェックとフェイルオーバールーティング

Route53のフェイルオーバールーティングポリシーを使用すると、プライマリエンドポイントが応答しなくなった際に自動でセカンダリエンドポイントへ切り替わります。ヘルスチェックの失敗閾値とリトライ間隔を調整することで、フォールスポジティブを抑えつつ迅速なフェイルオーバーを実現します。

# Route53ヘルスチェック作成
aws route53 create-health-check \
  --caller-reference "primary-app-hc-001" \
  --health-check-config '{
 "IPAddress": "203.0.113.10",
 "Port": 443,
 "Type": "HTTPS",
 "ResourcePath": "/health",
 "FailureThreshold": 3,
 "RequestInterval": 10
  }'

Lambda + EventBridgeによるフェイルオーバー自動化

Resilience Hubの評価結果やCloudWatchアラームをトリガーに、Routing ControlのState切り替えを自動実行するLambda関数を設計します。EventBridgeルールでRoute53ヘルスチェックのステータス変化をキャプチャし、Lambda関数を呼び出す構成にします。

import boto3

def handler(event, context):
 arc = boto3.client('route53-recovery-cluster', region_name='ap-northeast-1')
 routing_control_arn = event.get(
  'routing_control_arn',
  'arn:aws:route53-recovery-control::123456789012:controlpanel/xxxx/routingcontrol/yyyy'
 )
 target_state = event.get('target_state', 'Off')
 arc.update_routing_control_state(
  RoutingControlArn=routing_control_arn,
  RoutingControlState=target_state
 )
 sns = boto3.client('sns')
 sns.publish(
  TopicArn='arn:aws:sns:ap-northeast-1:123456789012:dr-failover-alerts',
  Subject='DR Failover Initiated',
  Message=f'Routing Control {routing_control_arn} set to {target_state}'
 )
 return {'statusCode': 200, 'state': target_state}

詳細なマルチリージョン構成（Active-Active/Active-Passiveの設計・Aurora Global Database連携等）は専門記事を参照してください。

マルチリージョン構成の詳細を読む

6. 回復性ドリフト検知と継続的統制

構成変更は日々の運用の中で積み重なります。新機能のデプロイ・スケーリング設定の変更・インフラの更新がRTO/RPO目標からの乖離（ドリフト）を引き起こします。Resilience Hubのドリフト検知機能は、こうした変化を自動検出し継続的な統制を可能にします。「DRテストは合格した」という静的な状態管理から、「常に回復性目標を満たしている」という動的な統制体制への移行がこの章のテーマです。

6-1. 回復性ドリフトとは

ドリフトとは、Resilience Hubに登録されたアプリケーションのコンプライアンス状態が前回アセスメントから変化した状態を指します。Resilience Hubのドリフト検知機能は2023年8月2日にGA（Generally Available）として正式リリースされ、2024年5月に拡張されてより詳細なRTO/RPOドリフトメトリクスが追加されました。

ドリフトが発生するケース

アプリのAppComponent設定変更・リソースの追加削除・Resiliency Policyの変更がドリフトを引き起こします。以下のような日常的な運用操作がドリフトの原因になります。

• RDSインスタンスのマルチAZ設定を無効化 → インフラ中断のRTO目標が未達に
• Auto Scalingのmin/max値変更 → アプリ層の回復性評価が変化
• バックアップスケジュールの変更 → RPO目標との乖離が発生
• Lambdaコンカレンシー設定の変更 → サーバーレス層の推定RTOが変化
• セキュリティグループの変更 → ヘルスチェック到達性への影響

ドリフトメトリクスの例

Resilience Hubはドリフト発生時に以下のようなメトリクスを提示します。前回アセスメントとの差分が「ドリフト量」として表示され、原因となった構成変更のタイムスタンプも追跡できます。

AppComponent: web-tier
前回アセスメント (2026-05-01):
  推定RTO: 1時間20分 / RTO目標: 2時間 → Compliant

今回アセスメント (2026-06-06):
  推定RTO: 2時間40分 / RTO目標: 2時間 → Non-Compliant
  RTO drift: +1時間20分（前回から80分逸脱）

原因候補: マルチAZ設定の変更（2026-05-28のデプロイで検出）
推奨アクション: マルチAZ再有効化 または RTO目標の見直し

ドリフト検知がない場合のリスク

ドリフト検知なしに運用する場合、構成変更後にRTO/RPOが悪化しても実際の障害発生まで気づけません。「DRテストは半年前に合格した」という認識のまま、実際の障害時には目標を大幅に超える復旧時間がかかる事態に陥ります。特に複数チームが並行してインフラを変更する環境では、誰も意図していない変化の積み重ねが回復性を静かに劣化させます。継続的なドリフト監視は「DR目標の形骸化」を防ぐ仕組みです。

6-2. ドリフト通知の設定

Resilience Hubはアセスメント結果をAmazon SNSに通知する機能を提供します。ドリフト発生時にリアルタイムで通知を受け取ることで、迅速な是正対応が可能になります。

SNS統合によるドリフト通知設定

CLIでSNSトピックをResilience Hubのイベントサブスクリプションとして登録します。

# SNSトピック作成
aws sns create-topic \
  --name resilience-hub-drift-alerts \
  --region ap-northeast-1

# アセスメント結果ドリフト通知の設定
aws resiliencehub update-app \
  --app-arn arn:aws:resiliencehub:ap-northeast-1:123456789012:app/xxxx \
  --event-subscriptions '[{
 "eventType": "DriftDetected",
 "name": "drift-alert-subscription",
 "snsTopicArn": "arn:aws:sns:ap-northeast-1:123456789012:resilience-hub-drift-alerts"
  }]'

# SNSサブスクリプション（メール通知）
aws sns subscribe \
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:resilience-hub-drift-alerts \
  --protocol email \
  --notification-endpoint oncall-team@example.com

CloudFormationでの設定例を示します。

ResilienceHubApp:
  Type: AWS::ResilienceHub::App
  Properties:
 Name: my-production-app
 ResiliencyPolicyArn: !Ref ResiliencyPolicy
 EventSubscriptions:
- EventType: DriftDetected
  Name: drift-alert-subscription
  SnsTopicArn: !Ref DriftAlertTopic

EventBridge + Lambdaによる自動再アセスメントトリガー

インフラ変更を検知して自動的に再アセスメントを実行することで、ドリフトを変更直後に発見できます。CloudTrailのAPIコールをEventBridgeで監視し、Lambdaで再アセスメントを起動する構成です。

import boto3

def handler(event, context):
 client = boto3.client('resiliencehub', region_name='ap-northeast-1')
 app_arn = 'arn:aws:resiliencehub:ap-northeast-1:123456789012:app/xxxx'
 client.publish_app_version(appArn=app_arn)
 response = client.start_app_assessment(
  appArn=app_arn,
  appVersion='release',
  assessmentName=f"auto-reassessment-{context.aws_request_id[:8]}"
 )
 return {'assessmentArn': response['assessment']['assessmentArn']}

CloudWatchアラームとのSLO逸脱アラート連携

アセスメント結果のドリフト量をCloudWatchカスタムメトリクスとして記録し、RTO/RPO目標逸脱時にアラームを上げます。

# RTO逸脱量のカスタムメトリクス送信
aws cloudwatch put-metric-data \
  --namespace "ResilienceHub/Compliance" \
  --metric-name "RTODriftMinutes" \
  --dimensions "AppArn=arn:aws:resiliencehub:ap-northeast-1:123456789012:app/xxxx" \
  --value 80 \
  --unit Minutes \
  --region ap-northeast-1

# CloudWatchアラーム設定（RTO逸脱が30分を超えたら通知）
aws cloudwatch put-metric-alarm \
  --alarm-name rto-drift-alert \
  --namespace ResilienceHub/Compliance \
  --metric-name RTODriftMinutes \
  --threshold 30 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --period 300 \
  --statistic Maximum \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:resilience-hub-drift-alerts \
  --alarm-description "Resilience Hub RTO drift exceeded 30 minutes"

マルチアカウントアセスメント: AWS Organizationsとの統合

複数アカウントを管理する組織では、AWS Organizationsと連携することでアカウント横断のドリフト状況を一元監視できます。管理アカウントからメンバーアカウントのResilience Hubアプリのコンプライアンス状況を集約し、組織全体の回復性ポスチャーを把握します。

# マルチアカウントのアセスメント結果を一覧表示
aws resiliencehub list-app-assessments \
  --assessment-status Completed \
  --query 'assessmentSummaries[].{App:appName,Status:complianceStatus,Date:endTime}' \
  --output table \
  --region ap-northeast-1

Organizations統合では、Security HubやAWS Configと組み合わせてアカウント横断のコンプライアンスダッシュボードを構築するアーキテクチャが多く採用されています。

6-3. 継続的統制の運用設計

ドリフトを検知するだけでは不十分です。「検知 → 通知 → 修正 → 再アセスメント → 確認」の統制ループを運用プロセスに組み込むことで、回復性の継続的な維持が実現します。

Resilience Lifecycle Frameworkの考え方

AWSはResilience Lifecycle Frameworkとして、回復性の継続的改善サイクルを提唱しています。

1. Identify（識別）: アプリケーションをResilience Hubに登録し、ビジネスクリティカリティを評価する
2. Assess（評価）: Resiliency Policyに対してアセスメントを実行し、現状の回復性レベルを定量測定する
3. Improve（改善）: 推奨事項に基づき、不足している回復性を補う設定変更・アーキテクチャ修正をする
4. Test（検証）: FIS実験・ゲームデーにより、設計上のRTO/RPOが実際に達成できるか確認する
5. Monitor（監視）: ドリフト検知・SNS通知・CloudWatchアラームにより、継続的に逸脱を監視する

このサイクルを自動化・継続化することが回復性統制の本質です。1回限りのDRテスト合格ではなく、常時稼働する統制ループとして運用します。

CI/CDパイプライン統合

デプロイのたびに自動アセスメントを実行し、ドリフトが発生したらパイプラインを停止する統合を構築します。GitHub Actionsでの実装例を示します。

jobs:
  resilience-check:
 runs-on: ubuntu-latest
 steps:
- name: Publish App Version
  run: |
 aws resiliencehub publish-app-version \
--app-arn ${{ secrets.RESILIENCE_APP_ARN }} \
--region ap-northeast-1

- name: Start Assessment
  id: assessment
  run: |
 ARN=$(aws resiliencehub start-app-assessment \
--app-arn ${{ secrets.RESILIENCE_APP_ARN }} \
--app-version release \
--assessment-name "ci-$(echo ${{ github.sha }} | cut -c1-8)" \
--query 'assessment.assessmentArn' --output text \
--region ap-northeast-1)
 echo "assessment_arn=$ARN" >> $GITHUB_OUTPUT

- name: Wait for Assessment
  run: |
 STATUS="InProgress"
 while [ "$STATUS" = "InProgress" ]; do
sleep 30
STATUS=$(aws resiliencehub describe-app-assessment \
  --assessment-arn ${{ steps.assessment.outputs.assessment_arn }} \
  --query 'assessment.assessmentStatus' --output text \
  --region ap-northeast-1)
 done

- name: Check Compliance
  run: |
 COMPLIANCE=$(aws resiliencehub describe-app-assessment \
--assessment-arn ${{ steps.assessment.outputs.assessment_arn }} \
--query 'assessment.complianceStatus' --output text \
--region ap-northeast-1)
 if [ "$COMPLIANCE" != "PolicyMet" ]; then
echo "::error::Resilience assessment failed: $COMPLIANCE"
exit 1
 fi

ドリフト検知→修正→再アセスメントの運用ループ設計

ドリフト通知を受け取ってから再コンプライアンスを達成するまでの標準フローを設計します。

1. SNS通知でオンコールチームに即時アラート（ドリフト発生AppComponent・逸脱量を通知）
2. アセスメントレポートで非準拠のAppComponentとドリフト原因を特定
3. 推奨事項に従いインフラ修正（Backupスケジュール変更・マルチAZ再有効化等）
4. 修正後にCI/CDパイプラインで自動再アセスメントを実行
5. アセスメントがPolicyMetを返したら是正完了・チケットクローズ

デプロイゲートとしての活用

RTO/RPO逸脱が検出された場合、デプロイを停止するゲートを実装することで回復性の劣化を本番環境に持ち込まないプロセスが実現します。CI/CDパイプラインでアセスメントがPolicyMet以外になった場合、パイプラインを失敗させドリフトが修正されるまでデプロイをブロックします。これにより「デプロイしてから後で気づく」問題を「デプロイ前に気づく」設計に転換できます。

7. 実戦統合 — 既存DR部品の組み合わせ

Resilience Hubは単独で使うより、FIS・AWS Backup・マルチリージョン構成・Aurora DRといった既存の構成部品と組み合わせることで真価を発揮します。本章では、Resilience Hubを統制レイヤーの中心に置き、各構成部品との責務を分界した上で、実戦的な3つの統合パターンを示します。各パターンには設定例を添え、自チームの状況に合わせて選択・組み合わせられるよう整理します。

7-1. 統制レイヤーと構成部品の責務分界

回復性エンジニアリングで陥りやすい失敗の一つが、ツールごとの責務を曖昧にしたまま運用を組むことです。「FISを入れた＝回復性が担保されている」「Backupを設定した＝DRは完了」といった誤解は、ツールの役割を混同するところから生まれます。本節では、Resilience Hubを統制レイヤーとして位置づけ、各構成部品の責務を明確に分界します。

この分界の核心は、Resilience Hubは「何を達成すべきか（RTO/RPO）」の目標管理と「現在達成できているか」の継続的測定を担い、他のツールはその目標を実現するための手段という関係です。FIS実験の結果もResilience Hubのアセスメントスコアに反映され、Backupのクロスリージョン設定もResiliency Policyへの準拠を通じて評価されます。

統合パターンA — Resilience Hub + FIS + Backup の三層構成

最も基本的な統合パターンです。Resilience HubでRTO/RPO目標を設定し（統制レイヤー）、FIS推奨によるゲームデーで回復性を検証し（検証レイヤー）、Backup Vault Lockでデータ保護を担保します（保護レイヤー）。

# EventBridge → Lambda で週次アセスメントを自動化する設定例
AWSTemplateFormatVersion: "2010-09-09"
Resources:
  ResilienceAssessmentSchedule:
 Type: AWS::Events::Rule
 Properties:
Name: weekly-resilience-assessment
ScheduleExpression: "cron(0 2 ? * MON *)"
State: ENABLED
Targets:
  - Id: ResilienceAssessmentLambda
 Arn: !GetAtt ResilienceAssessmentFunction.Arn

  ResilienceAssessmentFunction:
 Type: AWS::Lambda::Function
 Properties:
FunctionName: resilience-hub-assessment-trigger
Runtime: python3.12
Handler: index.handler
Environment:
  Variables:
 APP_ARN: !Sub "arn:aws:resiliencehub:${AWS::Region}:${AWS::AccountId}:app/YOUR_APP_ID"
Code:
  ZipFile: |
 import boto3, os

 def handler(event, context):
  client = boto3.client("resiliencehub")
  app_arn = os.environ["APP_ARN"]
  # アプリを最新リソースに同期してからアセスメント開始
  client.publish_app_version(appArn=app_arn)
  resp = client.start_app_assessment(
appArn=app_arn,
assessmentName="weekly-auto-assessment",
  )
  return resp["assessment"]["assessmentArn"]

この Lambda を EventBridge Scheduler で週次実行することで、毎週月曜深夜 2 時に最新のアセスメントが自動的に実施されます。アセスメント完了後にドリフトが検知された場合は、SNS経由でオンコールチームへ通知するフローと組み合わせることを推奨します。

Backup Vault Lock との連携では、アセスメントでRPO目標を満たさないコンポーネントが検出された際に、当該リソースのバックアップポリシーを自動的に強化する仕組みを実装できます。たとえば、RPO目標が2時間のコンポーネントでバックアップ頻度が4時間ごとに設定されていた場合、アセスメントレポートのAPI出力をトリガーにBackupプランを更新する自動修復パイプラインが有効です。

統合パターンB — マルチリージョン + ARC Routing Control + ドリフト検知

リージョン障害への対応が必要なワークロード向けのパターンです。マルチリージョン構成（既存記事参照）を基盤とし、ARCのRouting ControlでフェイルオーバーをResilience Hubの継続的アセスメントで統制します。

# ARC Routing Control によるフェイルオーバー操作の例
# クラスターARNとRouting Control ARNは事前に取得しておく

CLUSTER_ENDPOINT="https://YOUR_CLUSTER_ENDPOINT.route53-recovery-cluster.amazonaws.com/v1"
ROUTING_CONTROL_ARN="arn:aws:route53-recovery-control::ACCOUNT_ID:controlpanel/PANEL/routingcontrol/CONTROL_ID"

# プライマリリージョンのトラフィックをオフに切り替え
aws route53-recovery-cluster update-routing-control-state \
  --endpoint-url "${CLUSTER_ENDPOINT}" \
  --routing-control-arn "${ROUTING_CONTROL_ARN}" \
  --routing-control-state Off

# セカンダリリージョンのRouting Controlをオンに（別リージョンで実行）
aws route53-recovery-cluster update-routing-control-state \
  --endpoint-url "${DR_CLUSTER_ENDPOINT}" \
  --routing-control-arn "${DR_ROUTING_CONTROL_ARN}" \
  --routing-control-state On

このパターンでは、Resilience Hubのアセスメントをプライマリ・セカンダリ両リージョンで独立して実施し、両リージョンのRTO/RPO充足状況を継続的に追跡することが重要です。セカンダリリージョンが常にフェイルオーバー可能な状態を維持しているかを定量的に確認できるため、「いざフェイルオーバーしたら実は回復性が低下していた」という事態を防ぎます。

ドリフト検知の観点では、マルチリージョン構成はプライマリ側の変更がセカンダリ側に伝播されないケースが多く、非対称ドリフトが発生しやすい環境です。両リージョンのアセスメントスコアを比較する定期レポートをCloudWatch Dashboardで可視化することを推奨します。

統合パターンC — CI/CD統合型継続的回復性統制

デプロイパイプラインにResilience Hubのアセスメントを組み込み、「コードをマージするたびに回復性が評価される」状態を作るパターンです。本番デプロイ後のドリフト検知をゼロに近づける最も積極的なアプローチです。

# CodePipeline の Post-Deploy ステージにアセスメントを追加する例
# buildspec.yml（アセスメント実行ステージ）
version: 0.2
phases:
  build:
 commands:
# アプリバージョンを最新リソースで更新
- |
  aws resiliencehub publish-app-version \
 --app-arn "${APP_ARN}"
# アセスメント開始
- |
  ASSESSMENT_ARN=$(aws resiliencehub start-app-assessment \
 --app-arn "${APP_ARN}" \
 --assessment-name "post-deploy-$(date +%Y%m%d%H%M%S)" \
 --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
 [ "${STATUS}" = "Failed" ] && exit 1
 sleep 30
  done
# コンプライアンス状態を確認（Policy違反があれば非ゼロ終了）
- |
  COMPLIANCE=$(aws resiliencehub describe-app-assessment \
 --assessment-arn "${ASSESSMENT_ARN}" \
 --query "assessment.complianceStatus" \
 --output text)
  [ "${COMPLIANCE}" = "PolicyBreached" ] && \
 { echo "RESILIENCE POLICY BREACHED — deployment blocked"; exit 1; }
  echo "Resilience assessment passed: ${COMPLIANCE}"

このパターンの利点は、問題を本番環境での長期ドリフトとして検知するのではなく、デプロイ単位で即座に検知できることです。コンプライアンス違反をデプロイのブロック条件にするか、警告のみにするかは、チームのリスク許容度に合わせて調整してください。まず警告のみで開始し、運用チームが評価に慣れた段階でブロック条件に昇格させるアプローチが実践的です。

7-2. シリーズ全体ロードマップ

既存DR記事の読み順ガイド

本シリーズと既存DR記事群を組み合わせて読む場合、以下の順序が最も体系的に理解を積み上げられます。

まず本記事（Vol1）でRTO/RPO目標を設定し、Resiliency PolicyとResilience Hubアセスメントによる測定の仕組みを理解します。次に、カオスエンジニアリング（FIS実験テンプレート）記事でFIS実験の実装を習得し、§4で解説したゲームデー統合に適用してください。データ保護とリージョンフェイルオーバーについては、クロスリージョンDR記事でVault Lockとバックアッププランの実装を参照し、§5のARC Routing Control設計と組み合わせます。マルチリージョン Active-Active/Active-Passive記事では、§7-1 パターンBの基盤となるリージョン間構成の実装詳細を扱っています。Aurora DR記事は、データベース層のRPO充足確認でResilience Hubと組み合わせる際の参照先です。

各記事は独立して読めますが、「Resilience Hubでまず測る → 足りない構成部品を各記事で補強する」というアプローチが、回復性を体系的に向上させる実践的な順序です。

Vol2以降の想定トピック

本シリーズ「AWSレジリエンス/DR本番運用」は、Vol1で確立した回復性測定・統制の基盤の上に、以下のテーマを扱う続巻を予定しています。

Vol2では、アプリケーション種別ごとのDR設計パターンを扱います。ステートレスAPI・ステートフルDBサービス・バッチ処理・イベント駆動アーキテクチャそれぞれの回復性設計上の特性と、Resilience Hub評価時の注意点を整理します。

Vol3では、DR運用のコスト最適化を取り上げます。Warm Standby構成のリソースを平時に縮小運用しながらRTO目標を維持する方法、スポットインスタンスとの組み合わせによる費用対効果の改善、Backup Vault の階層ストレージ活用といったコスト削減手法を扱います。

Vol4では、SLO（Service Level Objective）管理とResilience Hubの統合を扱います。RTO/RPOをエンジニアリング目標として設定するだけでなく、エラーバジェット管理やService Level Indicatorとの紐付けを通じて、回復性をプロダクトのSLO管理に組み込む体制設計を示します。

カオスエンジニアリング（FIS）の記事を読む
クロスリージョンBackup/DRの詳細を読む

8. つまずきポイント・アンチパターン・まとめ

Resilience Hubを用いたレジリエンス/DR運用は、設計ステップが多く落とし穴も多数あります。本章では現場で実際に直面しやすいつまずきポイントと、陥りやすいアンチパターン・正解パターンを整理したうえで、本記事の要点と実装ロードマップを総括します。

8-1. つまずきポイント

Resilience Hubの評価・運用を始めると、「操作はできているのに期待どおりの結果が出ない」という詰まりが起きやすいです。以下では症状・原因・対処の形式で代表的な8件を解説します。

つまずき1: アプリを登録しただけではアセスメントが動かない

症状: Resilience Hubにアプリケーションを登録したのに、アセスメントスコアが更新されない、あるいはダッシュボードに「Not Assessed」が表示される。

原因: Resilience Hubへのアプリケーション登録とアセスメントの実行は別操作です。登録は「どのリソースを評価対象にするか」を定義するだけであり、アセスメントは明示的に「Run Assessment」を実行するか、CI/CDパイプラインから start-app-assessment APIを呼び出して初めてスコアが算出されます。

対処: 登録完了後に必ずアセスメントを手動実行してください。以降は変更時の自動トリガーを設定するか、定期スケジュールでCI/CDから実行する運用に移行します。

aws resiliencehub start-app-assessment \
  --app-arn arn:aws:resiliencehub:ap-northeast-1:123456789012:app/your-app \
  --app-version release \
  --assessment-name "initial-assessment-$(date +%Y%m%d)"

つまずき2: Resiliency Policy未設定でアセスメントを実行するとスコアが正確に出ない

症状: アセスメントは完了するが、「Policy compliant」や「Policy breached」の判定が出ない。または全コンポーネントが「Not Applicable」になる。

原因: Resilience HubのアセスメントはResiliency Policyで設定したRTO/RPO目標に対して評価します。Policyが未設定の場合、目標との比較ができず、スコアは意味をなしません。

対処: アプリケーション登録後、アセスメント実行前に必ずResiliency Policyを設定してください。Software/Application・Infrastructure・Availability Zone・Regionの4中断タイプそれぞれにRTO/RPO目標を設定します。

つまずき3: ARC Readiness Checkを新規構成に使おうとしたが2026年4月30日に新規顧客向け終了済み

症状: ARC（Application Recovery Controller）のReadiness Checkを新規リソースで設定しようとしたが、コンソールで「利用不可」と表示される、またはAPIで AccessDeniedException が返る。

原因: Amazon ARCのReadiness Checkは2026年4月30日をもって新規顧客向けの提供が終了しています。既存顧客は継続利用できますが、新規設定はできません。

対処: 新規構成にはRouting ControlまたはZonal Shiftを採用してください。Routing Controlはクラスター単位のフェイルオーバー制御、Zonal ShiftはAZ単位の退避（追加料金なし）を提供します。フェイルオーバー検知の自動化にはRoute53 Health CheckとEventBridgeを組み合わせます。

つまずき4: Regionレイヤーのアセスメント結果が改善されない

症状: AppComponentのRTO/RPO推定値がApplicationレイヤーやAZレイヤーでは目標を満たしているのに、Regionレイヤーだけ Policy breached のままになる。

原因: Regionレイヤーの障害に耐えるには、スタンバイリソースや再作成可能なInfraを別リージョンに用意する必要があります。シングルリージョン構成のままではResilience Hubが推定するRegionレイヤーのRTOは大きくなります。

対処: クロスリージョンのリードレプリカや読み書きフェイルオーバーエンドポイント（Auroraのグローバルデータベース等）、Pilot Lightまたは Warm Standby構成をセカンダリリージョンに追加してください。設定後に再アセスメントを実行して目標達成を確認します。

つまずき5: ドリフト検知の通知が届かない

症状: 構成変更後もRTO/RPOドリフトの通知メールが来ない。Resilience Hubのダッシュボードにはドリフトが表示されているのに、オペレーションチームへの通知が機能していない。

原因: Resilience Hubのドリフト検知通知にはSNSトピックとの統合設定が必要です。さらに、CloudWatch EventsルールまたはEventBridgeルールがResilience Hubのイベントをソースとして正しく設定されていない場合は通知されません。

対処:
1. Resilience HubのSNS通知設定（コンソール: Resilience Hub → Notification settings → Add SNS topic）を確認します。
2. EventBridgeルールで source: "aws.resiliencehub" と detail-type: "Resilience Hub Assessment State Change" を指定して通知を確認します。
3. SNSトピックのサブスクリプション（Emailや Lambda）が承認済みかを確認します。

つまずき6: FIS推奨をResilience Hubが生成しない

症状: アセスメントを実行しても「Recommended FIS experiments」のセクションが空になる、または推奨が少なすぎる。

原因: Resilience HubのFIS推奨はAppComponentのマッピングが完全でないと生成されません。CloudFormationスタックを登録しても、ECSサービスやAuto Scaling Groupなどのコンポーネントが正しくマッピングされていない場合、FIS推奨の対象から除外されます。

対処: Resilience HubコンソールのApp Summary画面でAppComponentsを確認し、全てのコンポーネントが正しいタイプ（AWS::ECS::Service、AWS::AutoScaling::AutoScalingGroupなど）にマッピングされているかを確認してください。マッピングが不完全な場合は手動でコンポーネントタイプを編集して再アセスメントします。

つまずき7: アセスメントスコアが上がらない

症状: 推奨事項（Recommended SOPs・アラーム設定）を確認したのにアセスメントスコアが改善されない。

原因: Resilience HubのRecommended SOPsは「推奨アクション一覧」です。コンソールで確認しただけでは実装されたことにならず、実際にSOP文書を作成してRunbookとして登録するか、推奨アラームをCloudWatchに設定して再アセスメントするまでスコアは変わりません。

対処: Recommended SOPsの内容を確認し、対応するCloudWatchアラームやRunbookを実際に作成してください。変更後に再アセスメントを実行するとスコアに反映されます。Recovery Procedure（回復手順）のRunbook登録はスコア向上に直結します。

つまずき8: CI/CDパイプライン統合時のAPIスロットリング

症状: CodePipelineやGitHub ActionsからResilience Hub APIを呼び出すと、高頻度のプッシュ時に ThrottlingException が返ってアセスメントが失敗する。

原因: Resilience Hub APIにはサービスクォータが設定されており、StartAppAssessmentは1秒あたり2リクエストに制限されています（デフォルト値）。モノレポや複数アプリを同時評価する構成では容易にクォータに達します。

対処: アセスメント実行をシリアル化するか、指数バックオフ付きリトライを実装してください。高頻度が必要な場合はService Quotasコンソールからクォータ引き上げを申請します。また、Scheduled Assessmentを使って定期実行と差分検知を組み合わせることで、都度実行の頻度を下げる設計も有効です。

8-2. アンチパターン → 正解

実際の運用でよく見られる誤ったアプローチと、それに対応する正解パターンを対比形式で整理します。

アンチパターン1: 手動でRTO/RPOを推測してドキュメントに書くだけ

アンチパターン2: Resiliency Policyを1種類だけ定義してすべてのアプリに適用

アンチパターン3: ドリフト検知を使わず構成変更後にRTO劣化を見逃す

アンチパターン4: FIS実験を年1回のゲームデーのみで実施

アンチパターン5: ARCのReadiness Checkを新規構成に使おうとする

アンチパターン6: Resilience Hub評価でBackupコンポーネントを見落とす

8-3. まとめ

本記事の総括

本記事では、AWS Resilience Hubを中心とした「回復性の測定・統制レイヤー」の全体像を解説しました。

Resilience Hubは単なる可視化ツールではなく、ビジネス要件から導いたRTO/RPO目標をResiliency Policyとして明文化し、アプリケーションの構成を定量的にアセスメントする「上流設計の核」として機能します。従来は「たぶん30分で復旧できる」という定性的な判断に頼っていたDR設計を、推定RTO/RPOによる定量評価へと転換します。

本記事が扱った5つの運用ループを振り返ります。

§2 RTO/RPO戦略とResiliency Policy設計

Backup＆Restore・Pilot Light・Warm Standby・Multi-site Active-Activeの4戦略のトレードオフを整理し、Application/Infrastructure/AZ/Regionの4中断タイプ別にRTO/RPO目標を定義するResiliency Policyの設計方法を扱いました。

§3 Resilience Hubアセスメントパイプライン

アプリケーションをCloudFormationスタック・タグ・Resource Groupから登録し、アセスメントを実行してAppComponent単位の推定RTO/RPOと目標充足状況を確認するパイプラインを解説しました。推奨事項（SOP・アラーム・FIS実験）をCI/CDに統合することで、変更のたびに回復性を自動評価できる継続的な仕組みが完成します。

§4 FIS連携とゲームデーによる回復性検証

Resilience HubのFIS推奨機能から生成されるアプリ固有の実験シナリオを使い、推定RTO/RPOが実際の障害でも達成できるかをゲームデーとCI/CD統合で継続検証する方法を扱いました。

§5 クロスリージョンDRと復旧制御

AWS BackupのクロスリージョンコピーとVault Lock、Application Recovery Controller（ARC）のRouting ControlとZonal Shiftを構成部品として組み合わせ、Regionレイヤーのフェイルオーバーを設計する方法を整理しました。

§6 回復性ドリフト検知と継続的統制

構成変更によるRTO/RPO逸脱をSNS・EventBridgeで即時検知し、自動再アセスメントをトリガーする継続的統制の運用ループを解説しました。ドリフト検知が機能することで「測定→改善→測定」のサイクルが閉じます。

実装ロードマップ

Resilience Hubを本番運用に導入する際の推奨手順を5ステップで示します。

Step 1: Resilience Hubへのアプリ登録とPolicy設定（1週目）

まず対象アプリケーションのCloudFormationスタックまたはResource GroupをResilience Hubに登録します。次にResiliency Policyを業務重要度に応じて定義（Tier1/Tier2/Tier3）し、4中断タイプ別のRTO/RPO目標を設定します。

# アプリ登録例
aws resiliencehub create-app \
  --name "payment-service" \
  --description "決済サービス（Tier1）"

# Resiliency Policy の作成例（Tier1）
aws resiliencehub create-resiliency-policy \
  --policy-name "tier1-policy" \
  --tier MissionCritical \
  --policy '{"Software":{"rtoInSecs":300,"rpoInSecs":60},"Hardware":{"rtoInSecs":300,"rpoInSecs":60},"AZ":{"rtoInSecs":900,"rpoInSecs":300},"Region":{"rtoInSecs":3600,"rpoInSecs":900}}'

Step 2: 初回アセスメントで現状把握（登録翌日）

初回アセスメントを実行し、現状のアーキテクチャで推定RTO/RPOを把握します。Policy breached のコンポーネントと推奨事項を一覧して改善優先度を決定します。

Step 3: FIS推奨でゲームデー実施（月1回）

Resilience HubのFIS推奨から実験シナリオを選択し、非本番環境でゲームデーを実施します。推定RTO/RPOが実際の障害対応でも達成できるかを検証し、未達のコンポーネントはRunbookを整備して再検証します。

Step 4: ドリフト検知＋CI/CD統合（1か月以内）

SNS通知とEventBridgeルールを設定してドリフト検知を有効化します。CodePipelineまたはGitHub ActionsにResilience Hub APIを組み込み、Infrastructureの変更時に自動アセスメントが走るパイプラインを構築します。

Step 5: 継続的統制の定常運用（四半期サイクル）

月次のドリフトレポートレビュー・四半期ゲームデー・半年ごとのPolicy目標見直しをカレンダーに組み込み、回復性統制を定常業務化します。年次のDR訓練だけでなく、日常的なCI/CDサイクルに回復性検証を溶け込ませることがゴールです。

新シリーズ「AWSレジリエンス/DR本番運用」Vol1の意義

本記事は、新シリーズ「AWSレジリエンス/DR本番運用」の起点となるVol1です。

従来のAWS DR関連記事は「FIS実験の手順」「Backupのクロスリージョン設定」「Aurora DRのフェイルオーバー」など個別実装を扱ってきました。本シリーズはそれらを「構成部品」として参照しつつ、Resilience Hubによる回復性の測定・統制という上位レイヤーに焦点を当てます。

「構成は組んだが、RTO/RPOを継続的に測定・保証できていない」というチームにとって、本シリーズは上流設計の解法となります。Vol2以降では、マルチアカウント環境でのResilience Hub一元管理・Organizations連携・コスト最適化DRパターンなどをテーマに展開予定です。

8-4. 関連記事（クロスリンク）

本記事の「構成部品」として参照している個別実装記事です。Resilience Hubのアセスメント推奨や検証ループで必要になった際は、あわせてご活用ください。

カオスエンジニアリング（FIS）の詳細を読む

クロスリージョンBackup/DRの詳細を読む

マルチリージョン構成の詳細を読む

Aurora DR設計の詳細を読む

Storage Vol3 — Backup Vault Lock詳細を読む