AWS認定資格 WEB問題集＆徹底解説セキュリティ専門知識（SCS）

会員登録/ログイン

1. サービス概要

AWS Resilience Hubは、AWS 上のアプリケーションの回復性（障害から決められた時間内に復旧し、データ損失を許容範囲に抑える能力）を、目標の定義 → 評価 → 改善 → テストのサイクルで継続的に管理するサービスです。 復旧時間目標（RTO）と復旧時点目標（RPO）をポリシーとして定め、アプリケーションを構成するリソースの設定から「障害時に目標を達成できる見込みか」を評価します。

評価はリソースの構成情報を基に行い、障害を注入しません。そのうえで構成の改善案に加え、障害を検知するアラーム、復旧手順（SOP）、AWS FIS による障害注入テストといった運用面の推奨も提示します。評価の考え方は AWS Well-Architected フレームワークの信頼性の柱に基づいています。 DOP-C02 では回復性の高いソリューションの管理、SCS-C03 ではインシデント対応計画の有効性の検証（タスク 2.1）で扱われます。 なお 2026年には、生成 AI による障害モード評価や「システム / ユーザージャーニー / サービス」の階層を導入した次世代版も提供されていますが、本ページは試験で前提となるアプリケーション単位のモデルを中心に解説します。

2. 主な特徴と機能

2.1 アプリケーションの定義と入力ソース

評価対象を「アプリケーション」として登録します。リソースは CloudFormation スタック、Terraform のステートファイル（S3 に保存したもの）、AWS Resource Groups、AppRegistry のアプリケーション、Amazon EKS クラスターなどから取り込めます。 取り込んだリソースは、一緒に動き一緒に障害を起こす単位であるアプリケーションコンポーネント（AppComponent。例: プライマリ DB とレプリカ）にまとめられます。

2.2 レジリエンスポリシー

ポリシーには、障害の種類ごとに RTO / RPO を設定します。種類はアプリケーション（デプロイ不良や設定ミスなどソフトウェア側の障害）、クラウドインフラストラクチャ、アベイラビリティーゾーン（AZ）、リージョンの 4 つです。 業務の重要度に応じた推奨ポリシー（ミッションクリティカルなど）も用意されています。

2.3 レジリエンス評価とスコア

評価では、アプリケーションが達成できる見込みの RTO / RPO（推定ワークロード RTO / RPO）を算出し、ポリシーを満たすか（Policy met / Policy breached）を判定します。未達の場合は、どの AppComponent が原因かがコンポーネント単位で示されます。 改善策はコスト重視・回復性重視など複数の選択肢で提示されます。レジリエンススコアは、ポリシーへの適合に加えて、推奨したアラーム・SOP・テストの実装状況も反映した総合指標です。

2.4 運用面の推奨（アラーム・SOP・FIS テスト）

評価結果から、障害を検知する CloudWatch アラーム、Systems Manager Automation ドキュメントとして実装された SOP、AWS FIS の実験を推奨します。 必要なものを選ぶと CloudFormation テンプレートとして出力でき、アプリのコードベースで IaC として管理・デプロイできます。既定の SOP を複製して自社用に拡張することも可能です。

2.5 定期評価とドリフト検出

毎日の自動評価を有効にでき、前回はポリシーを満たしていたコンポーネントが満たさなくなった（ポリシードリフト）場合や、入力ソース内のリソースが増減した（リソースドリフト）場合に検出します。ドリフトの通知先には SNS トピックを指定できます。

2.6 CI/CD への組み込み

評価の開始と結果取得は API で行えるため、デプロイパイプラインに評価ステージを置き、ポリシー違反ならリリースを止める運用ができます。

3. アーキテクチャおよび技術要素

1. アプリケーションを作成し、CloudFormation スタックなどの入力ソースからリソースを取り込む。
2. 取り込まれたリソースと AppComponent の分類を確認し、必要なら修正してアプリケーションのバージョンを公開する。
3. 障害の種類ごとの RTO / RPO を定めたレジリエンスポリシーをアタッチする。
4. レジリエンス評価を実行し、推定 RTO / RPO、ポリシー違反のコンポーネント、改善策、運用面の推奨を確認する。
5. 構成を改善し、推奨されたアラーム・SOP・FIS 実験を CloudFormation でデプロイする。
6. FIS 実験で検知と SOP が機能することを確かめ、毎日の自動評価とドリフト通知で状態を維持する。

Resilience Hub 自体はフェイルオーバーやレプリケーションを行いません。実際の復旧は AWS Backup、AWS Elastic Disaster Recovery、Amazon Application Recovery Controller、各サービスのマルチ AZ / クロスリージョン機能が担い、Resilience Hub はそれらが目標を満たす構成になっているかを評価します。

4. セキュリティと認証・認可

• アクセス用ロール: Resilience Hub はリソースの構成を読み取るために IAM ロール（呼び出し元ロール）または現在の IAM ユーザーの権限を使う。読み取り中心の権限で評価でき、リソースを変更しない。
• クロスアカウント: 他アカウントのリソースを含めるには、各アカウントに Resilience Hub が引き受けるロールを用意する。
• 通知の分離: ドリフト通知は別アカウント（例: セキュリティ運用アカウント）の SNS トピックへ送る構成にでき、トピックのアクセスポリシーで発行を許可する。
• 暗号化と監査: 保存データはサーバー側で暗号化され、他サービスとの通信は TLS で保護される。API 呼び出しは CloudTrail に記録される。
• インシデント対応計画: 評価・SOP・FIS テストを組み合わせ、対応計画が実際に機能することを証跡とともに示せる。

5. 料金形態

• アプリケーション単位の課金: 評価したアプリケーション 1 つにつき月額 15 USD。最初のレジリエンス評価を実行した時点から課金が始まり、アプリケーションを削除すると止まる。
• 無料トライアル: 最初に評価した 3 つのアプリケーションは 6 か月間無料。
• 次世代版: サービス単位の課金（月額＋評価量に応じた料金）で、依存関係評価などはオプション。
• 別途かかる費用: 推奨されたテストを実行する AWS FIS（アクション分課金）、デプロイしたアラーム、Systems Manager、CloudFormation で作成したリソースなどは各サービスの料金に従う。

6. よくあるアーキテクチャ・設計パターン

• DR 計画の妥当性確認: 経営層が承認した RTO / RPO をポリシー化し、構成から達成見込みを評価してギャップを是正してから、FIS でゲームデーを行う。
• リリースゲート: パイプラインで評価を実行し、ポリシー違反なら本番ステージへ進めない。
• 継続監視: 毎日の自動評価とドリフト通知で、レプリケーション設定の削除など気づきにくい回復性の劣化を検出する。
• 運用準備の IaC 化: 推奨されたアラーム・SOP・テストをテンプレートとして出力し、アプリのリポジトリでレビューしてデプロイする。
• ポリシーの標準化: 業務の重要度ごとにポリシーを用意し、全アプリに一貫した目標を適用する。

7. 設定・デプロイ手順（ハンズオン例）

1. Resilience Hub コンソールで「アプリケーションを追加」を選び、対象の CloudFormation スタックを入力ソースに指定する。
2. 取り込まれたリソースと AppComponent を確認し、アプリケーションを公開する。
3. レジリエンスポリシーを作成し、アプリケーション / インフラ / AZ / リージョンの各 RTO / RPO（例: AZ 障害は RTO 1 時間・RPO 15 分）を設定してアタッチする。
4. 評価を実行し、推定 RTO / RPO と違反コンポーネント、改善策を確認する。
5. 運用面の推奨からアラーム・SOP・FIS 実験を選んで CloudFormation テンプレートを生成し、スタックとしてデプロイする。
6. 毎日の自動評価を有効にし、ドリフト通知先の SNS トピックを設定する。

8. 試験で問われやすいポイント