c1.16 ワークロードのレジリエンスを評価する
セキュリティは可用性(CIA の A)に責任を持ちます。重要なワークロードがビジネスの復旧目標を満たせるかを測定し、見つかったギャップを埋めます。AWS Resilience Hub は、これを評価・追跡するためのマネージドな方法です。
実装ガイダンス
可用性はセキュリティの責任
レジリエンスは日々の運用ではインフラチームが担うことが多いですが、その成果に責任を持つのはセキュリティです。重要なワークロードが、ビジネスが期待する水準で障害に耐えられるようにすること — CIA トライアドの可用性です。大規模障害の後、取締役会は通常、リスクを適時に表面化しなかったとして CISO に説明責任を求めます。
Resilience Hub でギャップを測る
AWS Resilience Hub は、重要なアプリケーションが RTO(目標復旧時間)と RPO(目標復旧時点)の目標を満たせるかを評価するため、現在のレジリエンスをビジネスが求める SLA と比較できます。ギャップがある場合は、それを埋めるために必要なアーキテクチャ変更(例:追加のアベイラビリティーゾーンやリージョン、レプリカ)のコストを見積もり、ビジネスが「改善に投資する」か「リスクを受容して要件を調整する」かを判断するためのデータを提供します。その後 AWS は、生成 AI 支援による SRE レジリエンスジャーニーを備えた次世代の Resilience Hubを導入しました。従来の Resilience Hub も引き続き利用できます。
認識ではなく意思決定にする
主要な価値は、「私たちは十分にレジリエントか?」をデータに基づく答えに変えることです。マルチ AZ かマルチリージョンか、いつレプリカを追加するか — これらは想定ではなく、文書化された要件に従うべきです。より深いフェーズは災害復旧を参照してください。
How to validate
- 重要なワークロードを Resilience Hub で評価しましたか?
- ビジネスから明確な可用性要件(RTO/RPO、SLA)がありますか?
- 各重要ワークロードは実際に必要な SLA を提供できますか。ギャップに対する修復計画はありますか?
Threats addressed
- システムは時間とともに故障します。何をマルチ AZ で、何をマルチリージョンで実行するか、いつレプリカを追加するかは、認識ではなく測定された要件(RTO/RPO)で決めるべきです。さもないと重要なワークロードが障害を生き延びられない可能性があります。
- 重要なアプリケーションの大規模障害では、別のチームが日々のレジリエンスを担っていても、リーダーシップはレジリエンスのリスクを適時に特定し改善を推進しなかったとして CISO に説明責任を求めることが多いです。
AWS サービス
AWS Resilience Hub 料金
AWS 無料利用枠の一環として、最初の 3 アプリケーションについて AWS Resilience Hub を 6 か月間無料で試せます。Resilience Hub の料金を参照してください。