翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# の使用 AWS Resilience Hub
AWS Resilience Hub は、 でのアプリケーションの耐障害性を向上させ AWS 、アプリケーションの停止時の復旧時間を短縮するのに役立ちます。
**Topics**
+ [AWS Resilience Hub 概要](view-arh-summary-ug.md)
+ [AWS Resilience Hub ダッシュボード](view-app-dashboard.md)
+ [AWS Resilience Hub アプリケーションの説明と管理](applications.md)
+ [障害耐性ポリシーの管理](resiliency-policies.md)
+ [での障害耐性評価の実行と管理 AWS Resilience Hub](resil-assessments.md)
+ [障害耐性ウィジェットからの障害耐性評価の実行と管理](resil-assessments-resiliency-widget.md)
+ [アラームの管理](alarms.md)
+ [標準運用手順の管理](sops.md)
+ [AWS Fault Injection Service 実験の管理](testing.md)
+ [障害耐性スコアの理解](resil-score.md)
+ [運用上の推奨事項を アプリケーションに統合する CloudFormation](cfn-integration.md)
# AWS Resilience Hub 概要
AWS Resilience Hub は、複数の AWS サービスやリソースにわたるアプリケーションのレジリエンス体制をat-a-glance把握できるグラフとグラフを含む視覚的な概要を提供します。この包括的で簡潔なビジュアル概要により、潜在的なレジリエンスギャップを迅速に特定し、アクションに優先順位を付け、アプリケーションの中断からの復旧能力の向上の進行状況を追跡できます。**エクスポート**を選択し、メトリクスを初めてエクスポートする場合、 はアクセス元のリージョンに新しい Amazon S3 バケット AWS Resilience Hub を作成します AWS Resilience Hub。この Amazon S3 バケットは初めて作成され、正常に完了したときにエクスポートされたメトリクスを保存するために使用されます。エクスポートしたデータを Amazon S3 に保存する場合、追加料金が適用されます。これらの料金の詳細については、[Amazon S3 の料金](https://aws.amazon.com/s3/pricing/)を参照してください。
ウィジェットのグラフとグラフは、以下を理解するのに役立ちます。
+ アプリケーションの全体的な耐障害性スコアと現在の運用状態の概要。
+ 確立されたポリシーに準拠していないアプリケーション、または推奨設定からドリフトしたアプリケーションを強調することで、ポリシー違反やベストプラクティスからの逸脱が発生する可能性があります。さらに、優先順位を付けて対処できる特定の領域についても説明します。
+ 即時対応を必要とする重要なリソースまたはアプリケーション。
+ アラームの実装、 AWS Fault Injection Service (AWS FIS) 実験の実施、標準運用手順の確立など、レジリエンスプラクティスを強化するための推奨事項。これらの推奨事項は時間の経過とともに追跡されるため、実装の進行状況をモニタリングし、アプリケーションの全体的なレジリエンス体制への影響を測定できます。
**Topics**
+ [アプリケーションのステータス](#arh-summary-app-status-ug)
+ [リソースタイプ別の上位インフラストラクチャレコメンデーション](#arh-summary-infra-top-recommendation-ug)
+ [インフラストラクチャの推奨事項](#arh-summary-infra-recommendation-ug)
+ [未実装の運用上の推奨事項](#arh-summary-ops-recommendation-ug)
+ [アラームの推奨](#arh-summary-alarms-overtime-recommendation-ug)
+ [SOP の推奨事項](#arh-summary-sop-overtime-recommendation-ug)
+ [AWS FIS 実験のレコメンデーション](#arh-summary-fis-exp-overtime-recommendation-ug)
+ [ドリフトのあるアプリケーション](#arh-summary-app-drifts-ug)
+ [障害耐性スコア](#arh-summary-res-score-overtime-recommendation-ug)
+ [障害耐性スコアの下位 10 のアプリケーション](#arh-summary-res-score-bottom-ten-app-ug)
+ [ポリシー別のアプリケーションの状態](#arh-summary-app-state-policy-ug)
## アプリケーションのステータス
このウィジェットは、アプリケーションが障害耐性ポリシーに準拠しているかどうかを示します。ポップアップで**アプリケーション数**の横にある番号を選択すると、関連するすべてのアプリケーションが**アプリケーション**ペインに表示されます。作成したすべてのアプリケーションを表示するには、**アプリケーションの表示**を選択します。でのアプリケーションの管理の詳細については AWS Resilience Hub、「」を参照してください[AWS Resilience Hub アプリケーション概要の表示](view-app-summary.md)。
## リソースタイプ別の上位インフラストラクチャレコメンデーション
このウィジェットには、障害耐性体制を改善するために最後に成功した評価で提供された AWS リソースの各リソースタイプのインフラストラクチャレコメンデーションの数が表示されます。詳細を特定するには、カーソルを合わせるか、移動します。作成したすべてのアプリケーションを表示するには、**アプリケーションの表示**を選択します。インフラストラクチャのレコメンデーションの詳細については、「」を参照してください[障害耐性に関する推奨事項の確認](resil-recs.md)。
## インフラストラクチャの推奨事項
このウィジェットには、障害耐性体制を改善するために最後に成功した評価で提供されるインフラストラクチャの推奨事項の最大数を持つアプリケーションを最大 10 個一覧表示します。作成したすべてのアプリケーションを表示するには、**アプリケーションの表示**を選択します。インフラストラクチャのレコメンデーションの詳細については、「」を参照してください[障害耐性に関する推奨事項の確認](resil-recs.md)。
詳細を特定するには、以下を使用します。
+ **アプリケーション名** – 定義時に指定したアプリケーションの名前 AWS Resilience Hub。
+ **カウント** – 最後に成功した評価 AWS Resilience Hub で から提供されたインフラストラクチャレコメンデーションの数を示します。数値を選択して、評価レポートで提供されるすべてのインフラストラクチャの推奨事項を表示します。
+ **最終評価** – アプリケーションが最後に正常に評価された日時を示します。
## 未実装の運用上の推奨事項
このウィジェットには、障害耐性体制を改善するために最後に成功した評価で提供された実装されていない運用上の推奨事項の最大数を持つアプリケーションを最大 10 個一覧表示します。作成したすべてのアプリケーションを表示するには、**アプリケーションの表示**を選択します。運用上の推奨事項の詳細については、「」を参照してください[運用上の推奨事項のレビュー](ops.reqs.md)。
詳細を特定するには、以下を使用します。
+ **アプリケーション名** – 定義時に指定したアプリケーションの名前 AWS Resilience Hub。
+ **カウント** — 最後に成功した評価 AWS Resilience Hub で から提供された運用上の推奨事項の数を示します。数値を選択すると、評価レポートに実装されていない運用上の推奨事項がすべて表示されます。
+ **最終評価時刻** – アプリケーションが最後に正常に評価された日時を示します。
## アラームの推奨
このウィジェットには、選択した期間におけるレジリエンス体制を改善するために提供されるすべての Amazon CloudWatch アラームの推奨事項が一覧表示されます。さまざまなカテゴリ (**実装済み**、**未実装**、**除外**) は、アプリケーションの実装状態を示します。各カテゴリの Amazon CloudWatch アラームレコメンデーションの数を表示するには、それらにカーソルを合わせるか、それらに移動します。作成したすべてのアプリケーションを表示するには、**アプリケーションの表示**を選択します。アラームのレコメンデーションの詳細については、「」を参照してください[運用上の推奨事項のレビュー](ops.reqs.md)。
## SOP の推奨事項
このウィジェットには、選択した期間におけるレジリエンス体制を改善するために提供される標準運用手順 (SOP) の推奨事項がすべて一覧表示されます。さまざまなカテゴリ (**実装済み**、**未実装**、**除外**) は、アプリケーションの実装状態を示します。各カテゴリの SOP レコメンデーションの数を表示するには、それらにカーソルを合わせるか、それらに移動します。作成したすべてのアプリケーションを表示するには、**アプリケーションの表示**を選択します。運用上の推奨事項の詳細については、「」を参照してください[運用上の推奨事項のレビュー](ops.reqs.md)。
## AWS FIS 実験のレコメンデーション
このウィジェットには、選択した期間におけるレジリエンス体制を改善するために提供されるすべての AWS FIS 実験の推奨事項が一覧表示されます。さまざまなカテゴリ (**実装済み**、**未実装**、**一部実装済み**、**除外**済み) は、アプリケーションの実装状態を示します。各カテゴリの AWS FIS 実験レコメンデーションの数を表示するには、それらにカーソルを合わせるか、それらに移動します。作成したすべてのアプリケーションを表示するには、**アプリケーションの表示**を選択します。 AWS FIS 実験のレコメンデーションの詳細については、「」を参照してください[標準運用手順の管理](sops.md)。
## ドリフトのあるアプリケーション
このウィジェットには、最後に成功した評価で以前の準拠状態からドリフトしたすべてのアプリケーションが一覧表示されます。作成したすべてのアプリケーションを表示するには、**アプリケーションの表示**を選択します。でのアプリケーションの管理の詳細については AWS Resilience Hub、「」を参照してください[AWS Resilience Hub アプリケーション概要の表示](view-app-summary.md)。
詳細を特定するには、以下を使用します。
+ **アプリケーション名** – 定義時に指定したアプリケーションの名前 AWS Resilience Hub。
+ **ポリシードリフト** – アプリケーション名の横にある番号を選択すると、前の評価でポリシーに準拠しているが、現在の評価では準拠していないすべてのアプリケーションコンポーネントが表示されます。
+ **リソースドリフト** – 以下の番号を選択すると、最新のインポートで設定から変更されたすべてのリソースが表示されます。
## 障害耐性スコア
このウィジェットには、最大 5 つのアプリケーションの選択した期間におけるアプリケーションの障害耐性スコアの傾向が表示されます。アプリケーションの障害耐性スコアを表示するには、アプリケーション名に関連付けられた行にカーソルを合わせるか、その行に移動し、アプリケーション名を選択してアプリケーションの概要を表示します。作成したすべてのアプリケーションを表示するには、**アプリケーションの表示**を選択します。耐障害性スコアの詳細については、「」を参照してください[障害耐性スコアの理解](resil-score.md)。
## 障害耐性スコアの下位 10 のアプリケーション
このウィジェットには、最新の評価から回復性スコアが最も低いアプリケーションを最大 10 個一覧表示し、回復性を向上させるためにすぐに注意が必要なアプリケーションが浮き彫りになります。作成したすべてのアプリケーションを表示するには、**アプリケーションの表示**を選択します。耐障害性スコアの詳細については、「」を参照してください[障害耐性スコアの理解](resil-score.md)。
詳細を特定するには、以下を使用します。
+ **アプリケーション名** – 定義時に指定したアプリケーションの名前 AWS Resilience Hub。
+ **障害耐性スコア** – 評価の実行後にアプリケーション AWS Resilience Hub に対して によって決定される全体的な障害耐性スコア。
+ **最終評価時刻** – アプリケーションが最後に正常に評価された日時を示します。
## ポリシー別のアプリケーションの状態
このウィジェットには、すべてのポリシーと、ポリシーに違反している、満たされている、またはまだ評価されていないアプリケーションの数が一覧表示されます。作成したすべてのポリシーを表示するには、**ポリシーの表示**を選択します。耐障害性スコアの詳細については、「」を参照してください[障害耐性ポリシーの管理](resiliency-policies.md)。
詳細を特定するには、以下を使用します。
+ **ポリシー名** – 定義時に指定したポリシー名を示します AWS Resilience Hub。
+ **タイプ** – アプリケーションにアタッチされたポリシーのタイプ (**障害耐性ポリシー) **を示します。
+ **ポリシー名** – 障害耐性ポリシーで定義された RTO および RPO ターゲットに違反したアプリケーションの数を示します。
+ **Apps met** – 障害耐性ポリシーに準拠しているアプリケーションの数を示します。
+ **評価されていないアプリケーション** – 障害耐性ポリシーに対してまだ評価されていないアプリケーションの数を示します。
+ **障害耐性スコア** – 評価の実行後にアプリケーション AWS Resilience Hub に対して によって決定される全体的な障害耐性スコア。
+ **最終評価時刻** – アプリケーションが最後に正常に評価された日時を示します。
# AWS Resilience Hub ダッシュボード
ダッシュボードには、アプリケーションポートフォリオの耐障害性ステータスの包括的なビューが表示されます。ダッシュボードは、CloudWatch や AWS Fault Injection Service () などのサービスからの回復力イベント (データベースが使用できない、回復力の検証に失敗したなど）、アラート、インサイトを集約して整理しますAWS FIS。
ダッシュボードは、評価される各アプリケーションの耐障害性スコアも生成します。このスコアは、推奨される耐障害性ポリシー、アラーム、復旧標準運用手順 (SOPs)、およびテストに対して評価された場合のアプリケーションのパフォーマンスを示します。このスコアを使用して、時間の経過に伴う耐障害性の向上を測定できます。
AWS Resilience Hub ダッシュボードを表示するには、ナビゲーションメニューから**ダッシュボード**を選択します。**ダッシュボード**ページには、次のセクションが表示されます。
## アプリケーションのステータス
アプリケーションのステータスは、アプリケーションがアタッチされた障害耐性ポリシーに準拠しているかどうかを示します。さらに、評価が完了すると、アプリケーションの入力ソースが変更されているかどうかもステータスに表示されます。次の各ステータスの数字を選択すると、アプリケーションページで同じステータスを共有するすべての**アプリケーション**が表示されます。
+ **ポリシー内のアプリケーション** – アタッチされた障害耐性ポリシーに準拠するすべてのアプリケーションを示します。
+ **ポリシーに違反するアプリケーション** – アタッチされた障害耐性ポリシーに準拠していないすべてのアプリケーションを示します。
+ **評価されていないアプリケーション** – コンプライアンスがまだ評価または追跡されていないすべてのアプリケーションを示します。
+ **アプリケーションのドリフト** – 障害耐性ポリシーからドリフトしたすべてのアプリケーション、またはリソースがドリフトしたかどうかを示します。
## 時間の経過に伴うアプリケーションの耐障害性スコア
時間の経過に伴うアプリケーションの障害耐性スコアを使用すると、過去 30 日間のアプリケーションの障害耐性のグラフを表示できます。ドロップダウンメニューには 10 個のアプリケーションを一覧表示できますが、 には一度に最大 4 つのアプリケーションのグラフ AWS Resilience Hub のみが表示されます。障害耐性スコアの詳細については、「」を参照してください[障害耐性スコアの理解](resil-score.md)。
**注記**
AWS Resilience Hub は、スケジュールされた評価を同時に実行しません。そのため、アプリケーションの日次評価を確認するために、時間の経過に伴う障害耐性スコアのグラフに戻る必要がある場合があります。
AWS Resilience Hub は、Amazon CloudWatch を使用してこれらのグラフも生成します。**CloudWatch でメトリクスを表示**を選択すると、アプリケーションの障害耐性に関するより詳細な情報を CloudWatch ダッシュボードに作成して表示できます。CloudWatch の詳細については、「*Amazon CloudWatch ユーザーガイド」の*「[ダッシュボードの使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)」を参照してください。
## 実装されたアラーム
このセクションでは、すべてのアプリケーションをモニタリングするために Amazon CloudWatch で設定したすべてのアラームを一覧表示します。詳細については、「[アラームを表示する](view-alarm.md)」を参照してください。
## 実施した実験
このセクションでは、すべてのアプリケーションに実装したすべてのフォールトインジェクション実験を一覧表示します。詳細については、「[AWS FIS 実験の表示](view-fis-experiment.md)」を参照してください。
# AWS Resilience Hub アプリケーションの説明と管理
AWS Resilience Hub アプリケーションは、 AWS アプリケーションの中断を防止および復旧するように構造化された AWS リソースのコレクションです。
AWS Resilience Hub アプリケーションを記述するには、アプリケーション名、1 つ以上の CloudFormation スタックのリソース、および適切な障害耐性ポリシーを指定します。既存の AWS Resilience Hub アプリケーションをテンプレートとして使用して、アプリケーションを記述することもできます。
AWS Resilience Hub アプリケーションを記述したら、障害耐性評価を実行できるように公開する必要があります。次に、評価の推奨事項を使用して、評価の実行および結果の比較によって障害耐性を向上させることができます。次に、推定ワークロードの RTO と RPO の目標を達成するまで、評価の実行および結果の比較のプロセスを繰り返します。
**アプリケーション**ページを表示するには、ナビゲーションペインから**アプリケーション**を選択します。アプリケーションページでは、次の方法で**アプリケーション**を識別できます。
+ **[名前]** – AWS Resilience Hubでの定義時に指定したアプリケーションの名前。
+ **[説明]** – AWS Resilience Hubでの定義時に指定したアプリケーションの説明。
+ **コンプライアンスステータス** – アプリケーションステータスを**評価済み**、**未評価**、**ポリシー違反**、または**検出された変更** AWS Resilience Hub に設定します。
+ **評価済み** - はアプリケーションを AWS Resilience Hub 評価しました。
+ **未評価** - AWS Resilience Hub アプリケーションを評価していません。
+ **ポリシー違反** - AWS Resilience Hub は、アプリケーションが目標復旧時間 (RTO) と目標復旧時点 (RPO) の障害耐性ポリシーの目的を満たさなかったと判断しました。アプリケーションの耐障害性を評価する AWS Resilience Hub 前に、 が提供する推奨事項を確認して使用します。推奨事項の詳細については、「[にアプリケーションを追加する AWS Resilience Hub](describe-applicationlication.md)」を参照してください。
+ **検出された変更** - アプリケーションに関連付けられた障害耐性ポリシーに加えられた変更 AWS Resilience Hub が検出されました。アプリケーションが障害耐性ポリシーの目的を満たしているかどうかを判断する AWS Resilience Hub には、 のアプリケーションを再評価する必要があります。
+ **[スケジュールされた評価]** – リソースタイプはアプリケーションのコンポーネントリソースを識別します。スケジュールされた評価についての詳細は、「[アプリケーションの障害耐性](view-app-summary.md)」を参照してください。
+ **アクティブ** - アプリケーションが AWS Resilience Hubによって 1 日ごとに自動的に評価されることを示します。
+ **無効** - これは、アプリケーションが によって毎日自動的に評価されない AWS Resilience Hub ため、アプリケーションを手動で評価する必要があることを示します。
+ **[ドリフトステータス]** - アプリケーションが前回成功した評価からドリフトしたかどうかを示し、以下のステータスのいずれかを設定します。
+ **ドリフト** - 前回の評価で障害耐性ポリシーに準拠していたアプリケーションが、現在は障害耐性ポリシーに違反しており、アプリケーションが危険にさらされていることを示します。さらに、現在のアプリケーションバージョンに含まれる入力ソース内のリソースが、追加または削除されたかどうかも示します。
+ **ドリフトなし** - ポリシーで定義されている RTO と RPO の目標をアプリケーションがまだ満たしていると推定されていることを示します。さらに、現在のアプリケーションバージョンに含まれる入力ソース内のリソースが、追加または削除されなかったことも示します。
+ **[推定ワークロード RTO]** – アプリケーションの推定最大ワークロード RTO を示します。この値は、前回成功した評価からのすべての中断タイプの最大推定ワークロード RTO です。
+ **[推定ワークロード RPO]** – アプリケーションの推定最大ワークロード RPO を示します。この値は、前回成功した評価からのすべての中断タイプの最大推定ワークロード RTO です。
+ **[最終評価時間]** – アプリケーションが最後に正常に評価された日付と時刻を示します。
+ **[作成日時]** – ジョブを作成した日付と時刻。
+ **[ARN]** - アプリケーションのAmazon リソースネーム (ARN)。ARN の詳細については、「*AWS 全般のリファレンス*」の「[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com//general/latest/gr/aws-arns-and-namespaces.html)」を参照してください。
**注記**
AWS Resilience Hub は、イメージリポジトリに Amazon ECR を使用している場合にのみ、クロスリージョン Amazon ECS リソースの耐障害性を完全に評価できます。
さらに、**[アプリケーションページ]** の以下のオプションのいずれかを使用してアプリケーションリストをフィルタリングすることもできます。
+ **[アプリケーションの検索]** – アプリケーション名を入力すると、そのアプリケーションの名前で結果がフィルタリングされます。
+ **[最終評価日時を日付と時間範囲で絞り込む]** – このフィルターを適用するには、カレンダーアイコンを選択し、以下のオプションのいずれかを選択して、時間範囲に一致する結果で絞り込みます。
+ **[相対範囲]** – 使用可能なオプションを 1 つ選択して **[適用]** を選択します。
**[カスタマイズ範囲]** オプションを選択した場合は、**[期間を入力]** ボックスに期間を入力し、**[時間単位]** ドロップダウンリストから適切な時間単位を選択して、**[適用]** を選択します。
+ **[絶対範囲]** – 日付と時刻の範囲を指定するには、開始時刻と終了時刻を指定し、**[適用]**を選択します。
以下のトピックでは、 AWS Resilience Hub アプリケーションを記述するためのさまざまなアプローチと、それらを管理する方法について説明します。
**Topics**
+ [AWS Resilience Hub アプリケーション概要の表示](view-app-summary.md)
+ [AWS Resilience Hub アプリケーションリソースの編集](application-resources.md)
+ [アプリケーションコンポーネントの管理](AppComponent.md)
+ [新しい AWS Resilience Hub アプリケーションバージョンの公開](applications-publish.md)
+ [すべての AWS Resilience Hub アプリケーションバージョンの表示](view-application-version.md)
+ [AWS Resilience Hub アプリケーションのリソースの表示](view-resources.md)
+ [AWS Resilience Hub アプリケーションの削除](applications-delete.md)
+ [アプリケーションの設定パラメータ](app-config.md)
# AWS Resilience Hub アプリケーション概要の表示
AWS Resilience Hub コンソールのアプリケーション概要ページには、アプリケーション情報と障害耐性の状態の概要が表示されます。
**アプリケーション概要を表示するには**
1. ナビゲーションペインから**アプリケーション**を選択します。
1. **アプリケーション**ページで、表示するアプリケーションの名前を選択します。
アプリケーション概要ページには、次のセクションが含まれています。
**Topics**
+ [評価の概要](#view-assessment-summary-resiliency)
+ [概要](#view-app-summary-resiliency)
+ [アプリケーションの障害耐性](#view-app-resiliency)
+ [実装されたアラーム](#view-app-alarms)
+ [実施した実験](#view-app-experiments)
## 評価の概要
このセクションでは、最後に成功した評価の概要を示し、重要な推奨事項を実用的なインサイトとして強調表示します。 は Amazon Bedrock 生成 AI 機能 AWS Resilience Hub を使用して、 が提供する最も重要なレジリエンスに関する推奨事項にユーザーを集中させます AWS Resilience Hub。重要な項目に焦点を当てることで、アプリケーションのレジリエンス体制を改善する最も重要なレコメンデーションに集中できます。レコメンデーションを選択して概要を表示し、**詳細を表示**を選択して、評価レポートの関連セクションのレコメンデーションの詳細を表示します。評価レポートのレビューの詳細については、「」を参照してください[評価レポートのレビュー](review-assessment.md)。
**注記**
この評価の概要は、米国東部 (バージニア北部) リージョンでのみ利用できます。
Amazon Bedrock の大規模言語モデル (LLMs) によって生成された評価の概要は、提案にすぎません。生成 AI テクノロジーの現在のレベルは完全ではなく、LLMs無限ではありません。バイアスと誤った回答はまれですが、想定する必要があります。LLM からの出力を使用する前に、**評価の概要**の各推奨事項を確認してください。
## 概要
このセクションでは、以下のセクションで選択したアプリケーションの概要を示します。
+ **アプリケーション情報** – このセクションでは、選択したアプリケーションに関する以下の情報を提供します。
+ **アプリケーションステータス** – アプリケーションのステータスを示します。
+ **説明** – アプリケーションの説明。
+ **Version** – 現在評価されているアプリケーションのバージョンを示します。
+ **障害耐性ポリシー** – アプリケーションにアタッチされている障害耐性ポリシーを示します。障害耐性ポリシーの詳細については、「[障害耐性ポリシーの管理](resiliency-policies.md)」を参照してください。
+ **アプリケーションのドリフト** – このセクションでは、選択したアプリケーションの評価の実行中に検出されたドリフトが強調表示され、その障害耐性ポリシーに準拠しているかどうかが確認されます。さらに、アプリケーションバージョンが最後に公開されてからリソースが追加または削除されたかどうかも確認します。このセクションでは、次の情報が表示されます。
+ **ポリシードリフト** – 以下の番号を選択すると、前の評価でポリシーに準拠していたが、現在の評価では準拠しなかったすべてのアプリケーションコンポーネントが表示されます。
+ **リソースドリフト** – 以下の番号を選択すると、最新の評価でドリフトしたすべてのリソースが表示されます。
## アプリケーションの障害耐性
**障害耐性スコア**セクションに表示されるメトリクスは、アプリケーションの最新の障害耐性評価からのものです。
**[障害耐性スコア]**
障害耐性スコアは、潜在的な中断に対処する準備状況を定量化するのに役立ちます。このスコアは、アプリケーションの障害耐性ポリシー、アラーム、標準作業手順書 (SOP) 、および AWS Resilience Hub テストを満たすための推奨事項にアプリケーションがどの程度準拠しているかを反映しています。
アプリケーションが達成できる最大障害耐性スコアは 100% です。このスコアは、事前定義された期間内に実行されるすべての推奨テストを表します。テストによって正しいアラームが開始され、アラームによって正しい SOP が開始されたことが示されます。
例えば、 が 1 つのアラームと 1 つの SOP を含む 1 つのテスト AWS Resilience Hub を推奨しているとします。テストが実行されると、アラームは関連する SOP を開始し、その後正常に実行されます。障害耐性スコアの詳細については、「[障害耐性スコアの理解](resil-score.md)」を参照してください。
## 実装されたアラーム
アプリケーション概要の **[実装済みアラーム]** セクションには、アプリケーションを監視するために Amazon CloudWatch で設定したアラームが一覧表示されます。アラームの詳細については、「[アラームの管理](alarms.md)」を参照してください。
## 実施した実験
アプリケーション概要の **[故障注入実験]** セクションには、故障注入実験のリストが表示されます。故障注入実験の詳細については、「[AWS Fault Injection Service 実験の管理](testing.md)」を参照してください。
# AWS Resilience Hub アプリケーションリソースの編集
正確で有用な障害耐性評価を受けるには、アプリケーションの説明が更新され、実際の AWS アプリケーションとリソースと一致することを確認してください。評価レポート、検証、および推奨事項は、記載されているリソースに基づいています。 AWS アプリケーションからリソースを追加または削除する場合は、それらの変更を に反映する必要があります AWS Resilience Hub。
AWS Resilience Hub は、アプリケーションソースに関する透明性を提供します。アプリケーション内のリソースとアプリケーションソースを識別して編集できます。
**注記**
リソースを編集すると、アプリケーションの AWS Resilience Hub リファレンスのみが変更されます。実際のリソースは変更されません。
不足しているリソースを追加したり、既存のリソースを変更したり、不要なリソースを削除したりできます。リソースは論理的なアプリケーションコンポーネント (AppComponents) にグループ化されます。AppComponents はアプリケーションの構造をより正確に反映するように編集できます。
アプリケーションのドラフトバージョンを編集し、変更を新しい (リリース) バージョンに公開することで、アプリケーションリソースに追加または更新します。 は、アプリケーションのリリースバージョン (更新されたリソースを含む) AWS Resilience Hub を使用して障害耐性評価を実行します。
**アプリケーションの障害耐性を評価するには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** ページで、編集するアプリケーション名を選択します。
1. **[アクション]** メニューから **[障害耐性の評価]** を選択します。
1. **[耐障害性評価を実行]** ダイアログで、レポートの一意の名前を入力するか、**[レポート名]** ボックスに生成された名前を使用します。
1. **[実行]** を選択します。
1. 評価レポートが生成されたことが通知されたら、**[評価]** タブを選択し、評価を選択してレポートを表示します。
1. **[レビュー]** タブを選択すると、アプリケーションの評価レポートが表示されます。
**スケジュールされた評価を有効にするには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **アプリケーション**ページで、スケジュールされた評価を有効にするアプリケーションを選択します。
1. **毎日自動評価**をオンにします。
**スケジュールされた評価を無効にするには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **アプリケーション**ページで、スケジュールされた評価を有効にするアプリケーションを選択します。
1. オフ **毎日自動的に評価**されます。
**注記**
スケジュールされた評価を無効にすると、ドリフト通知が無効になります。
1. **[無効にする]** を選択します。
**アプリケーションのドリフト通知を有効にするには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **アプリケーション**ページで、ドリフト通知を有効にするアプリケーションを選択するか、ドリフト通知設定を編集します。
1. ドリフト通知を編集するには、次のいずれかのオプションを選択します。
+ **アクション** から、**ドリフト通知を有効にする **を選択します。
+ 「アプリケーションドリフト」セクションで**「通知を有効にする**」を選択します。 ****
1. 「」のステップを完了してから[スケジュールされた評価とドリフト通知の設定](scheduled-assessment.md)、この手順に戻ります。
1. **[有効化]** を選択します。
ドリフト通知を有効にすると、スケジュールされた評価も有効になります。
**アプリケーションのドリフト通知を編集するには**
**注記**
この手順は、スケジュールされた評価 (**毎日自動的に評価**がオンになっている) とドリフト通知を有効にしている場合に適用されます。
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **アプリケーション**ページで、ドリフト通知を有効にするアプリケーションを選択するか、ドリフト通知設定を編集します。
1. ドリフト通知を編集するには、次のいずれかのオプションを選択します。
+ **アクション** から、**ドリフト通知の編集 **を選択します。
+ 「アプリケーションドリフト」セクションで**「通知の編集**」を選択します。 ****
1. 「」のステップを完了してから[スケジュールされた評価とドリフト通知の設定](scheduled-assessment.md)、この手順に戻ります。
1. [**Save**] を選択します。
**アプリケーションのセキュリティ権限を更新するには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** ページで、セキュリティ権限を更新するアプリケーションを選択します。
1. **[アクション]** から **[権限の更新]** を選択します。
1. セキュリティ権限を更新するには、[セットアップアクセス許可](setup-permissions.md) の手順を完了してからこの手順に戻ります。
1. **[保存とテスト]** を選択します。
**障害耐性ポリシーをアプリケーションにアタッチするには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** ページで、編集するアプリケーション名を選択します。
1. **[アクション]** メニューから **[障害耐性ポリシーをアタッチ]** を選択します。
1. **[ポリシーをアタッチ]** ダイアログで、**[障害耐性ポリシーの選択]** ドロップダウンリストから障害耐性ポリシーを選択します。
1. **添付**を選択します。
**アプリケーションの入力ソース、リソース、AppComponents を編集するには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** ページで、編集するアプリケーション名を選択します。
1. **[アプリケーション構造]** タブを選択します。
1. **[バージョン]** の前にあるプラス記号 **[\$1]** を選択し、ステータスが **[ドラフト]** のアプリケーションバージョンを選択します。
1. アプリケーションの入力ソース、リソース、AppComponents を編集するには、以下の手順のステップを実行します。
**アプリケーションの入力ソースを編集するには**
1. アプリケーションの入力ソースを編集するには、**[入力ソース]** タブを選択します。
**[入力ソース]** セクションには、アプリケーションリソースのすべての入力ソースが一覧表示されます。次の方法で入力ソースを特定できます。
+ **[ソース名]** – 入力ソースの名前。ソース名を選択すると、それぞれのアプリケーションで詳細が表示されます。手動で追加した入力ソースの場合、リンクは使用できません。例えば、 AWS CloudFormation スタックからインポートされるソース名を選択すると、 コンソールのスタックの詳細ページ AWS CloudFormation にリダイレクトされます。
+ **[ソース ARN]** - 入力ソースの Amazon リソースネーム (ARN)。ARN を選択すると、その詳細がそれぞれのアプリケーションに表示されます。手動で追加した入力ソースの場合、リンクは使用できません。例えば、 AWS CloudFormation のスタックからインポートされる ARN を選択すると、 AWS CloudFormation のコンソールのスタック詳細ページにリダイレクトされます。
+ **[ソースタイプ]** – 入力ソースのタイプ。入力ソースには、Amazon EKS クラスター、 AWS CloudFormation スタック、myApplications アプリケーション AWS Resource Groups、Terraform 状態ファイル、および手動で追加されたリソースが含まれます。
+ **[関連リソース]** – 入力ソースに関連付けられているリソースの数。番号を選択すると、入力ソースのすべての関連リソースが **[リソース]** タブに表示されます。
1. 入力ソースをアプリケーションに追加するには、**[入力ソース]** セクションから **[入力ソースを追加]** を選択します。入力ソースの追加の詳細については、「[リソースコレクションを追加する](discover-structure.md)」を参照してください。
1. 入力ソースを編集するには、入力ソースを選択し、**[アクション]** から以下のいずれかのオプションを選択します。
+ **[入力ソースの再インポート (最大 5 つ)]** – 選択した入力ソースを最大 5 つまで再インポートします。
+ **[入力ソースを削除]** – 選択した入力ソースを削除します。
アプリケーションを公開するには、少なくとも 1 つの入力ソースが含まれている必要があります。入力ソースをすべて削除すると、**[新規バージョンを公開]** は無効になります。
**アプリケーションのリソースを編集するには**
1. アプリケーションのリソースを編集するには、**[リソース]** タブを選択します。
**注記**
未評価のリソースのリストを表示するには、**[未評価のリソースを表示]** を選択します。
**[リソース]** セクションには、アプリケーション記述のテンプレートとして使用することを選択したアプリケーションのリソースが一覧表示されます。検索エクスペリエンスを向上させるために、 AWS Resilience Hub は複数の検索条件に基づいてリソースをグループ化しました。これらの検索条件には、AppComponent タイプ、**[サポートされていない]** リソース、**[除外された]** リソースが含まれます。リソーステーブルの検索条件に基づいて**リソース**をフィルタリングするには、各検索条件の下にある番号を選択します。
次の方法でリソースを特定できます。
+ **論理 ID** – 論理 ID は、 AWS CloudFormation スタック、Terraform 状態ファイル、手動で追加されたアプリケーション、myApplications アプリケーション、または 内のリソースを識別するために使用される名前です AWS Resource Groups。
**注記**
Terraform では、異なるリソースタイプに同じ名前を使用できます。そのため、同じ名前を共有するリソースの論理 ID の末尾には「- resource type」が表示されます。
すべてのアプリケーションリソースのインスタンスを表示するには、**[論理 ID]** の前にあるプラス (**[\$1]**) 記号を選択します。すべてのアプリケーションリソースのインスタンスを表示するには、論理 ID の前にあるプラス (**[\$1]**) 記号を選択します。
サポートされるリソースタイプの詳細については、[AWS Resilience Hub サポートされているリソース](supported-resources.md)を参照してください。
+ **[リソースタイプ]** – リソースタイプはアプリケーションのコンポーネントリソースを識別します。例えば、`AWS::EC2::Instance` は Amazon EC2 インスタンスを宣言します。AppComponent リソースのグループ化の詳細については、「[アプリケーションコンポーネントのリソースのグループ化](AppComponent.grouping.md)」を参照してください。
+ **[ソース名]** – 入力ソースの名前。ソース名を選択すると、それぞれのアプリケーションで詳細が表示されます。手動で追加した入力ソースの場合、リンクは使用できません。例えば、 AWS CloudFormation スタックからインポートされるソース名を選択すると、 のスタックの詳細ページにリダイレクトされます AWS CloudFormation。
+ **[ソースタイプ]** – 入力ソースのタイプ。入力ソースには、 AWS CloudFormation スタック、myApplications アプリケーション AWS Resource Groups、Terraform 状態ファイル、および手動で追加されたリソースが含まれます。
**注記**
Amazon EKS クラスターを編集するには、「** AWS Resilience Hub のアプリケーションプロシージャの入力ソースを編集するには**」のステップを実行します。
+ **ソーススタック** – リソースを含む AWS CloudFormation スタック。この列は、選択したアプリケーション構造のタイプによって異なります。
+ **[物理 ID]** – Amazon EC2 インスタンス ID や S3 バケット名など、そのリソースに実際に割り当てられた識別子。
+ **[含まれている]** – AWS Resilience Hub で、これらのリソースがアプリケーションに含まれるかどうかを示します。
+ **[評価可能]** – AWS Resilience Hub がリソースの障害耐性を評価するかどうかを示します。
+ **AppComponents** – アプリケーション構造が検出されたときにこのリソースに割り当てられた AWS Resilience Hub コンポーネント。
+ **[名前]** – アプリケーションリソースの名前。
+ **アカウント** – 物理リソースを所有する AWS アカウント。
1. リストにないリソースを検索するには、検索ボックスにリソースの論理 ID を入力します。
1. アプリケーションからリソースを削除するには、リソースを選択し、**[アクション]** から **[リソースを除外]** を選択します。
1. アプリケーションのリソースを解決するには、**[リソースの更新]** を選択します。
1. 既存のアプリケーションリソースを変更するには、以下のステップを実行します。
1. リソースを選択し、**[アクション]** から **[スタックを更新]** を選択します。
1. **[スタックの更新]** ページでリソースを更新するには、[リソースコレクションを追加する](discover-structure.md) で該当する手順を完了してから、この手順に戻ります。
1. **[保存]** を選択します。
1. アプリケーションにリソースを追加するには、**[アクション]** から **[リソースの追加]** を選択し、以下の手順を実行します。
1. **[リリースタイプ]** ドロップダウンリストから少なくとも 1 つのリソースタイプを選択します。
1. **[AppComponent]** ドロップダウンリストから AppComponent を選択します。
1. **[リソース名]** ボックスにリソースの論理 ID を入力します。
1. **[リソース識別子]** ボックスに、物理リソース ID、リソース名、またはリソース ARN を入力します。
1. **[追加]** を選択します。
1. リソース名を編集するには、リソースを選択し、**[アクション]** から **[リソース名を編集]** を選択し、次の手順を実行します。
1. **[リソース名]** ボックスにリソースの論理 ID を入力します。
1. **[保存]** を選択します。
1. リソース識別子を編集するには、リソースを選択し、**[アクション]** から **[リソース識別子を編集]** を選択し、次の手順を実行します。
1. **[リソース識別子]** ボックスに、物理リソース ID、リソース名、またはリソース ARN を入力します。
1. **[保存]** を選択します。
1. AppComponent を変更するには、リソースを選択し、**[アクション]** から **[AppComponent を変更]** を選択して、次の手順を実行します。
1. **[AppComponent]** ドロップダウンリストから AppComponent を選択します。
1. **[追加]** を選択します。
1. リソースを削除するには、リソースを選択し、**[アクション]** から **[リソースを削除]** を選択します。
1. リソースを含めるには、リソースを選択し、**[アクション]** から **[リソースを含める]** を選択します。
**アプリケーションの AppComponents を編集するには**
1. アプリケーションの AppComponents を編集するには、**[AppComponents]** タブを選択します。
**注記**
AppComponent リソースのグループ化の詳細については、「[アプリケーションコンポーネントのリソースのグループ化](AppComponent.grouping.md)」を参照してください。
**[AppComponents]** セクションには、リソースをグループ化するすべての論理コンポーネントが一覧表示されます。次の方法で AppComponents を特定できます。
+ **[AppComponent 名]** –アプリケーション構造が見つかったときにこのリソースに割り当てられた AWS Resilience Hub コンポーネントの名前。
+ **[AppComponent タイプ]** – AWS Resilience Hub のコンポーネントのタイプ。
+ **[ソース名]** – 入力ソースの名前。ソース名を選択すると、それぞれのアプリケーションで詳細が表示されます。例えば、 AWS CloudFormation スタックからインポートされるソース名を選択すると、 AWS CloudFormationのスタック詳細ページにリダイレクトされます。
+ **[リソース数]** – 入力ソースに関連付けられているリソースの数。番号を選択すると、入力ソースのすべての関連リソースが **[リソース]** タブに表示されます。
1. AppComponent を作成するには、**[アクション]** メニューから **[AppComponent を新規作成]** を選択し、以下の手順を実行します。
1. **[AppComponent 名]** ボックスに AppComponent の名前を入力します。参考までに、このフィールドにはサンプル名があらかじめ入力されています。
1. **[AppComponent タイプ]** ドロップダウンリストから AppComponent のタイプを選択します。
1. **[保存]** を選択します。
1. AppComponent を編集するには、AppComponent を選択し、**[アクション]** から **[AppComponent の編集]** を選択します。
1. AppComponent を削除するには、AppComponent を選択し、**[アクション]** から **[AppComponent の削除]** を選択します。
リソースリストを変更すると、アプリケーションのドラフトバージョンに変更が加えられたことを示すアラートが表示されます。正確な障害耐性評価を実行するには、アプリケーションの新しいバージョンを公開する必要があります。新しいバージョンを公開する方法に関する詳細については、「[新しい AWS Resilience Hub アプリケーションバージョンの公開](applications-publish.md)」を参照してください。
# アプリケーションコンポーネントの管理
アプリケーションコンポーネント (AppComponent) は、単一のユニットとして動作および失敗する関連 AWS リソースのグループです。たとえば、プライマリデータベースとレプリカデータベースがある場合、両方のデータベースが同じ AppComponent. AWS Resilience Hub に属し、どのリソースがどの AWS AppComponent タイプに属するかを管理するルールがあります。たとえば、 `DBInstance`は に属`AWS::ResilienceHub::DatabaseAppComponent`し、 には属しません`AWS::ResilienceHub::ComputeAppComponent`。
AWS Resilience Hub AppComponents は、次のリソースをサポートしています。
+ `AWS::ResilienceHub::ComputeAppComponent`
+ `AWS::ApiGateway::RestApi`
+ `AWS::ApiGatewayV2::Api`
+ `AWS::AutoScaling::AutoScalingGroup`
+ `AWS::EC2::Instance`
+ `AWS::ECS::Service`
+ `AWS::EKS::Deployment`
+ `AWS::EKS::ReplicaSet`
+ `AWS::EKS::Pod`
+ `AWS::Lambda::Function`
+ `AWS::StepFunctions::StateMachine`
+ `AWS::ResilienceHub::DatabaseAppComponent`
+ `AWS::DocDB::DBCluster`
+ `AWS::DynamoDB::Table`
+ `AWS::ElastiCache::CacheCluster`
+ `AWS::ElastiCache::GlobalReplicationGroup`
+ `AWS::ElastiCache::ReplicationGroup`
+ `AWS::ElastiCache::ServerlessCache`
+ `AWS::RDS::DBCluster`
+ `AWS::RDS::DBInstance`
+ `AWS::ResilienceHub::NetworkingAppComponent`
+ `AWS::EC2::NatGateway`
+ `AWS::ElasticLoadBalancing::LoadBalancer`
+ `AWS::ElasticLoadBalancingV2::LoadBalancer`
+ `AWS::Route53::RecordSet`
+ `AWS:ResilienceHub::NotificationAppComponent`
+ `AWS::SNS::Topic`
+ `AWS::ResilienceHub::QueueAppComponent`
+ `AWS::SQS::Queue`
+ `AWS::ResilienceHub::StorageAppComponent`
+ `AWS::Backup::BackupPlan`
+ `AWS::EC2::Volume`
+ `AWS::EFS::FileSystem`
+ `AWS::FSx::FileSystem`
**注記**
現在、 は Amazon FSx for Windows File Server のみ AWS Resilience Hub をサポートしています。
+ `AWS::S3::Bucket`
**Topics**
+ [アプリケーションコンポーネントのリソースのグループ化](AppComponent.grouping.md)
# アプリケーションコンポーネントのリソースのグループ化
アプリケーションとその AWS Resilience Hub リソースが にインポートされると、 AWS Resilience Hub はアプリケーションをインポートするときに、関連するリソースを同じ AppComponent にグループ化するために最大限の努力をしますが、グループ化が常に 100% 正確であるとは限りません。一部のリソースは手動グループ化のためにブロックされ、該当する場合に自動的にグループ化されます。これらのサービスには、特定のグループ化設定を必要とする厳密な依存関係があるためです。手動グループ化のためにブロックされているサービスの完全なリストについては、「」を参照してください[手動グループ化のブロックされたサービス](blocked-services-for-manual-grouping.md)。
AWS Resilience Hub は、アプリケーションとそのリソースが正常にインポートされた後に、次のアクティビティを実行します。
+ リソースをスキャンして、評価の精度を向上させるために新しい AppComponents に再グループ化できるかどうかを確認します。
+ が新しい AppComponents に再グループ化できるリソース AWS Resilience Hub を識別すると、レコメンデーションと同じ が表示され、同じリソースを承認または拒否できます。では AWS Resilience Hub、グループ化レコメンデーションに割り当てられた信頼度は、属性とメタデータに基づいてリソースをグループ化する確実度を示します。**高い**信頼レベルは、 AWS Resilience Hub の信頼レベルが 90% 以上であり、そのグループのリソースが関連しており、グループ化する必要があることを示します。**中程度**の信頼レベルは、 AWS Resilience Hub の信頼レベルが 70%～90% で、そのグループのリソースが関連しており、グループ化する必要があることを示します。
**注記**
AWS Resilience Hub では、推定ワークロード RTO と推定ワークロード RPO を計算してレコメンデーションを生成できるように、正しいグループ化が必要です。
正しいグループ分けの例を以下に示します。
+ プライマリデータベースとレプリカを 1 つの AppComponent にグループ化します。
+ 同じアプリケーションを実行する Amazon EC2 インスタンスを 1 つの AppComponent にグループ化します。
+ Amazon ECS サービスを 1 つのリージョンにグループ化し、別のリージョンの Amazon ECS サービスを 1 つの AppComponent にフェイルオーバーします。
によるリソースグループ化のレコメンデーションの確認と含めの詳細については AWS Resilience Hub、以下のトピックを参照してください。
+ [AWS Resilience Hub リソースのグループ化に関する推奨事項](grouping-recommendation.md)
+ [リソースを AppComponent に手動でグループ化する](AppComponent-manual-grouping.md)
# 手動グループ化のブロックされたサービス
AWS Resilience Hub は、アプリケーションの耐障害性評価とレコメンデーションに影響を与える可能性のある設定エラーを防ぐために、特定の AWS サービスのリソースを手動でグループ化することをブロックします。これらのサービスは、依存関係と設定に基づいて自動的にグループ化されます。これらのリソースを含むアプリケーションを定義すると AWS Resilience Hub、それらの関係、依存関係、耐障害性の要件を分析し、正確な評価結果を保証する最適なグループ化を作成します。
手動グループ化のためにブロックされた AWS サービスのリスト:
+ Amazon API Gateway
+ Amazon DocumentDB
+ Amazon DynamoDB
+ Amazon Elastic Block Store
+ Amazon Elastic File System
+ Amazon Relational Database Service
+ Amazon S3
+ Amazon Simple Queue Service
+ FSx for Windows File Server
+ NAT Gateway
# AWS Resilience Hub リソースのグループ化に関する推奨事項
このセクションでは、 でリソースグループ化の推奨事項を生成して確認する方法について説明します AWS Resilience Hub。
**注記**
`AWSResilienceHubAsssessmentExecutionPolicy` AWS 管理ポリシー AWS Resilience Hub を使用して、 の操作に必要な IAM アクセス許可を付与できます。 AWS 管理ポリシーの詳細については、「」を参照してください[AWSResilienceHubAsssessmentExecutionPolicy](security-iam-awsmanpol.md#security_iam_aws-assessment-policy)。
**リソースグループ化の推奨事項を表示するには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **アプリケーションの追加**ページを選択し、リソースグループ化の推奨事項を確認するアプリケーション名を選択します。
1. **[アプリケーション構造]** タブを選択します。
1. に情報アラート AWS Resilience Hub が表示される場合は、レ**コメンデーションの確認**を選択して、すべてのリソースグループ化のレコメンデーションを表示します。それ以外の場合は、次の手順を実行して、リソースグループ化の推奨事項を手動で生成します。
1. **[リソース]** をクリックします。
1. **アクション**メニューから**「レコメンデーションのグループ化の取得**」を選択します。
AWS Resilience Hub はリソースをスキャンして、評価の精度を向上させるために、可能な限り最適な方法で関連する AppComponents にグループ化する方法を確認します。がリソースをグループ化できることを AWS Resilience Hub 学習すると、同じ の情報アラートが表示されます。
1. 情報アラートが表示された場合は、レ**コメンデーションの確認**を選択して、すべてのリソースグループ化レコメンデーションを表示します。
AppComponents は、以下を使用して**リソースグループ化の推奨事項を確認する**セクションで識別できます。
+ **AppComponent name** – リソースがグループ化される AppComponent の名前。
+ **信頼度** – グループ化レコメンデーションの AWS Resilience Hub の信頼度を示します。
+ **リソース数** – AppComponent でグループ化されるリソースの数を示します。
+ **[AppComponent タイプ]** – AppComponent のタイプを示します。
**AppComponents でグループ化されるリソースを表示するには**
1. **[リソースグループ化の推奨事項を表示するには](#view-resource-grouping)** 手順のステップを完了し、この手順に戻ります。
1. **リソースグループのレコメンデーションを確認する**セクションで、チェックボックス (**AppComponent 名**に隣接) を選択して、選択した AppComponent 内でグループ化されるすべてのリソースを表示します。複数のチェックボックスを選択すると、 は**、選択した AppComponents をそれぞれの AppComponent タイプにグループ化する動的に生成されたレコメン**デーション選択セクション AWS Resilience Hub を表示します。 AppComponents AppComponent 各 AppComponent タイプの下にある番号を選択すると、選択した AppComponent 内でグループ化されるすべてのリソースが表示されます。
以下を使用して、リソースセクションの選択した AppComponent でグループ化される**リソース**を特定できます。
+ **[論理 ID]** - リソースの論理 ID を示します。論理 ID は、 AWS CloudFormation スタック、Terraform 状態ファイル、myApplications アプリケーション、または 内のリソースを識別するために使用される名前です AWS Resource Groups。
+ **物理 ID** – Amazon EC2 インスタンス ID や Amazon S3 バケット名など、リソースに実際に割り当てられた識別子。
+ **Type** – リソースのタイプを示します。
+ **リージョン** – リソースが配置されている AWS リージョン。
**リソースグループ化の推奨事項を受け入れるには**
1. **[リソースグループ化の推奨事項を表示するには](#view-resource-grouping)** 手順のステップを完了し、この手順に戻ります。
1. **リソースグループ化の推奨事項の確認**セクションで、**AppComponent 名**の横にあるすべてのチェックボックスをオンにします。特定の AppComponent を検索するには、AppComponent **sの検索AppComponents** 名を入力します。
**注記**
デフォルトでは、 はすべてのリソースグループ化の推奨事項 AWS Resilience Hub を表示します。以前に拒否されたリソースグループのレコメンデーションでテーブルをフィルタリングするには、**AppComponents **の検索」ボックスの横にあるドロップダウンメニューから**「以前に拒否**済み」を選択します。
1. [**Accept (承諾)**] を選択します。
1. リソースグループのレコメンデーション**を受け入れる**ダイアログで Accept を選択します。 ****
AWS Resilience Hub リソースのグループ化が成功すると、 は情報アラートを表示します。リソースグループレコメンデーションのサブセットのみを受け入れた場合、**リソースグループレコメンデーションの確認**セクションには、受け入れていないすべてのリソースグループレコメンデーションが表示されます。
**リソースグループ化の推奨事項を拒否するには**
1. **[リソースグループ化の推奨事項を表示するには](#view-resource-grouping)** 手順のステップを完了し、この手順に戻ります。
1. **リソースグループのレコメンデーションを確認する**セクションで、**AppComponent 名**の横にあるすべてのチェックボックスをオンにします。特定の AppComponent を検索するには、Find AppComponent ** AppComponents** 名を入力します。
**注記**
デフォルトでは、 はすべてのリソースグループ化の推奨事項 AWS Resilience Hub を表示します。以前に拒否されたリソースグループのレコメンデーションでテーブルをフィルタリングするには、**AppComponents **の検索」ボックスの横にあるドロップダウンメニューから**「以前に拒否**済み」を選択します。
1. [**拒否**] を選択します。
1. リソースグループのレコメンデーションを拒否する理由のいずれかを選択し、**リソースグループのレコメンデーション****を拒否**ダイアログで拒否を選択します。
AWS Resilience Hub は、同じことを確認する情報アラートを表示します。リソースグループ化レコメンデーションのサブセットのみを拒否した場合、**リソースグループ化レコメンデーションの確認**セクションには、承認されていないすべてのリソースグループ化レコメンデーションが表示されます。
# リソースを AppComponent に手動でグループ化する
このセクションでは、リソースを AppComponent に手動でグループ化し、異なる AppComponent をリソースに割り当てる方法について説明します AWS Resilience Hub。
**リソースをグループ化するには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** ページで、グループ化するリソースを含むアプリケーション名を選択します。
1. **[アプリケーション構造]** タブを選択します。
1. **[バージョン]** タブで、ステータスが **[ドラフト]** のアプリケーションバージョンを選択します。
1. **[リソース]** タブを選択します。
1. **論理 ID** の横にあるチェックボックスをオンにして、グループ化するすべてのリソースを選択します。
**注記**
手動で追加したリソースは選択できません。
1. **[アクション]** を選択し、**[リソースの追加]** を選択します。
1. **[AppComponent を選択]** ドロップダウンリストから、リソースをグループ化したい AppComponent を選択します。
1. **[保存]** を選択します。
1. **[新しいバージョンを発行]** を選択します。
1. **[アプリケーション構造]** タブを選択します。
1. アプリケーションの公開バージョンを表示するには、以下の手順を実行します。
1. **[バージョン]** タブで、**[現在のリリース]** ステータスのアプリケーションバージョンを選択します。
1. **[リソース]** タブを選択します。
**AppComponent にリソースを割り当てるには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** ページで、再グループ化するリソースを含むアプリケーション名を選択します。
1. **[アプリケーション構造]** タブを選択します。
1. **[バージョン]** で、ステータスが **[ドラフト]** のアプリケーションバージョンを選択します。
1. **[リソース]** タブを選択します。
1. **論理 ID** の横にあるチェックボックスをオンにして、リソースを選択します。
1. **アクション**メニューから**AppComponent の変更**」を選択します。
1. **[AppComponent]** セクションから現在の AppComponent を削除するには、現在の AppComponent 名が表示されているラベルの右上隅にある **[X]** を選択します。
1. リソースを別の AppComponent にグループ化するには、**[AppComponent を選択]** ドロップダウンリストから別の AppComponent を選択します。
1. **[追加]** を選択します。
1. **[AppComponents]** タブから空の AppComponents をすべて削除します。
1. **[新しいバージョンを発行]** を選択します。
1. **[アプリケーション構造]** タブを選択します。
1. アプリケーションの公開バージョンを表示するには、以下の手順を実行します。
1. **[バージョン]** タブで、**[現在のリリース]** ステータスのアプリケーションバージョンを選択します。
1. **[リソース]** タブを選択します。
# 新しい AWS Resilience Hub アプリケーションバージョンの公開
「」の説明に従って AWS Resilience Hub アプリケーションリソースを変更したら[AWS Resilience Hub アプリケーションリソースの編集](application-resources.md)、アプリケーションの新しいバージョンを発行して、正確な耐障害性評価を実行する必要があります。また、新しい推奨アラーム、SOP、テストをアプリケーションに追加した場合は、アプリケーションの新しいバージョンを公開する必要がある場合があります。
**アプリケーションの新しいバージョンを発行するには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** ページで、アプリケーションの名前を選択します。
1. **[アプリケーション構造]** タブを選択します。
1. **[新しいバージョンを発行]** を選択します。
1. **バージョン発行**ダイアログの**「名前**」ボックスにアプリケーションバージョンの名前を入力するか、 が提案するデフォルト名を使用できます AWS Resilience Hub。
1. **[発行]** を選択します。
アプリケーションの新しいバージョンを公開すると、そのバージョンが障害耐性評価を実行したときに評価されるバージョンになります。また、変更を加えるまで、ドラフトバージョンはリリースされたバージョンと同じになります。
アプリケーションの新しいバージョンを公開したら、新しい障害耐性評価レポートを実行して、アプリケーションがまだレジリエンシーポリシーを満たしていることを確認することをお勧めします。評価の実行については、「[での障害耐性評価の実行と管理 AWS Resilience Hub](resil-assessments.md)」を参照してください。
# すべての AWS Resilience Hub アプリケーションバージョンの表示
アプリケーションの変更を追跡しやすくするために、 は、アプリケーションが作成された時点からの以前のバージョン AWS Resilience Hub を表示します AWS Resilience Hub。
**アプリケーションのすべてのバージョンを表示するには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** ページで、アプリケーションの名前を選択します。
1. **[アプリケーション構造]** タブを選択します。
1. アプリケーションの以前のバージョンをすべて表示するには、**すべてのバージョンを表示する**前にプラス記号 (**\$1**) を選択します。 AWS Resilience Hub は、ドラフトリリースステータスと**最新リリース**ステータスをそれぞれ使用して、アプリケーションの**ドラフト**バージョンと最近リリースされたバージョンを示します。アプリケーションの任意のバージョンを選択して、そのリソース、AppComponent、入力ソース、およびその他の関連情報を表示できます。
さらに、次のオプションのいずれかを使用してリストをフィルタリングすることもできます。
+ **[バージョン名で絞り込む]** – 名前を入力すると、アプリケーションのバージョン名で結果が絞り込まれます。
+ **[日付と時間の範囲によるフィルタリング]** – このフィルターを適用するには、カレンダーアイコンを選択し、以下のオプションのいずれかを選択して、時間範囲に一致する結果で絞り込みます。
+ **[相対範囲]** – 使用可能なオプションを 1 つ選択して **[適用]** を選択します。
**[カスタマイズ範囲]** オプションを選択した場合は、**[期間を入力]** ボックスに期間を入力し、**[時間単位]** ドロップダウンリストから適切な時間単位を選択して、**[適用]** を選択します。
+ **[相対範囲]** – 日付と時刻の範囲を指定するには、開始時刻と終了時刻を指定し、**[適用]**を選択します。
# AWS Resilience Hub アプリケーションのリソースの表示
**アプリケーションのリソースを表示するには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** ページで、セキュリティ権限を更新するアプリケーションを選択します。
1. **[アクション]** から **[リソースを表示]** を選択します。
**[リソース]** タブでは、以下の方法で **[リソース]** テーブル内のリソースを識別できます。
+ **論理 ID** – 論理 ID は、 AWS CloudFormation スタック、Terraform 状態ファイル、myApplications アプリケーション、または 内のリソースを識別するために使用される名前です AWS Resource Groups。
**注記**
Terraform では、異なるリソースタイプに同じ名前を使用できます。そのため、同じ名前を共有するリソースの論理 ID の末尾には「- resource type」が表示されます。
すべてのアプリケーションリソースのインスタンスを表示するには、**[論理 ID]** の前にあるプラス (**[\$1]**) 記号を選択します。すべてのアプリケーションリソースのインスタンスを表示するには、論理 ID の前にあるプラス (**[\$1]**) 記号を選択します。
サポートされるリソースタイプの詳細については、[AWS Resilience Hub サポートされているリソース](supported-resources.md)を参照してください。
+ **[ステータス]** – AWS Resilience Hub がリソースの障害耐性を評価するかどうかを示します。
+ **[リソースタイプ]** – リソースタイプはアプリケーションのコンポーネントリソースを識別します。例えば、`AWS::EC2::Instance` は Amazon EC2 インスタンスを宣言します。AppComponent リソースのグループ化の詳細については、「[アプリケーションコンポーネントのリソースのグループ化](AppComponent.grouping.md)」を参照してください。
+ **[ソース名]** – 入力ソースの名前。ソース名を選択すると、それぞれのアプリケーションで詳細が表示されます。手動で追加した入力ソースの場合、リンクは使用できません。たとえば、 AWS CloudFormation スタックからインポートされるソース名を選択すると、 のスタックの詳細ページにリダイレクトされます AWS CloudFormation。
+ **[ソースタイプ]** – 入力ソースのタイプ。
+ **[AppComponent タイプ]** – 入力ソースのタイプ。入力ソースには、 AWS CloudFormation スタック、myApplications アプリケーション AWS Resource Groups、Terraform 状態ファイル、手動で追加されたリソースが含まれます。
**注記**
Amazon EKS クラスターを編集するには、「** AWS Resilience Hub のアプリケーションプロシージャの入力ソースを編集するには**」のステップを実行します。
+ **[物理 ID]** – Amazon EC2 インスタンス ID や S3 バケット名など、そのリソースに実際に割り当てられた識別子。
+ **[含まれている]** – AWS Resilience Hub で、これらのリソースがアプリケーションに含まれるかどうかを示します。
+ **AppComponents** – アプリケーション構造が検出されたときにこのリソースに割り当てられた AWS Resilience Hub コンポーネント。
+ **[名前]** – アプリケーションリソースの名前。
+ **アカウント** – 物理リソースを所有する AWS アカウント。
1. **[保存とテスト]** を選択します。
# AWS Resilience Hub アプリケーションの削除
アプリケーションの上限である 50 に達したら、追加する前に 1 つ以上のアプリケーションを削除する必要があります。
**アプリケーションを削除するには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーションバージョン]** ページで、削除するすべてのアプリケーションバージョンを選択します。
1. **[アクション]** を選択してから、**[アプリケーションの削除]** を選択します。
1. 削除を確定するには、**[削除]** ボックスに **[削除]** と入力し、**[削除]** を選択します。
# アプリケーションの設定パラメータ
AWS Resilience Hub は、アプリケーションに関連付けられたリソースに関する追加情報を収集する入力メカニズムを提供します。この情報により、 AWS Resilience Hub はリソースをより深く理解し、耐障害性に関する推奨事項を提供します。
**[アプリケーション構成パラメータ]** セクションには、 AWS Elastic Disaster Recoveryのクロスリージョンフェイルオーバーサポートのすべての構成パラメータが一覧表示されています。以下により、構成パラメータを特定できます。
+ **[トピック]** – 設定されているアプリケーションの領域を示します。例えば、フェイルオーバー構成などです。
+ **目的** – が情報を AWS Resilience Hub リクエストした理由を示します。
+ **パラメータ** – アプリケーションにレコメンデーションを提供するために AWS Resilience Hub が使用する、アプリケーションの領域に固有の詳細を示します。現在、このパラメータは 1 つのフェイルオーバーリージョンと 1 つの関連付けられたアカウントのキー値のみを使用します。
# アプリケーション設定パラメータの更新
このセクションでは、 の設定パラメータを更新 AWS Elastic Disaster Recovery し、アプリケーションを発行して、障害耐性評価用に更新されたパラメータを含めることができます。
**アプリケーション設定パラメータを更新するには**
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** ページで、編集するアプリケーション名を選択します。
1. **[アプリケーション設定パラメータ]** タブを選択します。
1. **[更新]** を選択します。
1. **[アカウント ID]** ボックスにフェイルオーバーアカウント ID を入力します。
1. **[リージョン]** ドロップダウンリストからフェイルオーバーリージョンを選択します。
**注記**
この機能を無効にする場合は、ドロップダウンリストから **[–]** を選択します。
1. **[更新して公開]** を選択します。
# 障害耐性ポリシーの管理
このセクションでは、アプリケーションの障害耐性ポリシーを作成する方法について説明します。障害耐性ポリシーを正しく設定することで、アプリケーションの障害耐性状態を把握できます。障害耐性ポリシーには、アプリケーションがソフトウェア、ハードウェア、アベイラビリティーゾーン、 AWS リージョンなどの中断タイプから回復すると推定されるかどうかを評価するために使用する情報と目的が含まれています。これらのポリシーが実際のアプリケーションを変えたり、影響したりすることはありません。複数のアプリケーションに同じ障害耐性ポリシーを適用することができます。
障害耐性ポリシーを作成するときは、目標復旧時間 (RTO) と目標復旧時点 (RPO) を定義します。目標によって、アプリケーションが障害耐性ポリシーを満たしているかどうかが決まります。ポリシーをアプリケーションに添付し、障害耐性評価を実行します。ポートフォリオ内のアプリケーションの種類ごとに異なるポリシーを作成できます。例えば、リアルタイム取引アプリケーションには、月次レポートアプリケーションとは異なる障害耐性ポリシーが適用されます。
**注記**
AWS Resilience Hub では、障害耐性ポリシーの **RTO** および **RPO** フィールドに値 0 を入力できます。ただし、アプリケーションを評価する際、最も低い評価結果はゼロに近いです。したがって、**[RTO]** と **[RPO]** のフィールドにゼロを入力すると、推定ワークロード RTO と推定ワークロード RPO の結果はほぼゼロになり、アプリケーションの **[コンプライアンスステータス]** は **[ポリシー違反]** に設定されます。
評価では、添付されている障害耐性ポリシーと照らし合わせてアプリケーション構成を評価します。プロセスの最後に、 は、回復力ポリシーの復旧ターゲットに対してアプリケーションがどのように測定するかの評価 AWS Resilience Hub を提供します。
障害耐性ポリシーは、アプリケーションでもレジリエンシーポリシーでも作成できます。ポリシーに関連する詳細にアクセスしたり、ポリシーを変更したり削除したりできます。
AWS Resilience Hub は、RTO および RPO ターゲットを使用して、これらの潜在的なタイプの中断の回復性を測定します。
+ **アプリケーション** — 必要なソフトウェアサービスまたはプロセスの喪失。
+ **クラウドインフラストラクチャ** — EC2 インスタンスなどのハードウェアの喪失。
+ **クラウドインフラストラクチャアベイラビリティーゾーン (AZ)** — 1 つ以上のアベイラビリティーゾーンが使用できません。
+ **クラウドインフラストラクチャリージョン** — 1 つ以上のリージョンが使用できません。
AWS Resilience Hub では、カスタマイズされた障害耐性ポリシーを作成したり、推奨されるオープンスタンダードの障害耐性ポリシーを使用したりできます。カスタマイズされたポリシーを作成するときは、ポリシーに名前を付けて説明し、ポリシーを定義する適切なレベルまたは階層を選択します。これらの階層には、基礎 IT コアサービス、ミッションクリティカル、クリティカル、重要、非クリティカルが含まれます。
アプリケーションのクラスに適した階層を選択します。例えば、リアルタイム取引システムをクリティカルと分類し、月次レポートアプリケーションを非クリティカルと分類できます。標準ポリシーを使用する場合は、事前に構成された層と中断タイプごとの RTO および RPO ターゲットの値を備えた障害耐性ポリシーを選択できます。必要な場合には、階層と RTO、RPO 目標を変更できます。
障害耐性ポリシーは、障害耐性ポリシーで作成することも、新しいアプリケーションを記述するときに作成することもできます。
# 障害耐性ポリシーの作成
では AWS Resilience Hub、障害耐性ポリシーを作成できます。障害耐性ポリシーには、アプリケーションがソフトウェア、ハードウェア、アベイラビリティーゾーン、 AWS リージョンなどの中断タイプから回復できるかどうかを評価するために使用する情報と目的が含まれています。これらのポリシーが実際のアプリケーションを変えたり、影響したりすることはありません。複数のアプリケーションに同じ障害耐性ポリシーを適用することができます。
障害耐性ポリシーを作成するときは、目標復旧時間 (RTO) と目標復旧時点 (RPO) を定義します。評価を実行すると、 は、アプリケーションが障害耐性ポリシーで定義されている目的を達成すると推定されるかどうか AWS Resilience Hub を決定します。
評価では、添付されている障害耐性ポリシーと照らし合わせてアプリケーション構成を評価します。プロセスの最後に、 は、アプリケーションの障害耐性ポリシーの目的に対する評価 AWS Resilience Hub を提供します。
**注記**
AWS Resilience Hub では、障害耐性ポリシーの **RTO** および **RPO** フィールドに値 0 を入力できます。ただし、アプリケーションを評価する際、最も低い評価結果はゼロに近いです。したがって、**[RTO]** と **[RPO]** のフィールドにゼロを入力すると、推定ワークロード RTO と推定ワークロード RPO の結果はほぼゼロになり、アプリケーションの **[コンプライアンスステータス]** は **[ポリシー違反]** に設定されます。
障害耐性ポリシーは、アプリケーションでもレジリエンシーポリシーでも作成できます。ポリシーに関連する詳細にアクセスしたり、ポリシーを変更したり削除したりできます。
**アプリケーションで障害耐性ポリシーを作成するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. [アプリケーションを追加して開始する](describe-app-intro.md) から [タグを追加](add-tags.md) までの手順を完了してください。
1. **[障害耐性ポリシー]** セクションで、**[障害耐性ポリシーの作成]** を選択します。
**[障害耐性ポリシーの作成]** ページが表示されます。
1. **[作成方法の選択]** セクションで、**[ポリシーの作成]** を選択します。
1. ポリシーの名前を入力します。
1. (オプション) ポリシーの説明を入力します。
1. **[ティア]** ドロップダウンリストから次のいずれかを選択します。
+ **[基本 IT コアサービス]**
+ **[ミッションクリティカル]**
+ **[非常事態]**
+ **[重要]**
+ **[非クリティカル]**
1. **[RTO]** と **[RPO]** の両方の目標について、**[カスタマーアプリケーション RTO と RPO]** のボックスに数値を入力し、その値が表す時間単位を選択します。
**[インフラストラクチャ]** と **[アベイラビリティーゾーン]** の **[インフラストラクチャ RTO と RPO]** でこれらのエントリを繰り返します。
1. (オプション) マルチリージョンアプリケーションを使用している場合は、リージョンの RTO と RPO のターゲットを定義できます。
**[リージョン]** をオンにします。リージョン **[RTO]** と **[RPO]** の両方の目標について、**[カスタマーアプリケーション RTO と RPO]** のボックスに数値を入力し、その値が表す時間単位を選択します。
1. (オプション) タグを追加する場合は、ポリシーの作成を続行しながら追加することができます。タグの詳細については、*AWS 参考文献*の[リソースのタグ付け](https://docs.aws.amazon.com//general/latest/gr/aws_tagging.html)を参照してください。
1. **[作成]** を選択して、ポリシーを作成します。
**障害耐性ポリシーで障害耐性ポリシーを作成するには**
1. 左側のナビゲーションメニューで**ポリシー**を選択します。
1. **[障害耐性ポリシー]** セクションで、**[障害耐性ポリシーの作成]** を選択します。
**[障害耐性ポリシーの作成]** ページが表示されます。
1. ポリシーの名前を入力します。
1. (オプション) ポリシーの説明を入力します。
1. **[ティア]** から次のいずれかを選択します。
+ **[基本 IT コアサービス]**
+ **[ミッションクリティカル]**
+ **[非常事態]**
+ **[重要]**
+ **[非クリティカル]**
1. **[RTO]** と **[RPO]** の両方の目標について、**[カスタマーアプリケーション RTO と RPO]** のボックスに数値を入力し、その値が表す時間単位を選択します。
**[インフラストラクチャ]** と **[アベイラビリティーゾーン]** の **[インフラストラクチャ RTO と RPO]** でこれらのエントリを繰り返します。
1. (オプション) マルチリージョンアプリケーションを使用している場合は、リージョンの RTO と RPO のターゲットを定義できます。
**[リージョン]** をオンにします。**[RTO]** と **[RPO]** の両方の目標について、**[カスタマーアプリケーション RTO と RPO]** のボックスに数値を入力し、その値が表す時間単位を選択します。
1. (オプション) タグを追加する場合は、ポリシーの作成を続行しながら追加することができます。タグの詳細については、*AWS 参考文献*の[リソースのタグ付け](https://docs.aws.amazon.com//general/latest/gr/aws_tagging.html)を参照してください。
1. **[作成]** を選択して、ポリシーを作成します。
**推奨ポリシーに基づいて障害耐性ポリシーを作成するには**
1. 左側のナビゲーションメニューで**ポリシー**を選択します。
1. **[作成方法の選択]** セクションで、**[推奨ポリシーに基づいてポリシーを選択]** を選択します。
1. **[障害耐性ポリシー]** セクションで、**[障害耐性ポリシーの作成]** を選択します。
**[障害耐性ポリシーの作成]** ページが表示されます。
1. ポリシーの名前を入力します。
1. (オプション) ポリシーの説明を入力します。
1. **[推奨障害耐性ポリシー]** セクションで、以下の定義済みの障害耐性ポリシー階層の中から 1 つ選択してください。
+ **[重要度の低いアプリケーション]**
+ **[重要なアプリケーション]**
+ **[クリティカルアプリケーション]**
+ **[グローバルクリティカルアプリケーション]**
+ **[ミッションクリティカルアプリケーション]**
+ **グローバルミッションクリティカルアプリケーション**
+ **ファンダメンタルコアサービス**
1. 障害耐性ポリシーを作成するには、**[ポリシーの作成]** を選択します。
## 障害耐性ポリシーの詳細へのアクセス
障害耐性ポリシーを開くと、そのポリシーに関する重要な詳細が表示されます。障害耐性を編集または削除することもできます。
障害耐性ポリシーの詳細は、**概要**と**タグ**という 2 つの主要なビューで構成されています。
**[概要]**
[基本情報]
障害耐性ポリシーについて、名前、説明、階層、コスト階層、および作成日という情報が表示されます。
推定ワークロード RTO と推定ワークロード RPO
この障害耐性ポリシーに関連する推定ワークロード RTO と推定ワークロード RPO の中断タイプが表示されます。
**タグ**
このビューを使用して、アプリケーション内部のタグを管理、追加、および削除します。
**障害耐性ポリシーの詳細で障害耐性ポリシーを編集するには**
1. 左側のナビゲーションメニューで**ポリシー**を選択します。
1. **障害耐性ポリシー**で、障害耐性ポリシーを開きます。
1. **[編集]** を選択します。**基本情報**、**RTO**、**RPO** の各フィールドに適切な変更を入力します。次に、**変更の保存**を選択します。
**障害耐性ポリシーで障害耐性ポリシーを編集するには**
1. 左側のナビゲーションメニューで**ポリシー**を選択します。
1. **障害耐性ポリシー**で、障害耐性ポリシーを選択します。
1. **アクション**を選択して、**編集**を選択します。
1. **基本情報**、**RTO**、**RPO** の各フィールドに適切な変更を入力します。次に、**変更の保存**を選択します。
**障害耐性ポリシー詳細で障害耐性ポリシーを削除するには**
1. 左側のナビゲーションメニューで**ポリシー**を選択します。
1. **障害耐性ポリシー**で、障害耐性ポリシーを開きます。
1. **削除**をクリックします。**削除**を選択し、確定します。
**障害耐性ポリシー内の障害耐性ポリシーを削除するには**
1. 左側のナビゲーションメニューで**ポリシー**を選択します。
1. **障害耐性ポリシー**で、障害耐性ポリシーを選択します。
1. 「**アクション**」を選択して、「**削除**」を選択します。
1. **削除**を選択し、確定します。
# での障害耐性評価の実行と管理 AWS Resilience Hub
アプリケーションが変更されたら、障害耐性評価を実行する必要があります。評価では、各アプリケーションコンポーネントの設定をポリシーと比較し、アラーム、SOP、テストの推奨事項を作成します。これらの推奨構成により、復旧手順の速度を向上させることができます。
アラームの推奨事項は、停止を検出するアラームの設定に役立ちます。SOP の推奨事項には、バックアップからの復旧など、一般的な復旧プロセスを管理するスクリプトが用意されています。テスト推奨事項には、構成が正しく動作していることを確認するための提案が記載されています。例えば、ネットワークの問題による自動スケーリングや負荷分散などの自動復旧中にアプリケーションが復旧するかどうかをテストできます。また、リソースが上限に達したときにアプリケーションアラームがトリガーされるかどうか、指定した条件下で SOP がどの程度機能するかについても、テストできます。
**Topics**
+ [での障害耐性評価の実行 AWS Resilience Hub](run-assessment.md)
+ [評価レポートのレビュー](review-assessment.md)
+ [障害耐性評価の削除](delete-assessment.md)
# での障害耐性評価の実行 AWS Resilience Hub
の複数の場所から障害耐性評価を実行できます AWS Resilience Hub。アプリケーションの詳細については、「[AWS Resilience Hub アプリケーションの説明と管理](applications.md)」を参照してください。
**アクションメニューから回復力評価を実行するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** テーブルからアプリケーションを選択します。
1. **[アクション]** メニューで **[障害耐性を評価]** を選択します。
1. **[耐障害性評価を実行]** ダイアログでは、一意の名前を入力することも、生成された評価名を使用することもできます。
1. **[実行]** を選択します。
評価レポートを確認するには、アプリケーションで **[評価]** を選択します。詳細については、「[評価レポートのレビュー](review-assessment.md)」を参照してください。
**評価タブから障害耐性評価を実行するには**
アプリケーションまたは障害耐性ポリシーが変更されたときに、新しい障害耐性評価を実行できます。
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** テーブルからアプリケーションを選択します。
1. **[評価]** タブを選択します。
1. **[耐障害性評価を実行]** を選択します。
1. **[耐障害性評価を実行]** ダイアログでは、一意の名前を入力することも、生成された評価名を使用することもできます。
1. **[実行]** を選択します。
評価レポートを確認するには、アプリケーションで **[評価]** を選択します。詳細については、「[評価レポートのレビュー](review-assessment.md)」を参照してください。
# 評価レポートのレビュー
評価レポートはアプリケーションの **[評価]** ビューにあります。
**評価レポートを検索するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** で、アプリケーションを選択します。
1. **「評価**」タブで、**「障害耐性評価」セクションから評価**レポートを選択します。
レポートを開くと、以下のようになります。
+ 評価レポートの概要
+ 障害耐性を向上させるための推奨事項。
+ アラーム、SOP、テストの設定に関する推奨事項
+ タグを作成して管理し、 AWS リソースを検索してフィルタリングする方法
## 評価レポート
このセクションでは、評価レポートの概要を示します。 は、各中断タイプと関連するアプリケーションコンポーネントを AWS Resilience Hub 一覧表示します。また、実際の RTO ポリシーと RPO ポリシーを一覧表示し、アプリケーションコンポーネントがポリシー目標を達成できるかどうかを判断します。
**概要**:
アプリケーションの名前、障害耐性ポリシーの名前、およびレポートの作成日が表示されます。
**検出されたリソースドリフト**
このセクションでは、公開されたアプリケーションの最新バージョンに含まれた後に追加または削除されたすべてのリソースを一覧表示します。**入力ソースの再インポート** を選択して、入力ソースタブのすべての入力**ソース** (ドリフトしたリソースを含む) を再インポートします。**発行と評価**を選択して、更新されたリソースをアプリケーションに含め、正確な耐障害性評価を受け取ります。
ドリフトした入力ソースは、以下を使用して識別できます。
+ **[論理 ID]** - リソースの論理 ID を示します。論理 ID は、 AWS CloudFormation スタック、Terraform 状態ファイル、myApplications アプリケーション、または 内のリソースを識別するために使用される名前です AWS Resource Groups。
+ **変更** – 入力リソースが**追加**または削除されたかどうかを示します****。
+ **[ソース名]** - リソース名を示します。ソース名を選択すると、それぞれのアプリケーションで詳細が表示されます。手動で追加した入力ソースの場合、リンクは使用できません。たとえば、 AWS CloudFormation スタックからインポートされるソース名を選択すると、 のスタックの詳細ページにリダイレクトされます AWS CloudFormation。
+ **[リソースタイプ]** - リソースタイプを示します。
+ **アカウント** – 物理リソースを所有する AWS アカウントを示します。
+ **[リージョン]** – リソースがある AWS リージョンを示します。
**RTO**
アプリケーションが障害耐性ポリシーの目標を満たす見込みがあるかどうかをグラフィカルに表示します。これは、組織に重大な損害を与えることなく、アプリケーションが停止できる時間に基づくものです。この評価により、推定ワークロードの RTO が算出されます。
**RPO**
アプリケーションが障害耐性ポリシーの目標を満たす見込みがあるかどうかをグラフィカルに表示します。これは、ビジネスに重大な損害が発生する前に、データが失われる可能性のある時間に基づくものです。この評価により、ワークロードの推定 RPO が算出されます。
**詳細**
**[すべての結果]** タブと **[アプリケーションコンプライアンスドリフト]** タブに、各中断タイプの詳細な説明が表示されます。**[すべての結果]** タブにはコンプライアンスドリフトを含むすべての中断が表示され、**[アプリケーションコンプライアンスドリフト]** タブにはコンプライアンスドリフトのみが表示されます。中断タイプには、**[アプリケーション]**、クラウドインフラストラクチャ (**[インフラストラクチャ]** と **[アベイラビリティーゾーン**])、**[リージョン]** があり、それらに関する以下の情報が表示されます。
+ **AppComponent**
アプリケーションを構成するリソース。例えば、アプリケーションにはデータベースやコンピュートコンポーネントが含まれる場合があります。
+ **推定 RTO**
ポリシー設定がポリシー要件と一致しているかどうかを示します。**[推定 RTO]** と **[目標 RTO]** の 2 つの値が提供されます。例えば、**[目標 RTO]** に **[2 時間]**、**[推定ワークロード RTO]** に **[40 分]** という値が表示されている場合は、アプリケーションの現在の RTO が 2 時間であるのに対し、ワークロードの見積もり RTO は 40 分であることがわかります。推定ワークロード RTO の計算は、ポリシーではなく構成に基づいて行われます。その結果、選択したポリシーに関係なく、複数のアベイラビリティーゾーンのデータベースでは、アベイラビリティーゾーンの障害に対する推定ワークロード RTO は同じになります。
+ **RTO ドリフト**
前回の評価が成功した場合の推定ワークロード RTO からアプリケーションがずれている期間を示します。**[推定 RTO]** と **[RTO ドリフト]** という 2 つの値を提供しています。例えば、**[推定 RTO]** に **[2 時間]**、**[RTO ドリフト]**に **[40 分]** という値が表示される場合、アプリケーションが前回成功した評価の推定ワークロード RTO から 40 分ずれていることがわかります。
+ **推定 RPO**
各アプリケーションコンポーネントに設定した **[目標 RPO]** ポリシーに基づいて、 AWS Resilience Hub が推定した実際の **[推定ワークロード RPO]** ポリシーを表示します。例えば、アベイラビリティーゾーンの障害に対する障害耐性ポリシーの RPO 目標を 1 時間に設定したとします。推定結果はほぼゼロと計算される可能性があります。これは、すべてのトランザクションをコミットする Amazon Aurora が、複数のアベイラビリティーゾーンにまたがる 6 つのノードのうち 4 つで成功することを前提としています。ポイントインタイム復元には 5 分かかる場合があります。
指定しないで選択できる RTO と RPO の目標はリージョンだけです。一部のアプリケーションでは、AWS サービスに重大な依存関係があり、リージョン全体で使用できなくなる可能性がある場合に、復旧計画を立てておくと便利です。
リージョンの RTO や RPO の目標を設定するなど、このオプションを選択すると、そのような障害に対する推定復旧時間と運用上の推奨事項が表示されます。
+ **RPO ドリフト**
前回の評価で予測されたワークロードの RPO から、アプリケーションがどの程度ずれているかを示します。**[推定 RPO]** と **[RPO ドリフト]** という 2 つの値を提供しています。例えば、**[推定 RTO]** に **[2 時間]**、**[RTO ドリフト]** に **[40 分]** という値が表示される場合、アプリケーションが前回成功した評価の推定ワークロード RTO から 40 分ずれていることがわかります。
# 障害耐性に関する推奨事項の確認
障害耐性に関する推奨事項では、アプリケーションコンポーネントを評価し、推定ワークロードの RTO と推定ワークロードの RPO、コスト、最小限の変更によって最適化する方法を推奨しています。
では AWS Resilience Hub、**「このオプションを選択すべき理由**」の以下の推奨オプションのいずれかを使用して回復性を最適化できます。
**注記**
AWS Resilience Hub には、最大 3 つの AWS Resilience Hub 推奨オプションが用意されています。
リージョン RTO および RPO ターゲットを設定すると、 は推奨されるオプションに**リージョン RTO/RPO の最適化** AWS Resilience Hub を表示します。リージョン RTO および RPO ターゲットが設定されていない場合は、**Optimize for Availability Zone (AZ) RTO/RPO** が表示されます。障害耐性ポリシーの作成中にリージョン RTO/RPO ターゲットを設定する方法の詳細については、「」を参照してください[障害耐性ポリシーの作成](create-policy.md)。
アプリケーションとその構成の推定ワークロード RTO と推定ワークロード RPO 値は、データ量と個々の AppComponents を考慮して決定されます。ただし、これらの値は推定値にすぎません。アプリケーションの実際の復旧時間をテストするには、独自のテスト ( など AWS Fault Injection Service) を使用する必要があります。
**アベイラビリティーゾーン RTO/RPO に最適化する**
アベイラビリティーゾーン (AZ) の中断中の推定ワークロード復旧時間 (RTO/RPO) の最小値。RTO および RPO の目標を達成するために設定を十分に変更できない場合、ポリシーを満たす可能性に近づけるために、推定されるワークロード AZ 復旧時間の最小値が通知されます。
**リージョン RTO/RPO に最適化する**
リージョンの中断時の推定ワークロード復旧時間 (RTO/RPO) の最小値。RTO および RPO の目標を達成するために設定を十分に変更できない場合は、ポリシーを満たす可能性に近づけるために、ワークロードリージョンの推定復旧時間が最も短いことが通知されます。
**コストに合わせた最適化**
発生する可能性のある最低コストで、回復性ポリシーを満たします。最適化目標を達成するために設定を十分に変更できない場合は、設定がポリシーを満たす可能性に近づくために発生する可能性のある最低コストについて通知されます。
**最小化変更の最適化**
ポリシー目標を達成するために必要な最小限の変更。最適化目標を達成するために設定を十分に変更できない場合は、ポリシーを満たす可能性に近い設定に推奨される変更について通知されます。
最適化カテゴリの内訳には以下の項目が含まれます。
+ **説明**
によって提案される設定について説明します AWS Resilience Hub。
+ **変更**
推奨構成に切り替えるために必要なタスクを説明するためのテキスト変更リスト。
+ **基本コスト**
推奨される変更に関連する推定コスト。
**注記**
**基本コスト**は使用量によって異なり、エンタープライズ割引プログラム (EDP) の割引やオファーは含まれません。
+ **推定ワークロード RTO と RPO**
変更後の推定ワークロード RTO と推定ワークロード RPO。
AWS Resilience Hub は、アプリケーションコンポーネント (AppComponent) が障害耐性ポリシーに準拠できるかどうかを評価します。AppComponent が障害耐性ポリシーに準拠しておらず、AWS Resilience Hub がコンプライアンスを容易にするための推奨事項を作成できない場合、選択した AppComponent の復旧時間を AppComponent の制約内で満たすことができない可能性があります AppComponent 。AppComponent 制約の例としては、リソースタイプ、ストレージサイズ、リソース設定などがあります。
AppComponent の障害耐性ポリシーへの準拠を容易にするには、AppComponent のリソースタイプを変更するか、リソースが提供できる内容に合わせて障害耐性ポリシーを更新します。
# 運用上の推奨事項のレビュー
運用上の推奨事項には、 AWS CloudFormation テンプレートを使用してアラーム、SOPs、 AWS FIS 実験を設定するための推奨事項が含まれています。
AWS Resilience Hub には、アプリケーションのインフラストラクチャをコードとしてダウンロードおよび管理するための AWS CloudFormation テンプレートファイルが用意されています。そのため、アプリケーションコードに追加できるように、 AWS CloudFormation で推奨事項が提供されます。 AWS CloudFormation テンプレートファイルのサイズが 1 MB 以上で、500 を超えるリソースが含まれている場合、 は、各ファイルのサイズが 1 MB 以下で、最大 500 個のリソースが含まれている複数の AWS CloudFormation テンプレートファイル AWS Resilience Hub を生成します。テンプレートファイルが複数のファイルに分割されている場合 AWS CloudFormation 、 AWS CloudFormation テンプレートファイル名に が追加されます。ここで、 はシーケンス内のファイル番号`X`を示し`partXofY`、 はテンプレートファイルが分割された AWS CloudFormation ファイルの合計数`Y`を示します。例えば、テンプレートファイル `big-app-template5-Alarm-104849185070-us-west-2.yaml` が 4 つのファイルに分割されている場合、ファイル名は次のようになります。
+ `big-app-template5-Alarm-104849185070-us-west-2-part1of4.yaml`
+ `big-app-template5-Alarm-104849185070-us-west-2-part2of4.yaml`
+ `big-app-template5-Alarm-104849185070-us-west-2-part3of4.yaml`
+ `big-app-template5-Alarm-104849185070-us-west-2-part4of4.yaml`
ただし、大きな AWS CloudFormation テンプレートの場合は、ローカルファイルを入力として CLI/API を使用する代わりに、Amazon Simple Storage Service URI を指定する必要があります。
では AWS Resilience Hub、次のアクションを実行できます。
+ 選択したアラーム、SOPs、および AWS FIS 実験をプロビジョニングできます。アラーム、SOPs、 AWS FIS 実験をプロビジョニングするには、適切なレコメンデーションを選択し、一意の名前を入力します。 は、選択したレコメンデーションに基づいてテンプレート AWS Resilience Hub を作成します。**[テンプレート]** では、Amazon Simple Storage Service (Amazon S3) URL を通じて作成したテンプレートにアクセスできます。
+ 選択したアラーム、SOPs、およびアプリケーションに推奨された AWS FIS 実験を任意の時点で含めたり除外したりできます。詳細については、[運用上の推奨事項を含めるまたは除外する](exclude-recommend.md) を参照してください。
+ また、アプリケーションのタグを検索、作成、追加、削除、管理して、そのアプリケーションに関連するすべてのタグを確認することもできます。
# 運用上の推奨事項を含めるまたは除外する
AWS Resilience Hub には、アプリケーションの耐障害性スコアを向上させるために推奨されるアラーム、SOPs、および AWS FIS 実験 (テスト) を任意の時点で含めたり除外したりするためのオプションが用意されています。運用上のレコメンデーションの包含と除外は、新しい評価を実行した後にのみ、アプリケーションの耐障害性スコアに影響します。したがって、評価を実行して、更新された障害耐性スコアを取得し、アプリケーションへの影響を把握することをお勧めします。
アプリケーションごとに推奨事項を含めたり除外したりするためのアクセス許可の制限の詳細については、[AWS Resilience Hub レコメンデーションを含めるか除外するアクセス許可を制限する](include-exclude-limit-permissions.md) を参照してください。
**運用上の推奨事項をアプリケーションに含めたり除外したりするには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** で、アプリケーションを選択します。
1. **[評価]** を選択し、**[障害耐性評価]** 表から評価を選択します。評価を受けていない場合は、[での障害耐性評価の実行 AWS Resilience Hub](run-assessment.md) の手順を完了してからこのステップに戻ってください。
1. **[運用上の推奨事項]** タブを選択します。
1. 運用上の推奨事項をアプリケーションに含める、またはアプリケーションから除外するには、以下のステップを実行します。
**推奨アラームをアプリケーションに含めたり除外したりするには**
1. アラームを除外するには、以下のステップを実行します。
1. **[アラーム]** タブの **[アラーム]** テーブルから、除外するアラーム (**[未実装]** ステータス) をすべて選択します。アラームの現在の実装状況は、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を除外]** を選択します。
1. **[推奨項目を除外]** ダイアログから、以下のいずれかの理由 (オプション) を選択し、**[選択項目を除外]** を選択すると、選択したアラームがアプリケーションから除外されます。
+ **既に実装**済み – Amazon CloudWatch などの AWS サービスや他のサードパーティーサービスプロバイダーでこれらのアラームを既に実装している場合は、このオプションを選択します。
+ **[該当なし]** — アラームがビジネス要件に合わない場合は、このオプションを選択してください。
+ **[実装が複雑すぎる]** — アラームが複雑すぎて実装できないと思われる場合は、このオプションを選択してください。
+ **[その他]** — 推奨項目を除外するその他の理由を指定する場合は、このオプションを選択してください。
1. アラームを含めるには、次のステップを実行します。
1. **[アラーム]** タブの **[アラーム]** テーブルから、含めたいアラーム (**[除外]** ステータス) をすべて選択します。アラームの現在の実装状況は、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を含める]** を選択します。
1. **[推奨項目を含める]** ダイアログで **[選択項目を含める]** を選択すると、選択したすべてのアラームがアプリケーションに含められます。
**推奨標準作業手順 (SOP) をアプリケーションに含めたり除外したりするには**
1. 推奨 SOP を除外するには、以下のステップを実行します。
1. **[標準作業手順]** タブの **[SOP]** テーブルから、除外するすべての SOP (**[実施済み]** または **[未実装]**) を選択します。SOP の現在の実施ステータスは、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を除外]** を選択し、選択した SOP をアプリケーションから除外します。
1. **[推奨項目を除外]** ダイアログから、以下のいずれかの理由 (オプション) を選択し、**[選択項目を除外]** を選択して、選択した SOP をアプリケーションから除外します。
+ **[既に実装済み]** — これらの SOP を AWS サービスまたは他のサードパーティのサービスプロバイダーですでに実装している場合は、このオプションを選択してください。
+ **[該当なし]** — SOP がビジネス要件に合わない場合は、このオプションを選択してください。
+ **[実装が複雑すぎる]** — これらの SOP が複雑すぎて実装できないと思われる場合は、このオプションを選択してください。
+ **[なし]** — 理由を指定しない場合は、このオプションを選択してください。
1. SOP を含めるには、次のステップを実行します。
1. **[標準作業手順書]** タブの **[SOP]** テーブルから、含めたいアラーム (**[除外]** ステータス) をすべて選択します。アラームの現在の実装状況は、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を含める]** を選択します。
1. **[レコメンデーションを含める]** ダイアログで **[選択したものを含める]** を選択すると、選択したすべての SOP がアプリケーションに含められます。
**推奨テストをアプリケーションに含めたり除外したりするには**
1. 推奨テストを除外するには、以下のステップを実行します。
1. **[故障注入実験テンプレート]** タブの **[故障注入実験テンプレート]** テーブルから、除外したいテスト (**[実装済み]** または **[未実装]** ステータス) をすべて選択します。テストの現在の実装状況は、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を除外]** を選択します。
1. **[推奨項目を除外]** ダイアログから、以下のいずれかの理由 (オプション) を選択し、**[選択項目を除外]** を選択すると、選択した AWS FIS 実験がアプリケーションから除外されます。
+ **既に実装**済み – AWS サービスまたは他のサードパーティーサービスプロバイダーでこれらのテストを既に実装している場合は、このオプションを選択します。
+ **[該当なし]** — テストがビジネス要件に合わない場合は、このオプションを選択してください。
+ **[実装が複雑すぎる]** — テストが複雑すぎて実装できないと思われる場合は、このオプションを選択してください。
+ **[なし]** — 理由を指定しない場合は、このオプションを選択してください。
1. 推奨テストを含めるには、以下のステップを実行します。
1. **[故障注入実験テンプレート]** タブの **[故障注入実験テンプレート]** テーブルから、含めたいテスト (**[除外]** ステータス) をすべて選択します。テストの現在の実装状況は、**[ステータス]** 列で確認できます。
1. **[アクション]** から **[選択項目を含める]** を選択します。
1. **[推奨項目を含める]** ダイアログから **[選択したものを含める]** を選択すると、選択したすべてのテストがアプリケーションに含められます。
# 障害耐性評価の削除
アプリケーションの **[評価]** ビューで障害耐性評価を削除できます。
**障害耐性評価を削除するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** で、アプリケーションを選択します。
1. **[評価]** で、**[障害耐性評価]** 表から評価レポートを選択します。
1. 削除を確認するには、**[削除]** を選択します。
レポートは **[障害耐性評価]** 表に表示されなくなります。
# 障害耐性ウィジェットからの障害耐性評価の実行と管理
AWS Resilience Hub を使用すると、回復性ウィジェットの myApplications で作成および管理されるアプリケーションの評価を実行できます。アプリケーションに変更を加えるたびに、障害耐性ウィジェットまたは AWS Resilience Hub コンソールから障害耐性評価を実行することをお勧めします。この評価中、各アプリケーションコンポーネントの設定は、確立されたポリシーとベストプラクティスに照らして評価されます。この評価に基づいて、評価はアラームの設定、標準運用手順 (SOPs) の作成、テスト戦略の実装に関する推奨事項を生成します。これらの設定レコメンデーションを実装すると、復旧手順の速度と効率が向上し、インシデント対応が迅速になり、潜在的なダウンタイムを最小限に抑えることができます。
アラームの推奨事項は、停止を検出するアラームの設定に役立ちます。SOP の推奨事項には、バックアップからの復旧など、一般的な復旧プロセスを管理するスクリプトが用意されています。テスト推奨事項には、構成が正しく動作していることを確認するための提案が記載されています。例えば、ネットワークの問題による自動スケーリングや負荷分散などの自動復旧中にアプリケーションが復旧するかどうかをテストできます。また、リソースが上限に達したときにアプリケーションアラームがトリガーされるかどうか、指定した条件下で SOP がどの程度機能するかについても、テストできます。
**Topics**
+ [障害耐性ウィジェットからの障害耐性評価の実行](run-assessment-resiliency-widget.md)
+ [レジリエンシーウィジェットでの評価の概要の確認](review-assessment-resliency-widget.md)
# 障害耐性ウィジェットからの障害耐性評価の実行
**myApplications** ウィジェットで作成されたアプリケーションでは、障害耐性ウィジェットと AWS Resilience Hub コンソールから**障害耐性**評価を実行できるようになりました。コンソールから AWS Resilience Hub 障害耐性評価を実行する方法の詳細については、「」を参照してください[での障害耐性評価の実行 AWS Resilience Hub](run-assessment.md)。
**障害耐性ウィジェットから既存の **myApplications** **アプリケーションの障害耐性**評価を初めて実行するには**
1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)にサインインします。
1. 左側のサイドバーを展開し、**[myApplications]** を選択します。
1. 評価を実行するアプリケーションを選択します。
前提条件として、 AWS コンソールに**障害耐性**ウィジェットを追加していることを確認します。このウィジェットを追加するには、次の手順を実行します。
1. **コンソールホーム**ダッシュボードの右上または右下で、**\$1ウィジェットの追加**を選択します。
1. ウィジェットのタイトルバーの左上にある 6 つの縦のドットで表される**ドラッグインジケータ**を選択し、**コンソールホーム**ダッシュボードにドラッグします。
1. **アプリケーションの評価**を選択します。
1. 現在のアカウントのリソースへのアクセスに使用される既存の IAM ロールを選択するには、**IAM ロール**の使用を選択し、IAM ロール**の選択ドロップダウンリストから IAM ロール**を選択します。
現在の IAM ユーザーを使用してアプリケーションリソースを検出する場合は、**「現在の IAM ユーザーアクセス許可を使用する**」を選択し、**「現在の IAM ユーザーを使用してアプリケーションリソースを検出する**」セクションの **で必要な機能を有効にするアクセス許可を手動で設定する必要があることを理解 AWS Resilience Hub**します。
1. **評価** を選択します。
または、**Automatic assess daily** をオンにして、 AWS Resilience Hub が追加コストなしでアプリケーションを毎日評価できるようにします。
AWS Resilience Hub は次のアクションを実行します。
+ でアプリケーションを作成し AWS Resilience Hub 、関連するリソースを自動的に検出してマッピングします。
+ 目標復旧時間 (RTO) と目標復旧時点 (RPO) の値があらかじめ定義されている新しい耐障害性ポリシーを作成して割り当てます。つまり、RTO は 4 時間、RPO は 1 時間です。評価を生成したら、障害耐性ポリシーを変更するか、 AWS Resilience Hub コンソールから別のポリシーを割り当てることができます。耐障害性ポリシーのアップデートと別のポリシーのアタッチについて詳しくは、「[障害耐性ポリシーの管理](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html?icmpid=docs_resiliencehub_help_panel_resiliency_policies)」を参照してください。
+ RTO と RPO に対するアプリケーションの耐障害性を評価し、リソースと構成の変更を継続的に監視し、結果を公開します。
**注記**
評価を開始する前に、 AWS Resilience Hubを使用して評価を実行する際に発生する可能性があるコストを評価することをお勧めします。料金の詳細については、「 [AWS Resilience Hub の料金](https://aws.amazon.com//resilience-hub/pricing?icmpid=docs_resiliencehub_help_panel_resiliency_policies_hp)」を参照してください。
**障害耐性ウィジェットから既存の **myApplications** アプリケーションの**障害耐性**評価を再実行するには**
1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)にサインインします。
1. 左側のサイドバーを展開し、**[myApplications]** を選択します。
1. 再評価するアプリケーションを選択します。
前提条件として、 AWS コンソールに**障害耐性**ウィジェットを追加していることを確認します。このウィジェットを追加するには、次の手順を実行します。
1. **コンソールホーム**ダッシュボードの右上または右下で、**\$1ウィジェットの追加**を選択します。
1. ウィジェットのタイトルバーの左上にある 6 つの縦のドットで表される**ドラッグインジケータ**を選択し、**コンソールホーム**ダッシュボードにドラッグします。
1. **レジリエン**シーウィジェットから**再評価**を選択します。
または、**Automatic assess daily** をオンにして、 AWS Resilience Hub が追加コストなしでアプリケーションを毎日評価できるようにします。
# レジリエンシーウィジェットでの評価の概要の確認
**レジリエンシー**ウィジェットには、myApplications アプリケーションのレジリエンス、潜在的な脆弱性、主要業績評価指標 (KPIs)、改善のための推奨アクションに関する最も重要で実用的なインサイトを提供する評価結果のスナップショットが表示されます。以下を使用して、最新の評価からアプリケーションの耐障害性体制について詳しく知ることができます。
+ **[耐障害性スコア履歴]** – このグラフには、最大 1 年間のアプリケーションの耐障害性スコアの傾向が表示されます。
+ **[耐障害性スコア]** – 最新の評価で評価されたアプリケーションの耐障害性スコアを示します。このスコアは、アプリケーションがアプリケーションの障害耐性ポリシーを満たし、アラーム、標準運用手順 (SOPs)、 AWS Fault Injection Service および (AWS FIS) 実験を実装するための推奨事項にどの程度準拠しているかを反映しています。 AWS Resilience Hub コンソールの **概要**タブの**「障害耐性スコア**」セクションで追加情報を表示する番号を選択します。詳細については、「[評価レポート](review-assessment.md#review-section)」を参照してください。
+ **ポリシー違反** – 以下の番号を選択すると、アプリケーションにアタッチされたポリシーに違反するすべてのアプリケーションコンポーネント (AppComponents) が AWS Resilience Hub コンソール**の評価レポート**ペインに表示されます。詳細については、「[評価レポート](review-assessment.md#review-section)」を参照してください。
+ **[ポリシーのドリフト]** – 前回の評価ではポリシーに準拠していたが、現在の評価では準拠しなかった AppComponents を示します。以下の番号を選択すると、 AWS Resilience Hub コンソール**の評価レポート**ペインに AppComponents が表示されます。詳細については、「[評価レポート](review-assessment.md#review-section)」を参照してください。
+ **リソースドリフト** – コンソール**の評価レポート**ペインで、最新の評価からドリフトしたすべてのリソースを表示するには、以下の数値を選択します AWS Resilience Hub 。詳細については、「[評価レポート](review-assessment.md#review-section)」を参照してください。
+ **Resilience Hub に移動 ** – AWS Resilience Hub コンソールでアプリケーションを開くには、このオプションを選択します。
# アラームの管理
運用上の推奨事項の一環として、障害耐性評価を実行する場合、 AWS Resilience Hub は Amazon CloudWatch アラームを設定してアプリケーションの障害耐性をモニタリングすることを推奨しています。これらのアラームは、現在のアプリケーション設定のリソースとコンポーネントに基づいて推奨されます。アプリケーションのリソースとコンポーネントが変更された場合は、障害耐性評価を実行して、更新されたアプリケーションに適した Amazon CloudWatch アラームがあることを確認する必要があります。
さらに、 AWS Resilience Hub は、既に設定された Amazon CloudWatch アラームを自動的に検出して耐障害性評価に統合し、アプリケーションの耐障害性体制をより包括的に把握できるようになりました。この新機能は、レ AWS Resilience Hub コメンデーションを現在のモニタリング設定と組み合わせ、アラーム管理を合理化し、評価の精度を向上させます。Amazon CloudWatch アラームを実装していて、自動的に検出 AWS Resilience Hub されない場合は、アラームを除外し、その理由を**既に実装済み**として選択できます。レコメンデーションの除外の詳細については、「」を参照してください[運用上の推奨事項を含めるまたは除外する](exclude-recommend.md)。
AWS Resilience Hub には、 AWS Resilience Hub の内部 (Amazon CloudWatch など`README.md`) または外部で推奨されるアラームを作成できるテンプレートファイル AWS () が用意されています AWS。アラームで提供されるデフォルト値は、これらのアラームの作成に使用されるベストプラクティスに基づいています。
**Topics**
+ [運用上の推奨事項からのアラームの作成](create-alarm.md)
+ [アラームを表示する](view-alarm.md)
# 運用上の推奨事項からのアラームの作成
AWS Resilience Hub は、Amazon CloudWatch で選択したアラームを作成するための詳細を含む CloudFormation テンプレートを作成します。テンプレートが生成されたら、Amazon S3 のURL を介してテンプレートにアクセスし、ダウンロードしてコードパイプラインに配置するか、 CloudFormation コンソールからスタックを作成できます。
AWS Resilience Hub 推奨事項に基づいてアラームを作成するには、推奨アラームのテンプレートを作成し CloudFormation 、コードベースに含める必要があります。
**運用上の推奨事項にアラームを作成するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **アプリケーション**で、アプリケーションを選択します。
1. **[評価]** タブを選択します。
**[障害耐性評価]** 表では、以下の情報を使用して評価を特定できます。
+ **[名前]** – 作成時に提供した評価の名前。
+ **[ステータス]** – 評価の実行状態を示します。
+ **[コンプライアンスステータス]** – 評価が障害耐性ポリシーに準拠しているかどうかを示します。
+ **[障害耐性ドリフトステータス]** – アプリケーションが前回の成功した評価から逸脱したかどうかを示します。
+ **[アプリバージョン]** – アプリケーションのバージョン。
+ **[呼び出した人]** – 評価を呼び出したロールを示します。
+ **[開始時刻]** – 評価の開始時刻を示します。
+ **[終了時刻]** – 評価の終了時刻を示します。
+ **[ARN]** - 評価の Amazon リソースネーム (ARN)。
1. **[障害耐性評価]** 表から評価を選択します。評価を受けていない場合は、[での障害耐性評価の実行 AWS Resilience Hub](run-assessment.md) の手順を完了してからこのステップに戻ってください。
1. **[運用上の推奨事項]** を選択します。
1. デフォルトで選択されていない場合は、**[アラーム]** タブを選択します。
**[アラーム]** テーブルでは、以下を使用して推奨アラームを識別できます。
+ **[名前]** – アプリケーションに設定したアラームの名前。
+ **[説明]** – アラームの目的を説明します。
+ **[状態]** – Amazon CloudWatch アラームの現在の実装状態を示します。
この列には、次のいずれかの値が表示されます。
+ **実装済み** – が推奨するアラーム AWS Resilience Hub がアプリケーションに実装されていることを示します。以下の番号を選択すると、**[アラーム]** テーブルがフィルタリングされ、アプリケーションに実装されている推奨アラームがすべて表示されます。
+ **実装されていない** – が推奨するアラーム AWS Resilience Hub は含まれているが、アプリケーションには実装されていないことを示します。以下の番号を選択すると、**[アラーム]** テーブルがフィルタリングされ、アプリケーションに実装されていない推奨アラームがすべて表示されます。
+ **除外** – が推奨するアラーム AWS Resilience Hub がアプリケーションから除外されていることを示します。以下の番号を選択すると、**[アラーム]** テーブルがフィルタリングされ、アプリケーションから除外されている推奨アラームがすべて表示されます。推奨アラームを含めるか除外するかについて詳しくは、「[運用上の推奨事項を含める/除外する](https://docs.aws.amazon.com/resilience-hub/latest/userguide/exclude-recommend.html?icmpid=docs_resiliencehub_help_panel_operational_recommendations_alarms)」を参照してください。
+ **[非アクティブ]** – アラームは Amazon CloudWatch にデプロイされているが、Amazon CloudWatch ではステータスが **[INSUFFICIENT\$1DATA]** に設定されていることを示します。以下の番号を選択すると、**[アラーム]** テーブルがフィルタリングされ、実装済みのアラームと非アクティブなアラームがすべて表示されます。
+ **[構成]** – 対処する必要のある保留中の構成の依存関係があるかどうかを示します。
+ **[タイプ]** – アラームの種類を示します。
+ **[AppComponent]** – このアラームに関連するアプリケーションコンポーネント (AppComponents) を示します。
+ **リファレンス ID** – AWS CloudFormation スタックイベントの論理識別子を示します AWS CloudFormation。
+ **レコメンデーション ID** – AWS CloudFormation スタックリソースの論理識別子を示します AWS CloudFormation。
1. **[アラーム]** タブで、**[アラーム]** テーブル内のアラーム推奨事項を特定の状態に基づいてフィルタリングするには、その下にある番号を選択します。
1. アプリケーションに設定したい推奨アラームを選択し、**[CloudFormation テンプレートの作成]** を選択します。
1. **CloudFormation テンプレートの作成**ダイアログでは、自動生成された名前を使用するか、CloudFormation CloudFormation テンプレート名ボックスにテンプレートの名前を入力できます。 **CloudFormation **
1. **[作成]** を選択します。 AWS CloudFormation テンプレートの作成には数分かかる場合があります。
コードベースに推奨事項を含めるには、以下の手順を実行します。
**コードベースに AWS Resilience Hub レコメンデーションを含めるには**
1. **[テンプレート]** タブを選択すると、作成したテンプレートが表示されます。テンプレートを特定するには、以下を使用します。
+ **[名前]** – 作成時に提供した評価の名前。
+ **[ステータス]** – 評価の実行状態を示します。
+ **[タイプ]** – 運用上の推奨事項の種類を示します。
+ **[フォーマット]** – テンプレートが作成されるフォーマット (JSON/テキスト) を示します。
+ **[開始時刻]** – 評価の開始時刻を示します。
+ **[終了時刻]** – 評価の終了時刻を示します。
+ **ARN** – テンプレートの ARN
1. **[テンプレートの詳細]** で、**[テンプレート S3 パス]** の下のリンクを選択し、Amazon S3 コンソールでテンプレートオブジェクトを開きます。
1. Amazon S3 コンソールの **Objects** テーブルから、Alarms フォルダのリンクを選択します。
1. Amazon S3 のパスをコピーするには、JSON ファイルの前にあるチェックボックスを選択し、**[URL をコピー]** を選択します。
1. AWS CloudFormation コンソールから AWS CloudFormation スタックを作成します。 AWS CloudFormation スタックの作成の詳細については、「」を参照してください[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)。
AWS CloudFormation スタックの作成時に、前のステップからコピーした Amazon S3 パスを指定する必要があります。
# アラームを表示する
アプリケーションの耐障害性をモニタリングするために設定したすべてのアクティブなアラームを表示できます。 は CloudFormation テンプレート AWS Resilience Hub を使用して、Amazon CloudWatch でアラームを作成するために使用されるアラームの詳細を保存します。Amazon S3 URL を使用して CloudFormation テンプレートにアクセスし、ダウンロードしてコードパイプラインに配置するか、 CloudFormation コンソールからスタックを作成できます。
ダッシュボードからアラームを表示するには、左側のナビゲーションメニューから **[ダッシュボード]** を選択します。**実装済みアラーム**テーブルでは、次の情報を使用して実装済みアラームを特定できます。
+ **[影響を受けるアプリケーション]** – このアラームを実装したアプリケーションの名前。
+ **[アクティブアラーム]** – アプリケーションからトリガーされたアクティブなアラームの数を示します。
+ **進行中の FIS** – アプリケーションで現在実行されている AWS FIS 実験を示します。
**アプリケーションに実装されているアラームを表示するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** テーブルからアプリケーションを選択します。
1. アプリケーション概要ページの **[実装済みアラーム]** テーブルには、アプリケーションに実装されている推奨アラームがすべて表示されます。
**[実装済みアラーム]** テーブルで特定のアラームを検索するには、**[テキスト、プロパティ、または値でアラームを検索]** ボックスで、次のいずれかのフィールドを選択し、操作を選択して、値を入力します。
+ **[アラーム名]** – アプリケーションに設定したアラームの名前。
+ **[説明]** – アラームの目的を説明します。
+ **[状態]** – Amazon CloudWatch アラームの現在の実装状態を示します。
この列には、次のいずれかの値が表示されます。
+ **実装済み** – が推奨するアラーム AWS Resilience Hub がアプリケーションに実装されていることを示します。以下の番号を選択すると、**[運用上の推奨事項]** タブに推奨アラームと実装済みアラームがすべて表示されます。
+ **実装されていない** – が推奨するアラーム AWS Resilience Hub は含まれているが、アプリケーションには実装されていないことを示します。以下の番号を選択すると、**[運用上の推奨事項]** タブに推奨されているアラームと実装されていないアラームがすべて表示されます。
+ **除外** – が推奨するアラーム AWS Resilience Hub がアプリケーションから除外されていることを示します。以下の番号を選択すると、**[運用上の推奨事項]** タブに推奨アラームと除外アラームがすべて表示されます。推奨アラームを含めるか除外するかについて詳しくは、「[運用上の推奨事項を含める/除外する](https://docs.aws.amazon.com/resilience-hub/latest/userguide/exclude-recommend.html?icmpid=docs_resiliencehub_help_panel_operational_recommendations_alarms)」を参照してください。
+ **[非アクティブ]** – アラームは Amazon CloudWatch にデプロイされているが、Amazon CloudWatch ではステータスが **[INSUFFICIENT\$1DATA]** に設定されていることを示します。以下の番号を選択すると、**[運用上の推奨事項]** タブに実装済みのアラームと非アクティブなアラームがすべて表示されます。
+ **ソーステンプレート** – アラームの詳細を含む AWS CloudFormation スタックの Amazon リソースネーム (ARN) を提供します。
+ **[リソース]** – このアラームがアタッチされ、かつ実装されたリソースを表示します。
+ **[メトリクス]** – アラームに割り当てられた Amazon CloudWatch メトリクスを表示します。Amazon CloudWatch メトリクスの詳細については、「[Amazon CloudWatch メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Metric)」を参照してください。
+ **[最終変更]** – アラームが最後に変更された日付と時刻が表示されます。
**評価から推奨されるアラームを確認するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** テーブルからアプリケーションを選択します。
アプリケーションを検索するには、**[アプリケーションを検索]** ボックスにアプリケーション名を入力します。
1. **[評価]** タブを選択します。
**[障害耐性評価]** 表では、以下の情報を使用して評価を特定できます。
+ **[名前]** – 作成時に提供した評価の名前。
+ **[ステータス]** – 評価の実行状態を示します。
+ **[コンプライアンスステータス]** – 評価が障害耐性ポリシーに準拠しているかどうかを示します。
+ **[障害耐性ドリフトステータス]** – アプリケーションが前回の成功した評価から逸脱したかどうかを示します。
+ **[アプリバージョン]** – アプリケーションのバージョン。
+ **[呼び出した人]** – 評価を呼び出したロールを示します。
+ **[開始時刻]** – 評価の開始時刻を示します。
+ **[終了時刻]** – 評価の終了時刻を示します。
+ **[ARN]** - 評価の Amazon リソースネーム (ARN)。
1. **[障害耐性評価]** 表から評価を選択します。
1. **[運用上の推奨事項]** タブを選択します。
1. デフォルトで選択されていない場合は、**[アラーム]** タブを選択します。
**[アラーム]** テーブルでは、以下を使用して推奨アラームを識別できます。
+ **[名前]** – アプリケーションに設定したアラームの名前。
+ **[説明]** – アラームの目的を説明します。
+ **[状態]** – Amazon CloudWatch アラームの現在の実装状態を示します。
この列には、次のいずれかの値が表示されます。
+ **[実装済み]** – アラームがアプリケーションに実装されていることを示します。以下の番号を選択すると、**[アラーム]** テーブルがフィルタリングされ、アプリケーションに実装されている推奨アラームがすべて表示されます。
+ **[未実装]** – アラームがアプリケーションに実装されていないか、含まれていないことを示します。以下の番号を選択すると、**[アラーム]** テーブルがフィルタリングされ、アプリケーションに実装されていない推奨アラームがすべて表示されます。
+ **[除外]** – アラームがアプリケーションから除外されていることを示します。以下の番号を選択すると、**[アラーム]** テーブルがフィルタリングされ、アプリケーションから除外されている推奨アラームがすべて表示されます。推奨アラームを含める/除外する方法の詳細については、「[運用上の推奨事項を含めるまたは除外する](exclude-recommend.md)」を参照してください。
+ **[非アクティブ]** – アラームは Amazon CloudWatch にデプロイされているが、Amazon CloudWatch ではステータスが **[INSUFFICIENT\$1DATA]** に設定されていることを示します。以下の番号を選択すると、**[アラーム]** テーブルがフィルタリングされ、実装済みのアラームと非アクティブなアラームがすべて表示されます。
+ **[構成]** – 対処する必要のある保留中の構成の依存関係があるかどうかを示します。
+ **[タイプ]** – アラームの種類を示します。
+ **[AppComponent]** – このアラームに関連するアプリケーションコンポーネント (AppComponents) を示します。
+ **リファレンス ID** – AWS CloudFormation スタックイベントの論理識別子を示します AWS CloudFormation。
+ **レコメンデーション ID** – AWS CloudFormation スタックリソースの論理識別子を示します AWS CloudFormation。
# 標準運用手順の管理
標準運用手順 (SOP) は、システム停止やアラームが発生した場合にアプリケーションを効率的に復旧するための規範的な一連の手順です。運用上の障害が発生した場合にタイムリーに復旧できるように、SOP を事前に準備、テスト、測定します。
アプリケーションコンポーネントに基づいて、 AWS Resilience Hub は準備すべき SOPs を推奨します。 AWS Resilience Hub は Systems Manager と連携して、SOPs の基礎として使用できる多数の SSM ドキュメントを提供することで、SOPs。
たとえば、既存の SSM Automation ドキュメントに基づいてディスク容量を追加するための SOP を推奨 AWS Resilience Hub できます。この SSM ドキュメントを実行するには、正しいアクセス許可を持つ特定の IAM ロールが必要です。 は、ディスクが不足した場合に実行する SSM オートメーションドキュメントと、その SSM ドキュメントを実行するために必要な IAM ロールを示すメタデータをアプリケーションに AWS Resilience Hub 作成します。その後、このメタデータは SSM パラメータに保存されます。
SSM 自動化を設定することに加えて、 AWS FIS の実験を行ってテストすることもベストプラクティスです。したがって、 は SSM オートメーションドキュメントを呼び出す AWS FIS 実験 AWS Resilience Hub も提供します。このようにして、アプリケーションをプロアクティブにテストし、作成した SOP が意図したジョブを実行していることを確認することができます。
AWS Resilience Hub は、アプリケーションコードベースに追加できる CloudFormation テンプレートの形式でレコメンデーションを提供します。このテンプレートは以下を提供します。
+ SOP の実行に必要な権限を持つ IAM ロール。
+ SOP のテストに使用できる AWS FIS 実験。
+ どの SSM ドキュメントと IAM ロールを SOP として実行するか、どのリソースで実行するかを示すアプリケーションメタデータを含む SSM パラメータ。例: `$(DocumentName) for SOP $(HandleCrisisA) on $(ResourceA)`。
SOP の作成には試行錯誤が必要な場合があります。アプリケーションに対して障害耐性評価を実行し、 AWS Resilience Hub レコメンデーションから CloudFormation テンプレートを生成することをお勧めします。 CloudFormation テンプレートを使用して CloudFormation スタックを生成し、SOP で SSM パラメータとそのデフォルト値を使用します。SOP を実行して、どのような改良が必要かを確認してください。
アプリケーションごとに要件が異なるため、 AWS Resilience Hub によって提供されている SSM ドキュメントのデフォルトリストではすべてのニーズを満たすことはできません。ただし、デフォルトの SSM ドキュメントをコピーして、それを基にしてアプリケーションに合わせた独自のカスタムドキュメントを作成することはできます。独自のまったく新しい SSM ドキュメントを作成することもできます。デフォルトを変更する代わりに独自の SSM ドキュメントを作成する場合は、SOP の実行時に正しい SSM ドキュメントが呼び出されるように、それらを SSM パラメータに関連付ける必要があります。
必要な SSM ドキュメントを作成し、必要に応じてパラメータとドキュメントの関連付けを更新して SOP を完成させたら、SSM ドキュメントをコードベースに直接追加し、後で変更やカスタマイズを行います。そうすれば、アプリケーションをデプロイするたびに、最新の SOP もデプロイできます。
**Topics**
+ [AWS Resilience Hub レコメンデーションに基づく SOP の構築](building-sops.md)
+ [カスタム SSM ドキュメントの作成](create-custom-ssm-doc.md)
+ [デフォルトの代わりにカスタム SSM ドキュメントを使用する](using-different-ssm-doc.md)
+ [SOP のテスト](testing-sops.md)
+ [標準操作手順を表示する](view-sops.md)
# AWS Resilience Hub レコメンデーションに基づく SOP の構築
AWS Resilience Hub 推奨事項に基づいて SOP を構築するには、障害耐性ポリシーがアタッチされた AWS Resilience Hub アプリケーションが必要であり、そのアプリケーションに対して障害耐性評価を実行している必要があります。障害耐性評価により、SOP の推奨事項が生成されます。
AWS Resilience Hub 推奨事項に基づいて SOP を構築するには、推奨 SOP の CloudFormation テンプレートを作成し、コードベースに含める必要があります。 SOPs
**SOP レコメンデーションの CloudFormation テンプレートを作成する**
1. AWS Resilience Hub コンソールを開きます。
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. アプリケーションのリストで、SOP を作成したいアプリケーションを選択します。
1. **[評価]** タブを選択します。
1. **[障害耐性評価]** 表から評価を選択します。評価を受けていない場合は、[での障害耐性評価の実行 AWS Resilience Hub](run-assessment.md) の手順を完了してからこのステップに戻ってください。
1. **[運用上の推奨事項]** で、**[標準運用手順]** を選択します。
1. 含めたい SOP 推奨事項をすべて選択します。
1. **[CloudFormation テンプレートの作成]** を選択します。 AWS CloudFormation テンプレートの作成には数分かかる場合があります。
コードベースに SOP 推奨事項を含めるには、以下の手順を実行します。
**コードベースに AWS Resilience Hub レコメンデーションを含めるには**
1. **[運用上の推奨事項]** で **[テンプレート]** を選択します。
1. テンプレートのリストで、先ほど作成した SOP テンプレートの名前を選択します。
以下の情報を使用して、アプリケーションに実装されている SOP を特定できます。
+ **[SOP 名]** – アプリケーション用に定義した SOP の名前。
+ **[説明]** – SOP の目的を説明します。
+ **[SSM ドキュメント]** – SOP 定義を含む SSM ドキュメントの Amazon S3 のURL。
+ **[テスト実行]** – 最新のテストの結果を含むドキュメントの Amazon S3 のURL。
+ **ソーステンプレート** – SOP の詳細を含む AWS CloudFormation スタックの Amazon リソースネーム (ARN) を提供します。
1. **[テンプレートの詳細]** で、**[テンプレート S3 パス]** のリンクを選択し、Amazon S3 のコンソールでテンプレートオブジェクトを開きます。
1. Amazon S3 のコンソールで、**[オブジェクト]** テーブルから SOP フォルダへのリンクを選択します。
1. Amazon S3 のパスをコピーするには、JSON ファイルの前にあるチェックボックスを選択し、**[URL をコピー]** を選択します。
1. AWS CloudFormation コンソールから AWS CloudFormation スタックを作成します。 AWS CloudFormation スタックの作成の詳細については、「[https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。
AWS CloudFormation スタックの作成時に、前のステップからコピーした Amazon S3 パスを指定する必要があります。
# カスタム SSM ドキュメントの作成
アプリケーションのリカバリを完全に自動化するには、Systems Manager コンソールで SOP 用のカスタム SSM ドキュメントを作成する必要がある場合があります。既存の SSM ドキュメントをベースとして変更することも、新しい SSM ドキュメントを作成することもできます。
Systems Manager を使用して SSM ドキュメントを作成する方法の詳細については、「[チュートリアル:ドキュメントビルダーを使用してカスタムランブックを作成する](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)」を参照してください。
SSM ドキュメント構文について詳しくは、[SSM ドキュメント構文](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-doc-syntax.html)を参照してください。
SSM ドキュメントアクションの自動化については、「[Systems Manager Automation アクションのリファレンス](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-actions.html)」を参照してください。
# デフォルトの代わりにカスタム SSM ドキュメントを使用する
SOP に AWS Resilience Hub 推奨される SSM ドキュメントを作成したカスタムドキュメントに置き換えるには、コードベースで直接作業します。新しいカスタム SSM 自動化ドキュメントを追加することに加えて、以下の作業も行います。
1. 自動化の実行に必要な IAM 権限を追加します。
1. AWS FIS 実験を追加して SSM ドキュメントをテストします。
1. SOP として使用したい自動化ドキュメントを指す SSM パラメータを追加します。
一般的に、 で推奨されるデフォルト値を操作し AWS Resilience Hub 、必要に応じてカスタマイズするのが最も効率的です。たとえば、IAM ロールに必要なアクセス許可を追加または削除したり、新しい SSM ドキュメントを指すように AWS FIS 実験設定を変更したり、新しい SSM ドキュメントを指すように SSM パラメータを変更したりできます。
# SOP のテスト
前述のように、ベストプラクティスは、CI/CD パイプラインに AWS FIS 実験を追加して SOPs を定期的にテストすることです。これにより、停止が発生した場合に備えて準備が整います。
が提供する SOP AWS Resilience Hubとカスタム SOPs。
# 標準操作手順を表示する
**実装された SOP をアプリケーションから確認するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** で、アプリケーションを選択します。
1. **[標準操作手順]** タブを選択します。
「**標準運用手順の概要**」セクションの「**実施済み標準運用手順**」表には、SOP の推奨事項から生成された SOP のリストが表示されます。
SOP を特定するには、以下を使用します。
+ **[SOP 名]** – アプリケーション用に定義した SOP の名前。
+ **[SSM ドキュメント]** – SOP 定義を含む Amazon EC2 Systems Manager ドキュメントの S3 のURL。
+ **[説明]** – SOP の目的を説明します。
+ **[テスト実行]** – 最新のテストの結果を含むドキュメントの S3 のURL。
+ **[参照 ID]** – 参照されている SOP 推奨事項の識別子。
+ **[リソース ID]** – SOP 勧告が実装されているリソースの識別子。
**評価から推奨される SOP を確認するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** テーブルからアプリケーションを選択します。
アプリケーションを検索するには、**[アプリケーションを検索]** ボックスにアプリケーション名を入力します。
1. **[評価]** タブを選択します。
**[障害耐性評価]** 表では、以下の情報を使用して評価を特定できます。
+ **[名前]** – 作成時に提供した評価の名前。
+ **[ステータス]** – 評価の実行状態を示します。
+ **[コンプライアンスステータス]** – 評価が障害耐性ポリシーに準拠しているかどうかを示します。
+ **[障害耐性ドリフトステータス]** – アプリケーションが前回の成功した評価から逸脱したかどうかを示します。
+ **[アプリバージョン]** – アプリケーションのバージョン。
+ **[呼び出した人]** – 評価を呼び出したロールを示します。
+ **[開始時刻]** – 評価の開始時刻を示します。
+ **[終了時刻]** – 評価の終了時刻を示します。
+ **[ARN]** - 評価の Amazon リソースネーム (ARN)。
1. **[障害耐性評価]** 表から評価を選択します。
1. **[運用上の推奨事項]** タブを選択します。
1. **[標準操作手順]** タブを選択します。
**[標準運用手順]** 表では、以下の情報を参考に推奨 SOP についてさらに理解を深めることができます。
+ **[名前]** – 推奨 SOP の名前。
+ **[説明]** – SOP の目的を説明します。
+ **[状態]** – SOP の現在の実施状況を示します。表示は、**[実装済み]**、**[未実装]**、および **[除外]** です。
+ **[構成]** – 対処する必要のある保留中の構成の依存関係があるかどうかを示します。
+ **[タイプ]** – SOP のタイプを示します。
+ **[AppComponent]** – この SOP に関連するアプリケーションコンポーネント (AppComponents) を示します。サポートされている AppComponents について詳しくは、「[AppComponent 内のリソースのグループ化](https://docs.aws.amazon.com/resilience-hub/latest/userguide/AppComponent.grouping.html?icmpid=docs_resiliencehub_help_panel_operational_recommendations_alarms)」を参照してください。
+ **リファレンス ID** – AWS CloudFormation スタックイベントの論理識別子を示します AWS CloudFormation。
+ **[レコメンデーション ID]** – AWS CloudFormation内の AWS CloudFormation のスタックリソースの論理識別子を示します。
# AWS Fault Injection Service 実験の管理
このセクションでは、 で AWS Fault Injection Service (AWS FIS) 実験を管理する方法について説明します AWS Resilience Hub。 AWS FIS 実験を実行して、 AWS リソースの回復力と、アプリケーション、インフラストラクチャ、アベイラビリティーゾーン、 AWS リージョンのインシデントからの復旧にかかる時間を測定します。
回復性を測定するために、これらの AWS FIS 実験はリソースの中断をシミュレートします AWS 。中断の例としては、ネットワーク使用不可エラー、フェイルオーバー、Amazon EC2 または ASG AWS でのプロセスの停止、Amazon RDS でのブートリカバリ、アベイラビリティーゾーンの問題などがあります。 AWS FIS 実験が終了すると、アプリケーションが障害耐性ポリシーの RTO ターゲットで定義されている停止タイプから回復できるかどうかを推定できます。
のすべての実験 AWS Resilience Hub は を使用して構築 AWS FIS され、 AWS FIS アクションを実行します。 AWS FIS 実験では、特定の AWS サービス (Amazon EKS アクションなど) に合わせてカスタマイズされた AWS FIS オートメーションアクションのみを使用します。 AWS FIS アクションの詳細については、[AWS FIS 「 アクションリファレンス](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html)」を参照してください。
AWS FIS 実験は、デフォルトの状態で使用することも、要件に基づいてカスタマイズすることもできます。 AWS Resilience Hub コンソールおよびコンソールからの AWS FIS 実験の管理の詳細については AWS FIS 、以下のトピックを参照してください。
+ AWS Resilience Hub コンソール
+ [AWS FIS 実験の表示](view-fis-experiment.md)
+ [アプリケーションから実装された AWS FIS 実験のリストを表示するには](view-fis-experiment.md#view-active-fis-experiments)
+ [評価から推奨される AWS FIS 実験を表示するには](view-fis-experiment.md#view-recommended-fis-experiments)
+ [AWS FIS 実験の実行](test-assessment-report.md#arh-running-aws-fis-experiments)
+ [AWS Fault Injection Service 実験の失敗/ステータスチェック](test-failures.md)
+ AWS FIS コンソール
+ [AWS FIS 実験の管理](https://docs.aws.amazon.com//fis/latest/userguide/experiments.html)
+ [AWS FIS シナリオライブラリの使用](https://docs.aws.amazon.com//fis/latest/userguide/scenario-library.html)
+ [AWS FIS 実験テンプレートの管理](https://docs.aws.amazon.com//fis/latest/userguide/manage-experiment-template.html)
# AWS FIS 実験の開始、作成、実行
AWS Resilience Hub は、 AWS FIS 実験と統合することで AWS FIS 実験を簡素化します。カスタマイズされた推奨事項を提供し、アプリケーションコンポーネント (AppComponents) にマッピングされた事前入力されたテンプレートを使用して AWS FIS 実験を開始できるため、効率的な耐障害性テストが可能になります。
**運用上の推奨事項から AWS FIS 実験を開始するには**
1. AWS Resilience Hub コンソールを開きます。
1. ナビゲーションペインで、**[アプリケーション]** を選択します。
1. アプリケーションのリストで、テストを作成するアプリケーションを選択します。
1. **[評価]** タブを選択します。
1. **[障害耐性評価]** 表から評価を選択します。評価を受けていない場合は、[での障害耐性評価の実行 AWS Resilience Hub](run-assessment.md) の手順を完了してからこのステップに戻ってください。
1. **[運用上の推奨事項]** タブを選択します。
1. **Fault Injection 実験**の前に右矢印を選択します。
このセクションでは、アプリケーション AWS Resilience Hub がストレステストを行い、その耐障害性を向上させるために が推奨するすべての AWS FIS 実験を一覧表示します。実装に基づいて、 AWS FIS 実験は次の状態に分類されます。
+ **実装済み** – が推奨する実験 AWS Resilience Hub がアプリケーションに実装されていることを示します。以下の番号を選択すると、実装されたすべての実験が **Experiments** テーブルに表示されます。
+ **部分的に実装** – が推奨する実験 AWS Resilience Hub がアプリケーションに部分的に実装されていることを示します。以下の数値を選択すると、部分的に実装されたすべての実験が **Experiments** テーブルに表示されます。
+ **実装されていない** – が推奨する実験 AWS Resilience Hub がアプリケーションで実装されていないことを示します。以下の数値を選択すると、未実装のすべての実験が **Experiments** テーブルに表示されます。
+ **除外** – が推奨する実験 AWS Resilience Hub がアプリケーションから除外されていることを示します。以下の数値を選択すると、除外されたすべての実験が **Experiments** テーブルに表示されます。推奨される実験を含めるか除外するかの詳細については、[「運用上の推奨事項を含めるか除外](https://docs.aws.amazon.com/resilience-hub/latest/userguide/exclude-recommend.html?icmpid=docs_resiliencehub_help_panel_operational_recommendations_alarms)するか」を参照してください。
**Experiments** テーブルには、アプリケーションの耐障害性スコアに影響を与える実装された AWS FIS すべての実験が一覧表示されます。 AWS FIS 実験は、次の情報を使用して識別できます。
+ **アクション名** – アプリケーションに推奨される AWS FIS アクションを示します。アクション名を選択すると、**AWS FIS 実験の詳細**ページで推奨されるすべての AppComponents が表示されます。**状態**が**追跡不可**に設定されている場合、実験がシナリオである AWS FIS ことを示します。シナリオ名を選択すると、コンソールの**シナリオライブラリ**ページで AWS FIS その詳細が表示されます。
+ **状態** – AWS FIS 実験の現在の実装状態を示します。つまり、**実装済み**、**部分的に実装**済み、**未実装**、**除外済み**です。
**注記**
AWS FIS シナリオは、複数の事前定義されたアクションを持つコンソールのみの機能です。したがって、追跡 AWS Resilience Hub できず、**状態**は**追跡不可**に設定されます。
+ **説明** – AWS FIS アクションの目的について説明します。
1. 実験を開始する AWS FIS アクションを選択します。
AWS FIS 実験レコメンデーションセクションでは、以下の情報を使用して AppComponents で実装する必要がある実験の詳細を理解できます。
+ **名前** – リソースがグループ化されている AppComponent の名前。
+ **状態** – AWS FIS アクションの現在の実装状態を示します。つまり、**実装済み**、**部分的に実装**済み、**未実装**、除外**済み**です。
**注記**
AWS FIS シナリオは、複数の事前定義されたアクションを持つコンソールのみの機能です。したがって、追跡 AWS Resilience Hub できず、**状態**は**追跡不可**に設定されます。
+ **ターゲットの選択** – **実験の開始 を選択すると、リソースが実験**にどのように含まれるかを示します。 AWS Resilience Hub がターゲットリソースを自動的に決定しない場合は、それぞれの**ターゲット選択**フィールドにカーソルを合わせると、ターゲットリソースの追加に関するガイダンスが表示されます。
+ **リソース** – AppComponent の下にグループ化されたリソースの数を示します。リソース****ダイアログボックスでこれらのリソースを表示する番号を選択します。リソースは、以下を使用して識別できます。
+ **[論理 ID]** - リソースの論理 ID を示します。論理 ID は、、Terraform 状態ファイル AWS CloudFormation、myApplications アプリケーション、 AWS Resource Groups リソース、または Amazon Elastic Kubernetes Service クラスター内のリソースを識別するために使用される名前です。
+ **物理 ID** – Amazon EC2 インスタンス ID や Amazon S3 バケット名など、リソースに実際に割り当てられた識別子を示します。
+ **Type** – リソースのタイプを示します。
+ **Region** – リソースが配置されているリージョンを示します AWS 。
1. AppComponent を選択し、**Include** または **Exclude** を選択して、 AWS FIS それぞれ実験に AppComponent を含めるか除外します。
1. **実験の開始 **を選択します。
AWS Resilience Hub コンソールで**テンプレートの詳細を指定**ページにリダイレクトされ AWS FIS 、新しいタブで開きます。
1. 実験テンプレートを作成するには、[「 コンソールを使用して実験テンプレートを作成するには](https://docs.aws.amazon.com/fis/latest/userguide/create-template.html)」の手順を実行します。
さらに、テンプレートの詳細を入力し、 AWS FIS 「コンソール[を使用して実験テンプレートを作成するには](https://docs.aws.amazon.com/fis/latest/userguide/create-template.html)」の手順に従ってコンソールの**「テンプレートの詳細の指定**」ページで**「次**へ」を選択すると、 AWS Resilience Hub は アクションと**ターゲット****「アクション**とターゲット」ページのリソースタイプの**アクションとターゲット**のマッピングを自動的に試行します。ただし、カバレッジを向上させるには、アクションの追加とターゲットの追加をそれぞれ選択**してアクション**と**ターゲット**を手動で追加し、残りの手順を実行して実験を作成します。
## AWS FIS 実験の実行
AWS FIS コンソールで実験を作成したら、[「テンプレートから実験を開始する](https://docs.aws.amazon.com/fis/latest/userguide/start-experiment-from-template.html)」の手順に従ってコンソールで AWS FIS 実験を実行します。で実行した最新の実験 AWS Resilience Hub を検出する場合は AWS FIS、新しい評価を実行する必要があります。評価の実行の詳細については、「[での障害耐性評価の実行 AWS Resilience Hub](run-assessment.md)」を参照してください。
# AWS FIS 実験の表示
で AWS Resilience Hub、 AWS リソースの回復力と、アプリケーション、インフラストラクチャ、アベイラビリティーゾーン、 AWS リージョン インシデントからの復旧にかかる時間を測定するために設定した AWS FIS 実験を表示します。
ダッシュボードからアクティブな AWS FIS 実験のリストを表示するには、左側のナビゲーションメニューから **Dashboard** を選択します。
**実装された実験** テーブルでは AWS FIS 、次の情報を使用して実験を特定できます。
+ **[実験 ID]** – AWS FIS の実験の識別子。
+ **アクション** – AWS FIS 実験に関連付けられた AWS FIS アクションを示します。さらに、複数のアクションがある場合、 AWS FIS 実験に関連付けられた AWS FIS アクションの数が強調表示されます。詳細を特定するには、カーソルを合わせるか、移動します。
+ **実験テンプレート ID** – 実験の作成に使用された AWS FIS 実験テンプレートの AWS FIS 識別子。
**アプリケーションから実装された AWS FIS 実験のリストを表示するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** テーブルからアプリケーションを選択します。
アプリケーションを検索するには、**[アプリケーションを検索]** ボックスにアプリケーション名を入力します。
1. **[故障注入実験]** を選択します。
**実装された実験** テーブルでは、次の情報を使用して、アプリケーションで実装された AWS FIS 実験を特定できます。
+ **[実験 ID]** – AWS FIS の実験の識別子。
+ **アクション** – AWS FIS 実験に関連付けられた AWS FIS アクションを示します。さらに、複数のアクションがある場合、 AWS FIS 実験に関連付けられた AWS FIS アクションの数が強調表示されます。詳細を特定するには、カーソルを合わせるか、移動します。
+ **[実験テンプレート ID]** – AWS FIS の実験の作成に使用された AWS FIS の実験テンプレートの識別子。
**評価から推奨される AWS FIS 実験を表示するには**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** テーブルからアプリケーションを選択します。
アプリケーションを検索するには、**[アプリケーションを検索]** ボックスにアプリケーション名を入力します。
1. **[評価]** タブを選択します。
**評価**表では、次の情報を使用して評価を特定できます。
+ **[名前]** – 作成時に提供した評価の名前。
+ **[ステータス]** – 評価の実行状態を示します。
+ **[コンプライアンスステータス]** – 評価が障害耐性ポリシーに準拠しているかどうかを示します。
+ **耐障害性** – アプリケーションがアタッチされた耐障害性ポリシーで定義された RTO および RPO ターゲットからドリフトしたかどうかを示します。
+ **アプリケーションバージョン** – 評価されたアプリケーションのバージョン。
+ **[呼び出した人]** – 評価を呼び出したロールを示します。
+ **[開始時刻]** – 評価の開始時刻を示します。
+ **[終了時刻]** – 評価の終了時刻を示します。
+ **[ARN]** - 評価の Amazon リソースネーム (ARN)。
1. 評価 テーブルから**評価**を選択します。
1. **[運用上の推奨事項]** を選択します。
1. **Fault Injection 実験**の前に右矢印を選択します。
このセクションでは、アプリケーション AWS Resilience Hub がストレステストを行い、その耐障害性を向上させるために が推奨するすべての AWS FIS 実験を一覧表示します。実装に基づいて、 AWS FIS 実験は次の状態に分類されます。
+ **実装済み** – が推奨する実験 AWS Resilience Hub がアプリケーションに実装されていることを示します。以下の番号を選択すると、実装されたすべての実験が **Experiments** テーブルに表示されます。
+ **部分的に実装** – が推奨する実験 AWS Resilience Hub がアプリケーションに部分的に実装されていることを示します。以下の数値を選択すると、部分的に実装されたすべての実験が **Experiments** テーブルに表示されます。
+ **実装されていない** – が推奨する実験 AWS Resilience Hub がアプリケーションで実装されていないことを示します。以下の数値を選択すると、未実装のすべての実験が **Experiments** テーブルに表示されます。
+ **除外** – が推奨する実験 AWS Resilience Hub がアプリケーションから除外されていることを示します。以下の数値を選択すると、除外されたすべての実験が **Experiments** テーブルに表示されます。推奨される実験を含めるか除外するかの詳細については、[「運用上の推奨事項を含めるか除外](https://docs.aws.amazon.com/resilience-hub/latest/userguide/exclude-recommend.html?icmpid=docs_resiliencehub_help_panel_operational_recommendations_alarms)するか」を参照してください。
**Experiments** テーブルには、アプリケーションの耐障害性スコアに影響を与える実装された AWS FIS すべての実験が一覧表示されます。 AWS FIS 実験は、次の情報を使用して識別できます。
+ **アクション名** – アプリケーションに推奨される AWS FIS アクションを示します。**状態**が**追跡不可**に設定されている場合、実験がシナリオである AWS FIS ことを示します。シナリオ名を選択すると、コンソールの**シナリオライブラリ**ページで AWS FIS その詳細が表示されます。
+ **状態** – AWS FIS 実験の現在の実装状態を示します。つまり、**実装済み**、**部分的に実装**済み、**未実装**、**除外済み**です。
**注記**
AWS FIS シナリオは、複数の事前定義されたアクションを持つコンソールのみの機能です。したがって、追跡 AWS Resilience Hub できず、**状態**は**追跡不可**に設定されます。
+ **説明** – AWS FIS アクションの目的について説明します。
# AWS Fault Injection Service 実験の失敗/ステータスチェック
AWS Resilience Hub では、開始した実験のステータスを追跡できます。詳細については、[評価から推奨される AWS FIS 実験を表示するには](view-fis-experiment.md#view-recommended-fis-experiments)「」の手順を参照してください。
**Topics**
+ [AWS Systems Manager を使用した AWS FIS 実験実行の分析](test-failures-ssm.md)
+ [AWS FIS Amazon Elastic Kubernetes Service クラスターで実行されている Kubernetes ポッドのテスト中の実験失敗](test-failures-eks.md)
# AWS Systems Manager を使用した AWS FIS 実験実行の分析
AWS FIS 実験を実行したら、Systems Manager で AWS 実行の詳細を表示できます。
1. **CloudTrail** > **イベント履歴**に移動します。
1. 実験 ID を使用して**ユーザー名**でイベントをフィルタリングします。
1. 「StartAutomationExecution」エントリを表示します。**リクエスト ID** は SSM オートメーション ID です。
1. **AWS システム・マネージャー **> **オートメーション**に進みます。
1. SSM オートメーションID を使用して**実行 ID** でフィルタリングし、オートメーションの詳細を表示します。
実行は、Systems Manager のどのオートメーションでも分析できます。詳細については、「ユーザーガイド」の「[AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)」を参照してください。実行入力パラメータは**、実行の詳細****の入力パラメータ**セクションに表示され、 AWS FIS 実験に表示されないオプションパラメータが含まれます。
実行ステップ内の特定のステップにドリルダウンすると、ステップステータスやその他のステップの詳細に関する情報が表示されます。
**よくある失敗**
評価レポートの実行中に発生する一般的な障害は次のとおりです。
+ テスト/SOP 実験が実行される前に、アラームテンプレートがデプロイされませんでした。これにより、自動化ステップ中にエラーメッセージが表示されます。
+ **障害メッセージ:** `The following parameters were not found: [/ResilienceHub/Alarm/3dee49a1-9877-452a-bb0c-a958479a8ef2/nat-gw-alarm-bytes-out-to-source-2020-09-21_nat-02ad9bc4fbd4e6135]. Make sure all the SSM parameters in automation document are created in SSM Parameter Store.`
+ **修正:**フォールトインジェクション実験を再実行する前に、必ず関連するアラームをレンダリングし、結果のテンプレートをデプロイしてください。
+ 実行ロールに権限がありません。このエラーメッセージは、指定した実行ロールに権限がない場合に発生し、ステップの詳細に表示されます。
+ **障害メッセージ:** `An error occurred (Unauthorized Operation) when calling the DescribeInstanceStatus operation: You are not authorized to perform this operation. Please Refer to Automation Service Troubleshooting Guide for more diagnosis details`。
+ **修正**: 正しい実行ロールを指定したことを確認してください。これが完了したら、必要な権限を追加して評価を再実行してください。
+ 実行は成功しましたが、期待した結果にはなりませんでした。これは、パラメータが正しくないか、内部自動化の問題が原因です。
+ **失敗メッセージ:** 実行に成功したため、エラーメッセージは表示されません。
+ **修復:** 入力パラメータを確認し、 AWS FIS 実験実行の分析で説明されている実行されたステップを確認してから、個々のステップで予想される入力と出力を調べます。
# AWS FIS Amazon Elastic Kubernetes Service クラスターで実行されている Kubernetes ポッドのテスト中の実験失敗
Amazon EKS クラスターで実行されている Kubernetes ポッドのテスト中に発生する Amazon Elastic Kubernetes Service (Amazon EKS) の障害は次のとおりです。
+ AWS FIS 実験または Kubernetes サービスアカウントの IAM ロールの設定が正しくありません。
+ **障害メッセージ:**
+ `Error resolving targets. Kubernetes API returned ApiException with error code 401`.
+ `Error resolving targets. Kubernetes API returned ApiException with error code 403`.
+ `Unable to inject AWS FIS Pod: Kubernetes API returned status code 403. Check Amazon EKS logs for more details`.
+ **修正**: 以下を確認してください。
+ 「[AWS FIS`aws:eks:pod`アクションを使用する](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html)」の指示に従っていることを確認してください。
+ 必要な RBAC 権限と正しい名前空間を持つ Kubernetes サービスアカウントを作成して設定したことを確認してください。
+ 提供された IAM ロール (テストの CloudFormation スタックの出力を参照) を Kubernetes ユーザーにマッピングしていることを確認します。
+ AWS FIS ポッドを開始できません: 失敗したサイドカーコンテナの最大数に達しました。これは通常、メモリが AWS FIS サイドカーコンテナを実行するのに十分でない場合に発生します。
+ **障害メッセージ:** `Unable to heartbeat FIS Pod: Max failed sidecar containers reached`。
+ **修復:** このエラーを回避する方法の 1 つは、使用可能なメモリまたは CPU に合わせて目標負荷率を下げることです。
+ 実験の開始時にアラームアサーションが失敗しました。このエラーは、関連するアラームにデータポイントがないために発生します。
+ **障害メッセージ:** `Assertion failed for the following alarms`。アサーションが失敗したすべてのアラームを一覧表示します。
+ **修復:** Container Insights がアラーム用に正しくインストールされ、アラームがオンになっていない (`ALARM` の状態になっている) ことを確認します。
# 障害耐性スコアの理解
このセクションでは、 AWS Resilience Hub がさまざまな中断シナリオからアプリケーションの準備状況を定量化する方法について説明します。
AWS Resilience Hub は、アプリケーションの障害耐性体制を表す障害耐性スコアを提供します。このスコアは、アプリケーションがアプリケーションの障害耐性ポリシー、アラーム、標準作業手順書 (SOP)、テストを満たすための推奨事項にどの程度準拠しているかを反映します。アプリケーションが使用するリソースのタイプに基づいて、 は中断タイプごとにアラーム、SOPs、および一連のテスト AWS Resilience Hub を推奨します。
障害耐性の最高スコアは 100 ポイントです。最高のスコアまたは最高得点を達成するには、推奨されているアラーム、SOP、テストをすべてアプリケーションに実装する必要があります。たとえば、 は、1 つのアラームと 1 つの SOP を含む 1 つのテスト AWS Resilience Hub を推奨します。テストを実行してアラームを起動し、関連する SOP を開始します。テストが正常に実行され、アプリケーションがレジリエンスポリシーを満たしていれば、100 ポイントに近い障害耐性スコアが与えられます。
最初の評価を実行した後、 はアプリケーションから運用上の推奨事項を除外するオプション AWS Resilience Hub を提供します。除外された推奨事項が障害耐性スコアに与える影響を理解するには、新しい評価を実施する必要があります。ただし、除外された推奨事項をアプリケーションに含めて、新しい評価を実行することはいつでも可能です。アラーム、SOP、テストの推奨事項を含めたり除外したりする方法の詳細については、[運用上の推奨事項を含めるまたは除外する](exclude-recommend.md)を参照してください。
# アプリケーションの障害耐性スコアへのアクセス
ナビゲーションメニューから **[ダッシュボード]** または **[アプリケーション]** を選択すると、アプリケーションの障害耐性スコアを表示できます。
**ダッシュボードから障害耐性スコアにアクセスする**
1. 左側のナビゲーションメニューで、**[ダッシュボード]** を選択します。
1. **時間の経過に伴うアプリケーションの障害耐性スコア**で、**最大 4 つのアプリケーションを選択**ドロップダウンリストから 1 つ以上のアプリケーションを選択します。
1. **[障害耐性スコア]** チャートには、選択したすべてのアプリケーションの障害耐性スコアが表示されます。
**アプリケーションから障害耐性スコアへのアクセス**
1. 左側のナビゲーションメニューで、**[アプリケーション]** を選択します。
1. **[アプリケーション]** で、アプリケーションを選択します。
1. **概要**を選択します。
**障害耐性スコア**グラフには、アプリケーションの障害耐性スコアの傾向が最大 1 年間表示されます。 には、以下を使用して、可能な限り最大の障害耐性スコアを改善および達成するために対処する必要があるアクション項目、障害耐性ポリシー違反、運用上の推奨事項 AWS Resilience Hub が表示されます。
+ 障害耐性スコアを可能な限り高め、達成するために完了する必要のあるアクションアイテムを確認するには、**[アクションアイテム]** タブを選択します。選択すると、以下 AWS Resilience Hub が表示されます。
+ **[RTO/RPO]** — アプリケーションの障害耐性ポリシーの違反を解決するために修正する必要がある復旧時間 (RTO/RPO) の数を示します。値を選択すると、アプリケーションの評価レポートに RTO/RPO の詳細が表示されます。
+ **[アラーム]** — アプリケーションに実装する必要のある推奨 Amazon CloudWatch アラームの数を示します。値を選択すると、修正が必要な Amazon CloudWatch アラームがアプリケーションの評価レポートに表示されます。
+ **[SOP]** — アプリケーションに実装する必要がある推奨 SOP の数を示します。値を選択すると、修正が必要な SOP がアプリケーションの評価レポートに表示されます。
+ **[FIS]** — アプリケーションに実装する必要のある推奨テストの数を示します。値を選択すると、修正が必要なテストがアプリケーションの評価レポートに表示されます。
+ 障害耐性スコアに影響する各コンポーネントのスコアを表示するには、**[スコアの詳細]** を選択します。選択すると、 AWS Resilience Hub には次の内容が表示されます。
+ **[RTO/RPO コンプライアンス]** — アプリケーションコンポーネント (AppComponents) が、アプリケーションの障害耐性ポリシーで定義されているワークロードの推定回復時間と目標復旧時間にどの程度準拠しているかを示します。値を選択すると、アプリケーションの評価レポートに RTO/RPO の推定が表示されます。
+ **[実装済みアラーム]** — 実装された Amazon CloudWatch アラームの実際の寄与度を、アプリケーションの障害耐性スコアに対する最大寄与率と比較したものです。値を選択すると、実装された Amazon CloudWatch アラームがアプリケーションの評価レポートに表示されます。
+ **[実装済み SOP]** — 実装された SOP の実際の寄与度を、アプリケーションの障害耐性スコアに対する最大貢献度と比較したものです。値を選択すると、実装された SOP がアプリケーションの評価レポートに表示されます。
+ **[実施された FIS 実験]** – 実装されたテストの実際の寄与度をアプリケーションの障害耐性スコアに対する最大寄与度と比較したものです。値を選択すると、実装されたテストがアプリケーションの評価レポートに表示されます。
+ 障害耐性ポリシー違反と運用上の推奨事項を表示するには、右矢印を選択して **[ポリシー違反と運用上の推奨事項]** セクションを展開します。展開すると、以下 AWS Resilience Hub が表示されます。
+ **[障害耐性ポリシー違反]** — アプリケーションの障害耐性ポリシーに違反しているアプリケーションコンポーネントの数を示します。**[RTO/RPO]** の横にある値を選択すると、アプリケーションの評価レポートの **[障害耐性に関する推奨事項]** タブに詳細が表示されます。
+ **[運用上の推奨事項]** — **[未処理]** タブと **[除外]** タブを使用して、アプリケーションの障害耐性を高めるために実装または実行されていない運用上の推奨事項を示します。運用上の推奨事項には、使用されていない推奨事項と実装されていない推奨事項がすべて含まれます。
実装が必要な運用上の推奨事項を確認するには、**[未処理]** タブを選択します。選択すると、以下 AWS Resilience Hub が表示されます。
+ **[アラーム]** — 実装する必要のある推奨 Amazon CloudWatch アラームの数を示します。
+ **[SOP]** — 実装する必要のある推奨 SOP の数を示します。
+ **[FIS]** — 実施する必要のある推奨テストの数を示します。
アプリケーションから除外されている運用上の推奨事項を表示するには、**[除外]** タブを選択します。選択すると、以下 AWS Resilience Hub が表示されます。
+ **[アラーム]** — アプリケーションから除外されている推奨 Amazon CloudWatch アラームの数を示します。
+ **[SOP]** — アプリケーションから除外されている推奨 SOP の数を示します。
+ **[FIS]** — アプリケーションから除外されている推奨テストの数を示します。
# 障害耐性スコアの計算
このセクションの表では、各レコメンデーションタイプのスコアリングコンポーネントとアプリケーションの耐障害性スコアを決定する AWS Resilience Hub ために で使用される式について説明します。各レコメンデーションタイプのスコアリングコンポーネントとアプリケーションの耐障害性スコア AWS Resilience Hub について によって決定される結果値はすべて、最も近いポイントに丸められます。例えば、3 つのアラームのうち 2 つを実装した場合、スコアは 13.33 ((2/3) \$1 20) ポイントになります。この値は 13 ポイントに四捨五入されます。表内の計算式に使われているウェイトの詳細については、[重量](#weight) セクションを参照してください。
一部のスコアリングコンポーネントは `ScoringComponentResiliencyScore` API を通じてのみ取得できます。この API の詳細については、[スコアリングコンポーネント障害耐性スコア](https://docs.aws.amazon.com/resilience-hub/latest/APIReference/API_ScoringComponentResiliencyScore.html)を参照してください。
**テーブル**
+ [**各推奨タイプのスコアリングコンポーネントを計算する式**](#recommendation-type-coverage)
+ [**障害耐性スコアの計算式**](#resiliency-score)
+ [**AppComponents と中断タイプの障害耐性スコアを計算する式**](#resiliency-score-AppComponents-disruption-types)
次の表は、各レコメンデーションタイプのスコアリングコンポーネントを計算する AWS Resilience Hub ために で使用される式を示しています。
**各推奨タイプのスコアリングコンポーネントを計算する式**
| スコアリングコンポーネント | 説明 | Formula | 例 |
| --- | --- | --- | --- |
| テストカバレッジ (T) | AWS Resilience Hub 推奨テストの総数のうち、正常に実装されたテストと除外されたテストの数に基づいて標準化されたスコア (0～100 ポイント)。 障害耐性スコアを計算するには、 がそれを実装済みと見な AWS Resilience Hub すために、推奨されるテストが過去 30 日間に正常に実行されている必要があります。 | T = ((Total number of tests implemented) \$1 (Total number of tests excluded)) / (Total number of tests recommended)計算式の一部は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/resilience-hub/latest/userguide/calculate-score.html) | 20 件の AWS Resilience Hub 推奨テストのうち 10 件を実装し、5 件を除外した場合、テストカバレッジは次のように計算されます。`T = (10 + 5) / 20`つまり、`T = .75 or 75 points` |
| アラームカバレッジ (A) | AWS Resilience Hub 推奨される Amazon CloudWatch アラームの総数のうち、正常に実装および除外された Amazon CloudWatch アラームの数に基づく正規化されたスコア (0～100 ポイント）。 障害耐性スコアを計算するには、 AWS Resilience Hub が実装済みとみなせるように、推奨アラームが**準備完了**状態になっている必要があります。 | A = ((Total number of alarms implemented) \$1 (Total number of alarms excluded)) / (Total number of alarms recommended)計算式の一部は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/resilience-hub/latest/userguide/calculate-score.html) | AWS Resilience Hub が推奨した 20 個の Amazon CloudWatch アラームのうち 10 個を実装し、5 個を除外した場合、Amazon CloudWatch アラームカバレッジは次のように計算されます。`A = (10 + 5) / 20`つまり、`A = .75 or 75 points` |
| SOP カバレッジ (S) | AWS Resilience Hub が推奨する SOP の総数のうち、正常に実装されたものと除外された SOP の数に基づく標準化されたスコア (0～100 ポイント)。 | S = ((Total number of SOPs implemented) \$1 (Total number of SOPs excluded)) / (Total number of SOPs recommended)計算式の一部は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/resilience-hub/latest/userguide/calculate-score.html) | 20 個の AWS Resilience Hub 推奨 SOP のうち 10 個の SOP を実装し、5 個の SOP を除外した場合、SOP カバレッジは次のように計算されます。`S = (10 + 5) / 20`つまり、`S = .75 or 75 points` |
| RTO/RPO コンプライアンス (P) | アプリケーションが障害耐性ポリシーを満たしていることに基づく標準化されたスコア (0～100 ポイント)。 | P = Total weights of disruption types meeting the application's resiliency policy / Total weights of all disruption types. | アプリケーションの障害耐性ポリシーがアベイラビリティーゾーン (AZ) とインフラストラクチャの中断タイプのみを満たす場合、障害耐性ポリシースコア (P) は次のように計算されます。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/resilience-hub/latest/userguide/calculate-score.html) |
次の表は、アプリケーション全体の障害耐性スコアを計算する AWS Resilience Hub ために が使用する式を示しています。
**障害耐性スコアの計算式**
| スコアリングコンポーネント | 説明 | Formula | 例 |
| --- | --- | --- | --- |
| アプリケーションの障害耐性スコア (RS) | アプリケーションがその障害耐性ポリシーを満たしていることに基づく、標準化された障害耐性スコア (0～100 ポイント)。アプリケーションごとの障害耐性スコアは、すべての推奨タイプの加重平均です。つまり: RS = Weighted Average (T, A, S, P) | アプリケーションごとの障害耐性スコアは、次の式を使用して計算されます: RS = (T \$1 Weight(T) \$1`A * Weight(A) +``S * Weight(S) +``P * Weight(P)) /``(Weight(T) + Weight(A) + Weight(S) + Weight(P))` | 各推奨タイプ表の対象範囲を計算する式は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/resilience-hub/latest/userguide/calculate-score.html)アプリケーションごとの障害耐性スコアは次のように計算されます。`RS = ((.75 * .2) + (.75 * .2) + (.75 * .2) + (.5 * .4)) /(.2 + .2 + .2 + .4)`つまり、`RS = .65 or 65 points` |
次の表は、アプリケーションコンポーネント (AppComponents) と中断タイプの耐障害性スコアを計算する AWS Resilience Hub ために で使用される式を示しています。ただし、AppComponents と中断タイプの障害耐性スコアは、次の AWS Resilience Hub API を通じてのみ取得できます。
+ `RSo` を取得するための [DescribeAppAssessment](https://docs.aws.amazon.com/resilience-hub/latest/APIReference/API_DescribeAppAssessment.html)
+ `RSao` と `RSA` を取得するための [ListAppComponentCompliances](https://docs.aws.amazon.com/resilience-hub/latest/APIReference/API_ListAppComponentCompliances.html)
**AppComponents と中断タイプの障害耐性スコアを計算する式**
| スコアリングコンポーネント | 説明 | Formula | 例 |
| --- | --- | --- | --- |
| アプリコンポーネントごと、および中断タイプごとの障害耐性スコア (RSao) | AppComponent が中断タイプごとの障害耐性ポリシーを満たしていることに基づく標準化されたスコア (0～100 ポイント)。AppComponent ごとおよび中断タイプごとの障害耐性スコアは、すべての推奨タイプの加重平均です。つまり: `RSao = Weighted Average (T, A, S, P)``T, A, S, P` の値は、すべての推奨テスト、アラーム、SOP、AppComponent と中断タイプの障害耐性ポリシーを満たすために計算されたものです。 | AppComponent ごとおよび中断タイプごとの障害耐性スコアは、次の式を使用して計算されます。`RSao = (T * Weight(T) + ``A * Weight(A) + ``S * Weight(S) + ``P * Weight(P)) /``(Weight(T) + Weight(A) + Weight(S) + Weight(P))` | すべての推奨タイプの `RSao` の前提条件は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/resilience-hub/latest/userguide/calculate-score.html)AppComponent および中断タイプごとの障害耐性スコアは次のように計算されます。`RSao = ((.75 * .2) + (.75 * .2) + (.75 * .2) + (.5 * .4)) / `(.2 \$1 .2 \$1 .2 \$1 .4)つまり、`RSao = .65 or 65 points` |
| AppComponent ごとの障害耐性スコア (RSa) | 障害耐性ポリシーを満たしていることに基づく標準化されたスコア (0～100 ポイント)。AppComponent ごとの障害耐性スコアは、すべての推奨タイプの加重平均です。つまり: RSa = Weighted Average (T, A, S, P)`T, A, S, P` の値は、すべての推奨テスト、アラーム、SOP、および AppComponent の障害耐性ポリシーを満たために計算されたものです。 | AppComponent ごとの障害耐性スコアは、次の式を使用して計算されます。`RSa = ``(T * Weight(T) +``A * Weight(A) +``S * Weight(S) +``P * Weight(P)) /``(Weight(T) + Weight(A) + Weight(S) + Weight(P))` | すべての推奨タイプの `RSa` の前提条件は次のとおりです。[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/resilience-hub/latest/userguide/calculate-score.html)AppComponent ごとの障害耐性スコアは次のように計算されます。`RSa = ((.75 * .2) + (.75 * .2) + (.75 * .2) + (.5 * .4)) / `(.2 \$1 .2 \$1 .2 \$1 .4)つまり、`RSa = .65 or 65 points` |
| 中断タイプごとの障害耐性スコア (RSo) | 障害耐性ポリシーを満たしていることに基づく標準化されたスコア (0～100 ポイント)。中断タイプごとの障害耐性スコアは、すべての推奨タイプの加重平均です。つまり: RSo = Weighted Average (T, A, S, P)`T, A, S, P` の値は、すべての推奨テスト、アラーム、SOP、および中断タイプの障害耐性ポリシーを満たすために計算されたものです。 | 中断タイプごとの障害耐性スコアは、次の式を使用して計算されます。`RSo = (T * Weight(T) + A * Weight(A) + ``S * Weight(S) + P * Weight(P)) /` `(Weight(T) + Weight(A) + Weight(S) + Weight(P))` | すべての推奨タイプの `RSo` の前提条件は次のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/resilience-hub/latest/userguide/calculate-score.html) 中断タイプごとの障害耐性スコアは、次のように計算されます。 `RSo = ((.75 * .2) + (.75 * .2) + (.75 * .2) + (.5 *.4)) /` `(.2 + .2 + .2 + .4)` つまり、`RSo = .65 or 65 points` |
## 重量
AWS Resilience Hub は、総障害耐性スコアの各レコメンデーションタイプに重みを割り当てます。
次の表は、アラーム、SOPs、障害耐性ポリシーへの準拠、中断タイプの重みを示しています。中断タイプには、アプリケーション、インフラストラクチャ、AZ、リージョンが含まれます。
**注記**
ポリシーのリージョン RTO または RPO ターゲットを定義しないことを選択した場合、**リージョンが定義されていない場合の重み列に示すように、他の中断タイプの重みが**それに応じて増加します。
**アラーム、SOP、テスト、ポリシーターゲットのウェイト**
| 推奨事項の種類 | (重量) |
| --- | --- |
| アラーム | 20 ポイント |
| SOP | 20 ポイント |
| テスト | 20 ポイント |
| 障害耐性ポリシーを満たす | 40 ポイント |
**中断タイプ別のウェイト**
| 中断タイプ | リージョンが定義された場合のウェイト | リージョンが定義されていない場合のウェイト |
| --- | --- | --- |
| アプリケーション | 40 ポイント | 44.44 ポイント |
| インフラストラクチャ | 30 ポイント | 33.33 ポイント |
| アベイラビリティーゾーン (AZ) | 20 ポイント | 22.22 ポイント |
| リージョン | 10 ポイント | 該当なし |
# 運用上の推奨事項を アプリケーションに統合する CloudFormation
**「運用上の推奨事項**」ページで**CloudFormation テンプレートの作成**」を選択すると、 はアプリケーションの特定のアラーム、標準運用手順 (SOP)、または AWS FIS 実験を記述する CloudFormation テンプレート AWS Resilience Hub を作成します。 CloudFormation テンプレートは Amazon S3 バケットに保存され、**運用上の推奨事項**ページのテンプレート**の詳細**タブでテンプレートへの S3 パスを確認できます。
たとえば、次のリストは、 によってレンダリングされたアラームレコメンデーションを記述する JSON 形式の CloudFormation テンプレートを示しています AWS Resilience Hub。これは、`Employees` という DynamoDB テーブルの読み取りスロットリングアラームです。
テンプレートの `Resources` セクションでは、DynamoDB テーブルの読み取りスロットルイベントの数が 1 を超えたときにアクティブになる `AWS::CloudWatch::Alarm` のアラームについて説明しています。また、2 つの`AWS::SSM::Parameter`リソースは、実際のアプリケーションをスキャンすることなく AWS Resilience Hub 、 がインストール済みリソースを識別できるようにするメタデータを定義します。
```
{
"AWSTemplateFormatVersion" : "2010-09-09",
"Parameters" : {
"SNSTopicARN" : {
"Type" : "String",
"Description" : "The ARN of the Amazon SNS topic to which alarm status changes are to be sent. This must be in the same Region being deployed.",
"AllowedPattern" : "^arn:(aws|aws-cn|aws-iso|aws-iso-[a-z]{1}|aws-us-gov):sns:([a-z]{2}-((iso[a-z]{0,1}-)|(gov-)){0,1}[a-z]+-[0-9]):[0-9]{12}:[A-Za-z0-9/][A-Za-z0-9:_/+=,@.-]{1,256}$"
}
},
"Resources" : {
"ReadthrottleeventsthresholdexceededEmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9Alarm" : {
"Type" : "AWS::CloudWatch::Alarm",
"Properties" : {
"AlarmDescription" : "An Alarm by AWS Resilience Hub that alerts when the number of read-throttle events are greater than 1.",
"AlarmName" : "ResilienceHub-ReadThrottleEventsAlarm-2020-04-01_Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9",
"AlarmActions" : [ {
"Ref" : "SNSTopicARN"
} ],
"MetricName" : "ReadThrottleEvents",
"Namespace" : "AWS/DynamoDB",
"Statistic" : "Sum",
"Dimensions" : [ {
"Name" : "TableName",
"Value" : "Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9"
} ],
"Period" : 60,
"EvaluationPeriods" : 1,
"DatapointsToAlarm" : 1,
"Threshold" : 1,
"ComparisonOperator" : "GreaterThanOrEqualToThreshold",
"TreatMissingData" : "notBreaching",
"Unit" : "Count"
},
"Metadata" : {
"AWS::ResilienceHub::Monitoring" : {
"recommendationId" : "dynamodb:alarm:health-read_throttle_events:2020-04-01"
}
}
},
"dynamodbalarmhealthreadthrottleevents20200401EmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9AlarmSSMParameter" : {
"Type" : "AWS::SSM::Parameter",
"Properties" : {
"Name" : "/ResilienceHub/Alarm/3f904525-4bfa-430f-96ef-58ec9b19aa73/dynamodb-alarm-health-read-throttle-events-2020-04-01_Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9",
"Type" : "String",
"Value" : {
"Fn::Sub" : "${ReadthrottleeventsthresholdexceededEmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9Alarm}"
},
"Description" : "SSM Parameter for identifying installed resources."
}
},
"dynamodbalarmhealthreadthrottleevents20200401EmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9AlarmInfoSSMParameter" : {
"Type" : "AWS::SSM::Parameter",
"Properties" : {
"Name" : "/ResilienceHub/Info/Alarm/3f904525-4bfa-430f-96ef-58ec9b19aa73/dynamodb-alarm-health-read-throttle-events-2020-04-01_Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9",
"Type" : "String",
"Value" : {
"Fn::Sub" : "{\"alarmName\":\"${ReadthrottleeventsthresholdexceededEmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9Alarm}\",\"referenceId\":\"dynamodb:alarm:health_read_throttle_events:2020-04-01\",\"resourceId\":\"Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9\",\"relatedSOPs\":[\"dynamodb:sop:update_provisioned_capacity:2020-04-01\"]}"
},
"Description" : "SSM Parameter for identifying installed resources."
}
}
}
}
```
## CloudFormation テンプレートの変更
アラーム、SOP、または AWS FIS リソースをメインアプリケーションに統合する最も簡単な方法は、アプリケーションテンプレートを記述するテンプレートに別のリソースとして追加することです。以下に示す JSON 形式のファイルは、DynamoDB テーブルを CloudFormation テンプレートで記述する方法の基本的な概要を提供します。実際のアプリケーションには、追加のテーブルなど、さらにいくつかのリソースが含まれる可能性があります。
```
{
"AWSTemplateFormatVersion": "2010-09-09T00:00:00.000Z",
"Description": "Application Stack with Employees Table",
"Outputs": {
"DynamoDBTable": {
"Description": "The DynamoDB Table Name",
"Value": {"Ref": "Employees"}
}
},
"Resources": {
"Employees": {
"Type": "AWS::DynamoDB::Table",
"Properties": {
"BillingMode": "PAY_PER_REQUEST",
"AttributeDefinitions": [
{
"AttributeName": "USER_ID",
"AttributeType": "S"
},
{
"AttributeName": "RANGE_ATTRIBUTE",
"AttributeType": "S"
}
],
"KeySchema": [
{
"AttributeName": "USER_ID",
"KeyType": "HASH"
},
{
"AttributeName": "RANGE_ATTRIBUTE",
"KeyType": "RANGE"
}
],
"PointInTimeRecoverySpecification": {
"PointInTimeRecoveryEnabled": true
},
"Tags": [
{
"Key": "Key",
"Value": "Value"
}
],
"LocalSecondaryIndexes": [
{
"IndexName": "resiliencehub-index-local-1",
"KeySchema": [
{
"AttributeName": "USER_ID",
"KeyType": "HASH"
},
{
"AttributeName": "RANGE_ATTRIBUTE",
"KeyType": "RANGE"
}
],
"Projection": {
"ProjectionType": "ALL"
}
}
],
"GlobalSecondaryIndexes": [
{
"IndexName": "resiliencehub-index-1",
"KeySchema": [
{
"AttributeName": "USER_ID",
"KeyType": "HASH"
}
],
"Projection": {
"ProjectionType": "ALL"
}
}
]
}
}
}
}
```
アラームリソースをアプリケーションとともにデプロイできるようにするには、ハードコーディングされたリソースをアプリケーションスタックの動的参照に置き換える必要があります。
そこで、`AWS::CloudWatch::Alarm` のリソース定義で以下を変更してください。
```
"Value" : "Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9"
```
次のように変更します。
```
"Value" : {"Ref": "Employees"}
```
`AWS::SSM::Parameter` のリソース定義で以下を変更します。
```
"Fn::Sub" : "{\"alarmName\":\"${ReadthrottleeventsthresholdexceededDynamoDBEmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9Alarm}\",\"referenceId\":\"dynamodb:alarm:health_read_throttle_events:2020-04-01\",\"resourceId\":\"Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9\",\"relatedSOPs\":[\"dynamodb:sop:update_provisioned_capacity:2020-04-01\"]}"
```
次のように変更します。
```
"Fn::Sub" : "{\"alarmName\":\"${ReadthrottleeventsthresholdexceededEmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9Alarm}\",\"referenceId\":\"dynamodb:alarm:health_read_throttle_events:2020-04-01\",\"resourceId\":\"${Employees}\",\"relatedSOPs\":[\"dynamodb:sop:update_provisioned_capacity:2020-04-01\"]}"
```
SOPs や AWS FIS 実験の CloudFormation テンプレートを変更する場合は、ハードコードされた参照 IDs、ハードウェアの変更後も引き続き機能する動的参照に置き換えて、同じアプローチを取ります。
DynamoDB テーブルへの参照を使用して、 CloudFormation が以下を実行できるようにします。
+ まず、データベーステーブルを作成します。
+ 生成されたリソースの実際の ID を常にアラームで使用し、 CloudFormation がリソースを置き換える必要がある場合はアラームを動的に更新します。
**注記**
スタック[のネストや別のスタック](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-nested-stacks.html)のリソース出力の参照など、 で CloudFormation アプリケーションリソースを管理するためのより高度な方法を選択できます。 [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/walkthrough-crossstackref.html)(ただし、レコメンデーションスタックをメインスタックとは別にしておきたい場合は、2 つのスタック間で情報を渡す方法を設定する必要があります。)
さらに、HashiCorp の Terraform などのサードパーティツールを使用して、Infrastructure as Code (IaC) をプロビジョニングすることもできます。