目次

AWS Resilience Hub 完全ガイド v2.0

アプリケーション回復力評価・RTO/RPO達成可能性・Drift検出・自動改善推奨

ドキュメントメタデータ

  • 最終更新: 2026-04-26
  • バージョン: v2.0
  • 対象者: エンタープライズアーキテクト、SRE・DevOps責任者、DR計画者、コンプライアンス担当
  • 難易度: 上級
  • 関連サービス: AWS FIS（Fault Injection Service）、Elastic Disaster Recovery、Backup、CloudFormation、Application Composer
  • 推奨: 金融機関・医療・ミッションクリティカルなサービス向け

概要と課題

本質

AWS Resilience Hub は 「アプリケーションの回復力（RTO/RPO）目標を定義し、実装との乖離をAIが自動分析・改善推奨を提示するサービス」 である。CloudFormation・Terraform・App Registry で定義したアプリケーション構成を分析して、ソフトウェア障害・インフラ障害・AZ 障害・リージョン障害シナリオでの推定 RTO・RPO を算出。Well-Architected の信頼性ピラーに基づいた具体的なアーキテクチャ改善提案と FIS 実験テンプレート提供により、DR 計画を実装可能にする。

このサービスを選ぶ理由

なぜ AWS Resilience Hub なのか？

  1. RTO/RPO ギャップの自動検出

    • 手動での回復力評価は複雑・時間がかかる
    • Resilience Hub が IaC を読み込み、自動的に障害シナリオをシミュレート
    • 「RTO 1 時間目標に対して Lambda の再試行設定不足」のようなギャップを自動特定

  2. CI/CD への統合でドリフト検出

    • コード変更のたびに回復力評価を実行
    • 「今回の変更で RTO が 30 分 → 60 分に悪化」を CI/CD パイプラインで検出
    • 本番デプロイ前に回復力の後退をブロック可能

  3. FIS 実験テンプレートの自動生成

    • Resilience Hub が「このアプリケーションには AZ 障害テストが必要」と認識
    • AWS FIS で実行可能な実験テンプレートを自動生成
    • 理論的評価と実践的検証の両立

  4. Well-Architected Framework との統合

    • 信頼性ピラーのベストプラクティス（単一障害点排除・バックアップ・フェイルオーバー）に基づく
    • Well-Architected レビューの準備を効率化

  5. Elastic Disaster Recovery との連携

    • EDR でのレプリケーション・フェイルオーバー能力を Resilience Hub の評価に組み込み
    • DR 計画が実際の RTO 目標を満たせるか継続確認

  6. 複数アプリケーションの優先順位付け

    • 回復力スコア（0～100）で複数アプリの比較
    • リスク高いシステムを優先的に改善

アーキテクチャと設計原則

全体構成図（Mermaid 1）

graph TB
    subgraph IaCLayer["IaC定義層"]
        CFN["CloudFormation<br/>Stack"]
        Terraform["Terraform State"]
        AppRegistry["App Registry<br/>Component"]
    end
    
    subgraph AnalysisLayer["分析層"]
        Import["Import Resources<br/>（自動検出）"]
        Architecture["Architecture Analysis<br/>（依存関係・構成）"]
        ML["ML-Based Analysis<br/>（障害シナリオ評価）"]
    end
    
    subgraph PolicyLayer["ポリシー層"]
        RTO["RTO目標<br/>（Recovery Time）"]
        RPO["RPO目標<br/>（Recovery Point）"]
        Tier["Tier（重要度）"]
    end
    
    subgraph SimulationLayer["シミュレーション層"]
        SoftwareFault["Software Failure<br/>Simulation"]
        InfraFault["Infrastructure Failure<br/>Simulation"]
        AZFault["AZ Failure<br/>Simulation"]
        RegionFault["Region Failure<br/>Simulation"]
    end
    
    subgraph OutputLayer["出力層"]
        ResilienceScore["Resilience Score<br/>（0～100）"]
        Recommendations["Recommendations<br/>（改善提案）"]
        FISTemplate["FIS Experiment<br/>Template"]
    end
    
    CFN --> Import
    Terraform --> Import
    AppRegistry --> Import
    
    Import --> Architecture
    Architecture --> ML
    
    RTO --> SimulationLayer
    RPO --> SimulationLayer
    Tier --> SimulationLayer
    
    ML --> SoftwareFault
    ML --> InfraFault
    ML --> AZFault
    ML --> RegionFault
    
    SoftwareFault --> ResilienceScore
    InfraFault --> ResilienceScore
    AZFault --> ResilienceScore
    RegionFault --> ResilienceScore
    
    ResilienceScore --> Recommendations
    Recommendations --> FISTemplate

評価フロー（Mermaid 2）

sequenceDiagram
    participant User as User/CI/CD
    participant Hub as Resilience Hub
    participant Analysis as ML Analysis
    participant FIS as AWS FIS
    
    User->>Hub: Import Application<br/>(CloudFormation/Terraform)
    Hub->>Hub: Detect Resources
    
    User->>Hub: Define Resiliency Policy<br/>(RTO/RPO/Tier)
    
    User->>Hub: Start Assessment
    Hub->>Analysis: Analyze Architecture
    
    Analysis->>Analysis: Simulate Software Fault
    Analysis->>Analysis: Simulate Infrastructure Fault
    Analysis->>Analysis: Simulate AZ Fault
    Analysis->>Analysis: Simulate Region Fault
    
    Analysis->>Hub: Generate Score & Recommendations
    Hub->>User: Display Resiliency Score
    Hub->>User: Display Recommendations
    Hub->>FIS: Generate Experiment Template
    
    User->>FIS: Execute Experiment<br/>(Optional)
    FIS-->>User: Test Results

コアコンポーネント

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

Resilience Hub での管理単位

属性:
  - Name・Description
  - Owner・Tags
  - Resiliency Policy ARN
  - Assessment History

リソース検出ソース:
  1. CloudFormation Stack
     → スタック内のリソース自動検出
     → EC2・RDS・Lambda・ELB・SQS 等
  
  2. Terraform State
     → Terraform State File から IaC 抽出
     → 既存の Terraform 管理リソース活用
  
  3. Application Registry
     → myApplications で統一管理
     → 複数スタック・複数リージョン統合

2. Resiliency Policy（回復力ポリシー）

RTO・RPO 目標を定義

構成要素:
  1. Software Failure（ソフトウェア障害）
     例: CodeDeploy デプロイエラー・アプリケーションクラッシュ
     - RTO: 60 分（目標復旧時間）
     - RPO: 1 時間（目標復旧時点）
  
  2. Infrastructure Failure（インフラ障害）
     例: EC2 インスタンス障害・RDS ノード障害
     - RTO: 30 分
     - RPO: 15 分
  
  3. AZ Failure（アベイラビリティゾーン障害）
     例: 単一 AZ の全停止
     - RTO: 120 分
     - RPO: 1 時間
  
  4. Region Failure（リージョン障害）
     例: リージョン全体の停止
     - RTO: 360 分（6 時間）
     - RPO: 4 時間

Tier（重要度）:
  - Mission Critical
    RTO: 1-15 分、RPO: 1-5 分（金融・医療）
  
  - Important
    RTO: 15-60 分、RPO: 5-60 分（e-commerce・SaaS）
  
  - Core Services
    RTO: 60-480 分、RPO: 1-24 時間（通常の業務アプリ）
  
  - Non-Critical
    RTO: > 24 時間、RPO: > 24 時間（非本番・試験環境）

3. Assessment（評価）

アプリケーションの回復力を評価

実行内容:
  1. Architecture Analysis
     - リソース依存関係の解析
     - Single Point of Failure（SPOF）検出
     - スケーリング設定確認
  
  2. Failure Scenario Simulation
     各障害シナリオでの推定 RTO・RPO 算出
     
  3. Score Calculation
     定義した RTO/RPO 目標との乖離を計算
     → Resiliency Score（0～100）

Assessment Duration:
  - 実施時間: 30～60 分
  - 出力: Recommendations・Risk Assessment

4. Recommendation（推奨事項）

アーキテクチャ改善の提案

推奨カテゴリ:

1. Redundancy（冗長性）
   「RDS を Single-AZ → Multi-AZ に変更」
   期待効果: RTO 60分 → 15分
   推定コスト増加: +$200/月

2. Fault Tolerance（耐障害性）
   「ALB のクロスゾーン負荷分散を有効化」
   期待効果: AZ 障害時の サービス継続性向上

3. Automated Recovery（自動復旧）
   「Lambda の同時実行数を予約」
   期待効果: Cold Start による RTO悪化を回避

4. Data Protection（データ保護）
   「AWS Backup スケジュール設定」
   期待効果: RPO 24時間 → 1時間

5. Capacity Planning（容量計画）
   「Auto Scaling Group の最小・最大キャパシティ見直し」
   期待効果: スケール遅延によるサービス低下を回避

5. Resiliency Score（回復力スコア）

アプリケーションの回復力を数値化（0～100）

計算方法:
  - 各障害シナリオで「目標達成度」を評価
  - 達成度の平均 = Resiliency Score
  
解釈:
  90-100: Excellent
          ほぼすべての障害シナリオで RTO/RPO 目標達成
  
  75-89:  Good
          一部の障害シナリオで改善の余地あり
  
  50-74:  Moderate
          複数の障害シナリオで RTO/RPO 目標未達成
  
  < 50:   Poor
          ほぼすべてのシナリオで改善必要

改善戦略:
  - Score < 50 → 迅速な改善計画策定
  - Score 50-75 → 段階的な強化
  - Score 75-90 → 定期的なレビュー
  - Score > 90 → 維持・継続モニタリング

6. Drift Detection（ドリフト検出）

定義したアーキテクチャと実装の乖離を検出

検出シナリオ:

1. Code Change → Resiliency Score 悪化
   例: CloudFormation で RDS の Multi-AZ 設定を削除
   → Assessment で自動検出 → アラート発火

2. Manual Change → Drift 検出
   例: コンソールで EC2 Auto Scaling Group 設定変更
   → 定期的なスキャンで検出 → 推奨修正

3. CloudFormation Stack Update → 自動再評価
   新しい Drift が生じていないか確認
   → CI/CD パイプラインで検証

主要ユースケース

1. SaaS プロバイダの回復力評価

シナリオ: マルチテナント SaaS・99.99% 可用性契約

定義:
  - RTO: 15 分（目標）
  - RPO: 5 分（目標）
  - Tier: Mission Critical

アプリケーション構成:
  - ALB（マルチ AZ）
  - ECS Fargate（3 AZ・Auto Scaling）
  - RDS Aurora（Multi-AZ）
  - DynamoDB（グローバルテーブル）

Assessment 結果:
  AZ Failure Scenario:
    - 推定 RTO: 2 分（目標 15 分 ✅）
    - 推定 RPO: 0 分（目標 5 分 ✅）
  
  Region Failure Scenario:
    - 推定 RTO: 45 分（目標 15 分 ❌）
    - 推定 RPO: 10 分（目標 5 分 ❌）
    → グローバルテーブル設定不足を推奨

Resiliency Score: 78（改善余地あり）

2. 金融機関のコンプライアンス対応

シナリオ: 銀行・規制要件「RTO 4時間・RPO 1時間」

定義:
  - RTO: 4 時間
  - RPO: 1 時間
  - Tier: Mission Critical

アプリケーション:
  - Mainframe ↔ AWS Lambda（統合）
  - RDS Oracle（Multi-AZ）
  - AWS Backup（日次）

Assessment 前の課題:
  - Backup が日次（RPO 24時間）→ ❌ 要件未達
  - Disaster Recovery 計画が文書のみ
  - RTO の実測値不明

改善推奨:
  1. AWS Backup を 1 時間ごとに変更
  2. Elastic Disaster Recovery（EDR）の導入
  3. FIS での定期的な DR テスト

Resiliency Score: 45 → 82（改善後）

3. e-commerce プラットフォーム の Black Friday 対応

シナリオ: Black Friday 期間の無停止・スケール対応

要件:
  - 可用性: 99.95%
  - RTO: 30 分
  - RPO: 1 時間
  - 期間中のトラフィック 10 倍

Resilience Hub 分析:
  課題検出:
    1. Auto Scaling グループの最大キャパシティ不足
       → 10 倍スケール時にスケール遅延（RTO 悪化）
    
    2. RDS Connections 枯渇のリスク
       → コネクションプール設定不足
    
    3. ElastiCache（Session）が単一 AZ
       → キャッシュ障害時にセッション喪失

推奨:
  1. Auto Scaling Max Instance を事前に引き上げ
  2. RDS Provisioned IOPS・Connection Pool 増加
  3. ElastiCache を Multi-AZ に変更

Resiliency Score: 72（改善対応可能）

4. データベース移行の回復力検証

シナリオ: オンプレ Oracle → AWS RDS Aurora への移行

検証項目:
  - 移行中の RTO・RPO 維持
  - Failover の自動化可否
  - Rollback プロセスの確立

Resilience Hub での検証:
  1. 移行前: オンプレ Oracle のクリティカルパス分析
  2. 移行後: RDS Aurora のレプリケーション設定確認
  3. Assessment: Failover シナリオ自動テスト
  
  結果:
    - Multi-AZ 自動フェイルオーバー: 2 分
    - Backup & Point-in-time Restore: 15 分

Resiliency Score: 85（可能・本運用へ）

5. CI/CD パイプラインへの組み込み

シナリオ: 毎日のビルド・デプロイ時に回復力をチェック

パイプライン統合:
  1. Code Build
  2. CloudFormation Change Set 生成
  3. **Resilience Hub Assessment**（新規）
  4. Compliance Check
  5. Approval & Deploy

検証ロジック:
  ```bash
  # buildspec.yml
  - ASSESSMENT_ARN=$(aws resiliencehub start-app-assessment ...)
  - STATUS=$(aws resiliencehub describe-app-assessment --assessment-arn $ASSESSMENT_ARN --query 'assessment.assessmentStatus')
  - while [ $STATUS = "InProgress" ]; do sleep 30; done
  
  - SCORE=$(aws resiliencehub describe-app-assessment --assessment-arn $ASSESSMENT_ARN --query 'assessment.resiliencyScore.resiliencyScore')
  - if [ $SCORE -lt 70 ]; then exit 1; fi  # Fail if score too low
  
  # Deploy only if Resilience Score >= 70

効果:

  • 自動的に回復力悪化を検出・ブロック
  • 品質の継続的向上

### 6. AWS FIS との統合テスト

```text
シナリオ: Resilience Hub の理論値を FIS で実証

プロセス:
  1. Resilience Hub で Assessment 実行
     → 推定 RTO: AZ障害時 5分
  
  2. FIS Experiment Template を自動生成
     → AZ 障害シミュレーション
  
  3. FIS で実験実行
     → 実測：AZ 障害時 RTO 6分（推定値と一致）
  
  4. フィードバック
     理論値と実測値のギャップを分析
     → アーキテクチャ最適化

7. マルチリージョン アーキテクチャの検証

シナリオ: Primary (us-east-1) ↔ Secondary (eu-west-1)
         アクティブ-アクティブ構成

評価対象:
  - リージョン障害時の自動フェイルオーバー
  - DR RTO・RPO 目標達成可否
  - Cross-Region Replication の遅延

Assessment:
  Region Failure Scenario:
    推定 RTO: 5 分（Route 53 フェイルオーバー）
    推定 RPO: 1 秒（リアルタイムレプリケーション）

Resiliency Score: 92（優秀・本番対応可）

設定・操作の具体例

CLI 操作（AWS CLI）

1. アプリケーション作成（CloudFormation Stack）

# アプリケーション作成
aws resiliencehub create-app \
  --name ecommerce-platform \
  --description "E-commerce platform for Black Friday" \
  --tags "Environment=production,Team=platform"

# 結果: App ARN
# arn:aws:resiliencehub:ap-northeast-1:123456789012:app/ecommerce-platform

2. CloudFormation Stack のリソース検出

# Application に CloudFormation Stack を追加
aws resiliencehub import-resources-to-draft-app-version \
  --app-arn arn:aws:resiliencehub:ap-northeast-1:123456789012:app/ecommerce-platform \
  --source-arns 'arn:aws:cloudformation:ap-northeast-1:123456789012:stack/ecommerce-stack/xxx'

# リソース検出・Import が自動実行

3. Resiliency Policy（回復力ポリシー）の作成

aws resiliencehub create-resiliency-policy \
  --policy-name standard-policy \
  --policy '{
    "Software": {
      "rtoInSecs": 3600,
      "rpoInSecs": 3600
    },
    "AZ": {
      "rtoInSecs": 7200,
      "rpoInSecs": 3600
    },
    "Infrastructure": {
      "rtoInSecs": 3600,
      "rpoInSecs": 3600
    },
    "Region": {
      "rtoInSecs": 21600,
      "rpoInSecs": 14400
    }
  }' \
  --tier BusinessCritical \
  --tags "Team=platform"

# 結果: Policy ARN

4. Policy をアプリケーションに適用

aws resiliencehub update-app \
  --app-arn arn:aws:resiliencehub:ap-northeast-1:123456789012:app/ecommerce-platform \
  --policy-arn arn:aws:resiliencehub:ap-northeast-1:123456789012:resiliency-policy/standard-policy

5. Assessment 実行

# Assessment 開始
ASSESSMENT=$(aws resiliencehub start-app-assessment \
  --app-arn arn:aws:resiliencehub:ap-northeast-1:123456789012:app/ecommerce-platform \
  --assessment-name "Black Friday Readiness" \
  --query 'assessment.assessmentArn' \
  --output text)

echo "Assessment ARN: $ASSESSMENT"

# Assessment 完了を待機（ポーリング）
while true; do
  STATUS=$(aws resiliencehub describe-app-assessment \
    --assessment-arn $ASSESSMENT \
    --query 'assessment.assessmentStatus' \
    --output text)
  
  if [ $STATUS = "Success" ]; then
    break
  elif [ $STATUS = "Failed" ]; then
    echo "Assessment failed"
    exit 1
  fi
  
  echo "Status: $STATUS ... waiting"
  sleep 30
done

echo "Assessment completed!"

6. Assessment 結果の確認

# Resiliency Score 確認
aws resiliencehub describe-app-assessment \
  --assessment-arn $ASSESSMENT \
  --query 'assessment.{
    Score: resiliencyScore.resiliencyScore,
    ComponentScore: resiliencyScore.componentResiliencyScores[*]
  }' \
  --output json

# 結果例:
# {
#   "Score": 78,
#   "ComponentScore": [
#     { "Component": "ALB", "Score": 95 },
#     { "Component": "ECS", "Score": 85 },
#     { "Component": "RDS", "Score": 65 }
#   ]
# }

7. 推奨事項の取得

aws resiliencehub list-recommendations \
  --assessment-arn $ASSESSMENT \
  --query 'recommendations[*].{
    Description: description,
    Severity: recommendationStatus,
    ExpectedCost: estimatedCostTierChange,
    ImpactOnScore: estimatedCostTierChange
  }' \
  --output table

8. FIS Experiment Template 生成

aws resiliencehub list-unsupported-resources \
  --app-arn arn:aws:resiliencehub:ap-northeast-1:123456789012:app/ecommerce-platform \
  --assessment-arn $ASSESSMENT \
  --query 'unsupportedResources[*].{ResourceType: resourceType, Count: count}'

# Resilience Hub が対応する FIS Template を自動生成
# 対応リソース: EC2・RDS・ECS・Lambda・ALB・CloudWatch

SDK 操作（Python）

1. Assessment 自動実行・結果取得

import boto3
import json
import time

def assess_resilience(app_arn, assessment_name):
    """
    Resilience Hub Assessment を実行
    """
    client = boto3.client('resiliencehub', region_name='ap-northeast-1')
    
    # Assessment 開始
    response = client.start_app_assessment(
        appArn=app_arn,
        assessmentName=assessment_name
    )
    
    assessment_arn = response['assessment']['assessmentArn']
    print(f"Assessment started: {assessment_arn}")
    
    # 完了待機
    while True:
        assessment = client.describe_app_assessment(
            assessmentArn=assessment_arn
        )['assessment']
        
        status = assessment['assessmentStatus']
        print(f"Status: {status}")
        
        if status == 'Success':
            break
        elif status == 'Failed':
            raise Exception("Assessment failed")
        
        time.sleep(30)
    
    # 結果取得
    score = assessment['resiliencyScore']['resiliencyScore']
    print(f"Resiliency Score: {score}")
    
    return assessment

# 使用例
app_arn = "arn:aws:resiliencehub:ap-northeast-1:123456789012:app/ecommerce-platform"
assessment = assess_resilience(app_arn, "Black Friday Readiness")

# スコア判定
if assessment['resiliencyScore']['resiliencyScore'] >= 70:
    print("✅ Ready for production")
else:
    print("❌ Needs improvement")

2. 推奨事項を JSON で出力

def get_recommendations(assessment_arn):
    """
    推奨事項を取得・JSON で保存
    """
    client = boto3.client('resiliencehub', region_name='ap-northeast-1')
    
    paginator = client.get_paginator('list_recommendations')
    
    all_recommendations = []
    for page in paginator.paginate(assessmentArn=assessment_arn):
        all_recommendations.extend(page.get('recommendations', []))
    
    # JSON で保存
    with open('recommendations.json', 'w') as f:
        json.dump(all_recommendations, f, indent=2, default=str)
    
    print(f"Saved {len(all_recommendations)} recommendations")
    return all_recommendations

recommendations = get_recommendations(assessment_arn)
for rec in recommendations[:5]:
    print(f"- {rec['description']}")

IaC 操作（CloudFormation / Terraform）

CloudFormation テンプレート

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Resilience Hub Application Setup'

Resources:
  ECommerceApp:
    Type: AWS::ResilienceHub::App
    Properties:
      Name: ecommerce-platform
      Description: E-commerce platform
      Tags:
        Environment: production
        Team: platform

  ResiliencyPolicy:
    Type: AWS::ResilienceHub::ResiliencyPolicy
    Properties:
      PolicyName: ecommerce-policy
      Tier: BusinessCritical
      DataLocationConstraint: AnyLocation
      Policy:
        Software:
          RtoInSecs: 3600
          RpoInSecs: 3600
        AZ:
          RtoInSecs: 7200
          RpoInSecs: 3600
        Infrastructure:
          RtoInSecs: 3600
          RpoInSecs: 3600
        Region:
          RtoInSecs: 21600
          RpoInSecs: 14400

  AssessmentLambda:
    Type: AWS::Lambda::Function
    Properties:
      FunctionName: resilience-assessment
      Handler: index.lambda_handler
      Role: !GetAtt LambdaRole.Arn
      Runtime: python3.11
      Code:
        ZipFile: |
          import boto3
          import json
          
          client = boto3.client('resiliencehub')
          
          def lambda_handler(event, context):
              app_arn = event['appArn']
              
              # Assessment 実行
              response = client.start_app_assessment(
                  appArn=app_arn,
                  assessmentName='automated-assessment'
              )
              
              return {
                  'statusCode': 200,
                  'body': json.dumps('Assessment started')
              }

  LambdaRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: lambda.amazonaws.com
            Action: sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
      Policies:
        - PolicyName: ResilienceHubAccess
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: Allow
                Action:
                  - resiliencehub:*
                Resource: '*'

Outputs:
  AppArn:
    Value: !GetAtt ECommerceApp.AppArn
    Description: Resilience Hub App ARN
  PolicyArn:
    Value: !GetAtt ResiliencyPolicy.PolicyArn
    Description: Resiliency Policy ARN

Terraform コード

resource "aws_resiliencehub_app" "ecommerce" {
  name            = "ecommerce-platform"
  description     = "E-commerce platform"
  
  tags = {
    Environment = "production"
    Team        = "platform"
  }
}

resource "aws_resiliencehub_resiliency_policy" "standard" {
  name                 = "ecommerce-policy"
  tier                 = "BusinessCritical"
  data_location_constraint = "AnyLocation"
  
  policy {
    software {
      rto_in_secs = 3600
      rpo_in_secs = 3600
    }
    
    az {
      rto_in_secs = 7200
      rpo_in_secs = 3600
    }
    
    infrastructure {
      rto_in_secs = 3600
      rpo_in_secs = 3600
    }
    
    region {
      rto_in_secs = 21600
      rpo_in_secs = 14400
    }
  }
}

resource "aws_resiliencehub_app_version_resource_mapping" "cloudformation" {
  app_arn                       = aws_resiliencehub_app.ecommerce.arn
  ecs_app_component_name        = "ecommerce-service"
  physical_resource_id          = aws_ecs_service.ecommerce.name
  terraform_source_name         = "aws_ecs_service.ecommerce"
  
  depends_on = [aws_resiliencehub_app.ecommerce]
}

類似サービス比較表

観点 Resilience Hub AWS FIS Gremlin Chaos Mesh Steadybit
アーキテクチャ分析 ✅ 自動 ❌ ❌ ❌ ❌
RTO/RPO 評価 ✅ ❌ ❌ ❌ ❌
障害注入テスト FIS 連携 ✅ ✅ ✅ ✅
AWS ネイティブ ✅ ✅ ❌ ❌ ❌
マルチクラウド AWS のみ AWS のみ ✅ ✅ ✅
Kubernetes ❌ EKS ✅ ✅（専門） ✅（専門）
継続的テスト Assessment 実験 継続テスト 継続テスト 継続テスト
自動改善推奨 ✅ ❌ 限定的 ❌ ❌
Well-Architected ✅ 統合 ❌ ❌ ❌ ❌
価格モデル 評価ベース Action ベース 月額 OSS 月額
推奨用途 回復力評価・DR計画 障害注入テスト 継続的な Chaos Engineering Kubernetes 専門 オンプレ対応

ベストプラクティス

✅ 推奨事項

  1. ミッションクリティカルなシステムから開始

    • 金融・医療・e-commerce など
    • 回復力が収益直結のシステム優先

  2. RTO/RPO 目標を明確に定義

    • ビジネス要件から逆算
    • 規制要件・SLA を反映

  3. 定期的な Assessment（月 1 回以上）

    • コード変更のたびに評価
    • ドリフト検出・継続改善

  4. FIS との連携で理論値を実証

    • Assessment の推定値をテスト
    • アーキテクチャ改善のフィードバック

  5. CI/CD パイプラインへの組み込み

    • 回復力スコア閾値をチェック
    • デプロイ前にリスク検出

  6. 推奨事項の段階的実装

    • Quick Win（低コスト・高効果）から開始
    • 優先度付け・ロードマップ化

  7. Well-Architected レビューとの連携

    • 信頼性ピラーの実装確認
    • 監査・コンプライアンス対応

❌ アンチパターン

  1. Assessment を実施後、推奨を無視

    • スコアが低いまま本番稼働
    • リスク管理不足

  2. 全推奨を一括実装

    • インフラが大きく変更される
    • テスト・検証不足のリスク

  3. FIS テストなしでの改善確定

    • 理論値と実測値にギャップ
    • 想定外の障害発生リスク

  4. 定期的な Assessment なし

    • ドリフト放置
    • 新しいリスク発見遅延

  5. RTO/RPO 目標が不明確

    • 何を改善すべきか不明
    • 優先順位付け不可

トラブルシューティング表

現象 原因 対応
リソース検出されない CloudFormation Stack/Terraform 未連携・IAM 権限不足 Stack ARN 確認・IAM ReadOnlyAccess 権限付与
Assessment が失敗 対応外リソース含む・設定不完全 リソースタイプ確認・CloudFormation 検証
Resiliency Score が低い アーキテクチャに問題あり 推奨実装・FIS テストで検証
推奨事項が曖昧 カスタムリソース・未対応リソース サポート対象リソースのみ使用
FIS Template 生成失敗 対応外の構成・リソース不足 AWS FIS ドキュメント確認
Drift Detection が動作しない Assessment スケジュール未設定 手動 Assessment または定期スケジュール設定

2025-2026 最新動向

2025 年 Q2: AI-Powered Recommendation 強化

  • 生成 AI による詳細なアーキテクチャ改善提案
  • Cost-Benefit 分析の自動化

2025 年 Q3: マルチリージョン評価の強化

  • Global Application Composer での複数リージョン同時評価
  • Cross-Region Failover のシミュレーション

2026 年: Continuous Compliance

  • Resilience Score を継続的に監視
  • SLA 達成状況をダッシュボード表示
  • Compliance Report の自動生成

学習リソース・参考文献

AWS 公式ドキュメント（8+）

  1. AWS Resilience Hub User Guide
  2. Resilience Hub API Reference
  3. Getting Started with Resilience Hub
  4. Defining Resiliency Policies
  5. Application Assessment
  6. FIS Integration
  7. AWS Well-Architected Framework Reliability Pillar
  8. Elastic Disaster Recovery Integration

ベンダー・OSS リソース（5+）

  1. Gremlin - Chaos Engineering Platform
  2. Chaos Mesh - Cloud-native Chaos Engineering
  3. Steadybit - Continuous Resilience Testing
  4. Litmus Chaos - Open Source Chaos Engineering
  5. ChaosKube - Kubernetes Chaos Tool

実装例・チェックリスト

導入チェックリスト

  • [ ] ミッションクリティカルなアプリケーションの特定
  • [ ] RTO/RPO・重要度の明確化（ビジネス要件確認）
  • [ ] CloudFormation Stack・Terraform State の Resilience Hub への登録
  • [ ] Resiliency Policy の作成・アプリケーションに適用
  • [ ] 初回 Assessment の実行・スコア確認
  • [ ] 推奨事項の優先順位付け
  • [ ] Quick Win（低コスト・高効果）の実装開始
  • [ ] FIS での実験テンプレート生成・実行
  • [ ] 改善後の Assessment で効果確認
  • [ ] CI/CD パイプラインへの Assessment 組み込み
  • [ ] 月次の定期 Assessment スケジュール設定
  • [ ] Well-Architected レビューとの連携

まとめ

AWS Resilience Hub は 「アプリケーション回復力を自動評価・RTO/RPO ギャップを特定・改善推奨を提示するサービス」。CloudFormation・Terraform・Application Composer での IaC 定義を分析して、障害シナリオでの推定 RTO・RPO を算出・スコア化。AWS FIS との統合で理論値を実証でき、Well-Architected の信頼性ピラーに基づいた実装が可能。

金融機関・医療・e-commerce など、回復力が経営に直結する組織向けに強く推奨。定期的な Assessment と段階的な改善で、確実な DR 計画を実現できる。

最終更新：2026-04-26 バージョン：v2.0