運用管理

レジリエンス評価 - AWS Resilience Hub でアプリケーションの耐障害性を定量化する

AWS Resilience Hub を使ったアプリケーションの耐障害性評価を解説。RTO/RPO の定義、レジリエンスポリシー、自動評価、改善推奨事項の活用を紹介します。

約 2 分で読めます

レジリエンス評価の必要性

アプリケーションの耐障害性 (レジリエンス) は、障害が発生した際にどれだけ早く復旧できるか (RTO: Recovery Time Objective) と、どの時点までのデータを復旧できるか (RPO: Recovery Point Objective) で定量化されます。しかし、多くの組織では RTO/RPO の目標値が曖昧であったり、現在のアーキテクチャがその目標を達成できるかの検証が行われていません。AWS Resilience Hub は、アプリケーションの耐障害性を定量的に評価し、改善推奨事項を提示するサービスです。CloudFormation スタックや Terraform State からリソース構成を自動検出し、AZ 障害・リージョン障害・アプリケーション障害の各シナリオに対する推定 RTO/RPO を算出します。定義した目標 RTO/RPO と比較して、目標を達成できるかどうかを判定します。

レジリエンスポリシーと評価の実行

Resilience Hub の利用はレジリエンスポリシーの定義から始まります。ポリシーでは、アプリケーションの RTO と RPO の目標値を障害シナリオごとに設定します。たとえば「AZ 障害: RTO 1 時間、RPO 5 分」「リージョン障害: RTO 4 時間、RPO 1 時間」「アプリケーション障害: RTO 30 分、RPO 5 分」のように定義します。次にアプリケーションを登録します。CloudFormation スタック名を指定すると、スタック内のリソース (EC2、RDS、DynamoDB、Lambda、S3 など) が自動的に検出され、リソース間の依存関係がマッピングされます。評価を実行すると、各リソースの現在の設定 (マルチ AZ 構成、バックアップ設定、レプリケーション設定など) を分析し、各障害シナリオに対する推定 RTO/RPO を算出します。目標を達成できないリソースがあれば、具体的な改善推奨事項が提示されます。

改善推奨事項と FIS 統合

評価結果の改善推奨事項は、リソースごとに具体的なアクションとして提示されます。たとえば、シングル AZ の RDS インスタンスに対しては「マルチ AZ 配置に変更」、バックアップが未設定の DynamoDB テーブルに対しては「ポイントインタイムリカバリ (PITR) の有効化」、 Auto Scaling が未設定の EC2 に対しては「 Auto Scaling グループの作成」が推奨されます。各推奨事項には、実施した場合の推定 RTO/RPO の改善値も含まれるため、優先度の判断に役立ちます。 FIS (Fault Injection Simulator) との統合により、 Resilience Hub が推奨するテストシナリオ (AZ 障害のシミュレーション、 RDS フェイルオーバーなど) を FIS の実験テンプレートとして自動生成し、実際に障害を注入して耐障害性を検証できます。評価 → 改善 → テスト → 再評価のサイクルを回すことで、アプリケーションのレジリエンスを継続的に向上させられます。 災害復旧 クラウドの基礎から応用まで、書籍 (Amazon)で体系的に学べます。

運用と継続的な評価

Resilience Hub は一度きりの評価ではなく、継続的なレジリエンス管理を支援します。アプリケーションのリソース構成が変更された場合 (CloudFormation スタックの更新)、ドリフト検出で変更を検知し、再評価を促します。評価は手動実行に加え、CI/CD パイプラインに組み込んでデプロイ時に自動実行することも可能です。Organizations 統合により、組織内の複数アカウントのアプリケーションを一元的に管理できます。料金はアプリケーション 1 つあたり月額 15 USD の定額制で、評価回数に制限はありません。Well-Architected Framework の信頼性の柱のレビューを自動化するツールとして位置づけられ、Well-Architected Tool との統合も提供されています。

Resilience Hub の料金

Resilience Hub の料金はアプリケーションの評価回数で課金されます。1 アプリケーションの評価あたり約 0.10 ドルで、月間の評価回数に応じたコストです。アプリケーションの定義と RTO/RPO ポリシーの設定に追加料金は発生しません。定期的な評価 (月次や四半期) をスケジュール設定し、アーキテクチャ変更後に再評価を実行する運用パターンが推奨されます。評価結果に基づく改善推奨の実装コスト (Multi-AZ 化、バックアップ設定等) は別途必要です。

まとめ - Resilience Hub の活用指針

AWS Resilience Hub は、アプリケーションの耐障害性を RTO/RPO で定量的に評価し、改善推奨事項を提示するサービスです。CloudFormation からのリソース自動検出、3 つの障害シナリオに対する評価、FIS との統合によるテスト実行が主な強みです。本番環境のミッションクリティカルなアプリケーションに対して、まず RTO/RPO の目標を定義し、Resilience Hub で現状を評価することから始めることを推奨します。月額 15 USD/アプリケーションと低コストで、障害発生時の影響を事前に把握できる価値は大きいです。

関連するサービス

AWS Resilience Hubアプリケーションの耐障害性を評価し、復旧目標の達成状況を可視化するサービスAWS Fault Injection SimulatorAWS 環境に意図的に障害を注入してシステムの耐障害性を検証するサービスAWS CloudFormationテンプレートで AWS リソースをコードとして定義・プロビジョニングする IaC サービス

関連する記事

カオスエンジニアリング実践 - AWS Fault Injection Simulator で耐障害性を検証するAWS Fault Injection Simulator (FIS) を使ったカオスエンジニアリングの実践を解説。障害注入シナリオの設計、EC2 ・ ECS ・ RDS への障害注入、安全な実験の進め方を紹介します。アーキテクチャレビュー - AWS Well-Architected Tool でワークロードを体系的に評価するAWS Well-Architected Tool を使ったワークロードのアーキテクチャレビューを解説。6 つの柱に基づく評価、改善計画の策定、カスタムレンズの活用を紹介します。AWS Resilience Hub でアプリケーションの耐障害性を評価 - RTO/RPO 目標の達成状況を可視化Resilience Hub によるアプリケーションの耐障害性評価、RTO/RPO ポリシーの設定、改善推奨事項の活用を解説します。

同じテーマの記事

AWS の内部時刻同期の仕組み - Amazon Time Sync Service とうるう秒スミアリングの設計AWS が独自に運用する Amazon Time Sync Service の仕組み、GPS と原子時計による高精度時刻源、うるう秒をスミアリングで吸収する設計判断、分散システムにおける時刻同期の重要性を解説します。AWS AppFabric で SaaS 監査ログを集約 - OCSF 標準化と Security Lake 統合AppFabric による SaaS アプリケーションの監査ログ収集、OCSF 形式への標準化、分析パイプラインの構築を解説します。AWS AppConfig で実装するフィーチャーフラグ - 安全な設定デプロイとロールバックコードデプロイとは独立した設定変更を、Linear・Exponential 戦略で段階的にロールアウトする。CloudWatch アラーム連動の自動ロールバックで安全性を確保します。アーキテクチャレビュー - AWS Well-Architected Tool でワークロードを体系的に評価するAWS Well-Architected Tool を使ったワークロードのアーキテクチャレビューを解説。6 つの柱に基づく評価、改善計画の策定、カスタムレンズの活用を紹介します。監査ログの設計と運用 - CloudTrail による API アクティビティの完全記録AWS CloudTrail を活用した監査ログの設計手法を解説し、API アクティビティの記録、S3 への長期保存、Config との連携によるコンプライアンス対応を紹介します。AWS の障害報告書 (COE) から学ぶ分散システムの教訓 - 過去の大規模障害が変えた設計原則AWS が公開した Correction of Errors (COE) と障害報告書から、S3 障害、us-east-1 の DNS 障害、Kinesis 障害など過去の大規模インシデントの根本原因と、それが AWS の設計原則をどう変えたかを解説します。タグの設計が運用を決める - AWS リソースタグ戦略の雑学と実践的な命名規則AWS リソースタグが単なるラベルではなくコスト配分、アクセス制御、自動化の基盤である理由、タグキーの命名規則、タグの上限 50 個の使い方、タグポリシーによるガバナンスを解説します。AWS のサービスクォータはなぜ存在するのか - 共有インフラを守るマルチテナント設計AWS のサービスクォータ (旧サービス制限) が単なる制約ではなく、マルチテナント環境で他の顧客を守るための設計であることを、ノイジーネイバー問題、ソフトリミットとハードリミットの違い、引き上げ申請の裏側から解説します。

内容が近い記事・サービス

AWS Resilience Hub でアプリケーションの耐障害性を評価 - RTO/RPO 目標の達成状況を可視化Resilience Hub によるアプリケーションの耐障害性評価、RTO/RPO ポリシーの設定、改善推奨事項の活用を解説します。AWS Resilience Hubアプリケーションの耐障害性を定量的に評価し、RTO/RPO 目標に対する準拠状況の可視化と改善推奨を提供するレジリエンス管理サービスAWS の DR 戦略の選択肢 - Pilot Light から Multi-Site まで段階的に設計する災害復旧Pilot Light、Warm Standby、Multi-Site Active/Active の各 DR 戦略と Elastic Disaster Recovery を中心に、AWS が提供する災害復旧の選択肢の幅広さと柔軟性を解説します。