3行まとめ
systems、user journeys、servicesで、業務アプリケーション、重要経路、評価単位を分けて見る。
GenAI-powered failure mode assessmentの結果は、SREやアプリチームがレビューして優先順位を決める。
月額15ドルのservice単位課金、追加評価、150リソース超過、Dependency Assessmentを分けて見積もる。
最初の検証では、重要なserviceを1つ選び、policy、role、評価回数、依存関係検出の必要性を説明できる状態にする。
AWSは2026年5月28日、次世代AWS Resilience Hubを一般提供した。従来のアプリケーション単位の見方から、systems、user journeys、servicesの3階層で重要な業務経路とサービスを整理し、GenAIを使った障害モード評価や依存関係検出まで踏み込めるようになった。
導入前に見るべき中心は、AIが便利かどうかだけではない。serviceをどの粒度で切るか、AWS Organizationsで誰が全体を見て誰が修正するか、月額15ドルのservice単位課金と追加評価、150リソース超過、Automated Dependency Assessmentの追加料金をどう見積もるかが先に来る。
既存のAWS Resilience Hub利用者は、現行体験を継続しながら自分たちのペースで次世代版を採用できる。この記事では、SREやプラットフォームチームが小さく検証する前に確認したい公式情報、料金、権限、運用ループを整理する。
このテーマをもう少し広げて見るなら、Amazon QuickのMCP向けVPC接続とは：社内ツールをAIアシスタントにつなぐ前に確認すべきこと と AWS FinOps Agentプレビューとは：異常コスト調査をAIエージェント化する前に確認すべきこと も合わせて確認してください。Resilience Hubの依存関係や運用判断を、社内ツール接続やAIアシスタントの権限設計と合わせて確認できるため。
2026年5月28日に一般提供されたもの
AWSのWhat's Newでは、次世代AWS Resilience Hubが一般提供されたこと、AWS上の重要ワークロードのレジリエンスを評価し強化するためのコンソール上の中心的な場所として位置づけられていることが説明されている。更新内容は、新しいアプリケーションモデル、dependency discovery、生成AIを使ったfailure mode analysis、modular resilience policies、organization-wide reportingだ。
根拠
AWS News Blogでも同じ発表が扱われており、対象読者はSRE、開発チーム、プラットフォームエンジニアに近い。発表日は2026年5月28日で、次世代版はResilience Hubが提供されているAWS商用リージョンで利用可能とされている。地域別の最新対応状況は、AWS Capabilities by Regionや公式のリージョン表に戻って確認したい。
この記事で判断すること
この記事の主な問いは、次世代AWS Resilience Hubを使うべきかではなく、使うならどの単位で、誰の責任で、どの頻度で評価するかだ。ワークロードをservicesへ分ける粒度、central SREとアプリチームの分担、AI評価の結果を人間がレビューするルール、料金の読み替えを先に決めておくと、検証が「コンソールを触って終わり」になりにくい。
評価基準
最初の合格条件は、重大なserviceを1つ選び、resilience policy、参照するリソース、読み取り権限、月内の評価回数、dependency discoveryの必要性を説明できることだ。ここが曖昧なまま全社展開へ進むと、AI評価の結果よりも、責任分界と費用見積もりで詰まりやすい。
この記事で深掘りしないこと
旧版Resilience Hubの基本操作や、実際に障害を起こすハンズオンは扱わない。AWS公式ドキュメントは次世代版だけでも範囲が広く、What is、getting started、systems、user journeys、services、assessment、dashboard、AWS Organizations integration、migration、security、monitoring、quotasまで分かれている。この記事では導入前レビューに必要な論点へ絞る。
注意点
本稿はAmazonおよびAWSと非提携の日本語ブログによる整理であり、公式発表そのものではない。料金、対応リージョン、サポート条件は変わり得るため、導入判断の直前には必ずAWS公式ページで再確認してほしい。株式や投資判断ではなく、プロダクトと運用判断のための記事として読む前提だ。
systems、user journeys、servicesの3階層モデルをどう読むか
- 1system
事業上ひとまとまりとして守りたいアプリケーションや業務単位。
- 2user journey
ログイン、検索、決済、承認など、止まると影響が大きい利用者経路。
- 3service
評価、policy、resource source、課金を考えるdeployable unitに近い単位。
serviceを細かく切ると責任は見えやすくなる一方で数が増え、大きくまとめると原因や担当がぼやけやすくなる。
次世代AWS Resilience Hubで最初に押さえたいのは、アプリケーションの見方が変わることだ。User Guideの変更点では、旧版のapplication概念が、次世代版では評価の主単位であるserviceに対応し、servicesはsystemsの中にまとめられ、user journeysがその間の重要な経路を表すと説明されている。
これは単なる用語変更ではない。レジリエンスを「このAWSリソース群は壊れにくいか」だけで見るのではなく、「どの業務アプリケーションの、どの利用者経路が、どのサービスに支えられているか」で見るためのモデル変更だ。
systemは事業アプリケーションの単位として見る
systemは、事業上ひとまとまりとして扱うアプリケーションの単位に近い。ECサイトなら購入体験全体、社内SaaSなら顧客管理や請求管理といった業務単位が候補になる。ここをAWSアカウントやCloudFormationスタックの単位で機械的に切ると、SREが見たい可用性と事業側が守りたい体験がずれやすい。
条件
systemを決めるときは、サービスオーナー、SRE、セキュリティ、監査が同じ言葉で影響範囲を説明できるかを確認したい。障害発生時に「どのsystemが影響を受けたか」と聞かれて、AWSリソース名だけでなく、顧客や社内利用者への影響を説明できる単位にするのがよい。
user journeyは重要な利用者経路を表す
user journeyは、systemの中で守るべき重要経路を表す。ログイン、商品検索、カート投入、決済、配送状況確認、管理者承認、API経由の注文受付など、止まったときに影響が大きい流れを先に並べると、Resilience Hubの評価結果を「どのAWSリソースが危ないか」だけでなく「どの体験が危ないか」に戻して読める。
確認項目
最初の棚卸しでは、すべての画面やAPIを対象にしない。収益、法令、顧客影響、社内業務停止、復旧目標のいずれかに強く関わる経路を3つから5つ程度に絞る。Amazon Watch Japanの読者なら、2026年6月のAWS発表を追う月次まとめと同じように、対象を絞って継続更新できる単位へ落とすと扱いやすい。
serviceは課金と評価の単位にも近い
serviceは、deployable unitとして扱われる単位だ。公式ブログでは、serviceを作成するときにresilience policy、invoker IAM role、対象リージョン、resource tags、CloudFormation stack、Terraform state file、Amazon EKS cluster and namespaceなどを指定できる例が示されている。つまりserviceは評価の単位であると同時に、次世代版の料金を読む単位にも近い。
注意点
serviceを細かく切りすぎると、評価対象と月額課金の数が増える。一方で、1つのserviceに多くの機能を押し込みすぎると、障害モードの原因と対応チームが見えにくくなる。初回検証では、顧客影響が大きく、構成を説明でき、担当チームが明確なserviceを1つ選ぶのが現実的だ。
| service分割の考え方 | 向いているケース | 注意点 |
|---|---|---|
| 小さめに分ける | マイクロサービス単位で責任が明確 | service数と評価回数が増えやすい |
| 中くらいに分ける | 1つの利用者経路を複数リソースで支える | 依存関係の説明が必要 |
| 大きめに分ける | 既存アプリが密結合で段階移行したい | failure modeの原因がぼやけやすい |
GenAI-powered failure mode assessmentは何を評価するのか
単一障害点により、1か所の停止が重要経路へ波及しないかを見る。
過剰負荷で性能や可用性が崩れやすい構成になっていないかを見る。
遅延が利用者体験や復旧目標に影響する可能性を確認する。
設定ミスや設計意図とのずれがレジリエンスを下げていないかを見る。
共通依存や共有基盤により、複数要素が同時に影響を受けないかを見る。
findingは自動修復の結論ではなく、影響するuser journey、RTO、RPO、SLO、対応コストを人間が見て判断する材料になる。
次世代AWS Resilience Hubの目立つ変更は、GenAI-powered failure mode assessmentだ。ただし、これは障害を自動修復する機能として読むべきではない。公式ドキュメントでは、現在のリソース状態を読み取り、トポロジーを分析し、resilience policies、AWS Resilience Analysis Framework、AWS Well-Architectedのベストプラクティスに照らして、failure mode、重大度、理由、推奨事項を出す流れとして説明されている。
導入側の価値は、設計レビューの入口を早く作れることにある。人間が見落としやすい単一障害点、冗長性不足、依存関係、監視の穴を洗い出し、SREやアプリチームが優先順位を付ける材料にする。
5つのfailure modeを中心に見る
料金ページでは、failure mode assessmentが評価する重要なfailure modeとして、Single Points of Failure、Excessive Load、Excessive Latency、Misconfiguration、Shared Fateが挙げられている。日本語で読むなら、単一障害点、過剰負荷、過大なレイテンシ、設定ミス、共有基盤や共通依存による同時障害のような観点だ。
根拠
User Guideの「How failure mode assessments work」では、assessmentが現在のリソース構成を更新し、トポロジーを見て、ポリシーとフレームワークに照らし、Well-Architectedの信頼性ベストプラクティスを適用し、failure modeを推奨事項とともに出すと説明されている。評価範囲にはavailability、disaster recovery、dependency resilience、observabilityが含まれる。
findingsは設計レビューの入口にする
assessmentの結果は、すぐに作業チケットへ変換できるものもあれば、設計意図を確認しないと判断できないものもある。公式ブログでは、findingが何のfailure modeか、なぜそのアーキテクチャで重要か、どう直すか、どのpolicy requirementに関係するかを示すと説明している。
評価基準
findingを見たら、重大度だけでなく、影響するuser journey、RTO、RPO、SLO、対応コスト、既存ロードマップとの重複で優先順位を付けたい。例えばログイン経路の単一障害点は即対応に近いが、低頻度の管理機能の冗長化不足は、保留理由を残して次のリリース計画に入れる判断もあり得る。
assertionと人間レビューを外さない
公式ブログでは、Failure mode guidanceでassertionsを追加し、assessment中のエージェントを誘導できると説明されている。assertionsはユーザーが追加することも、エージェントが生成することもでき、評価精度を上げるために更新できる。
注意点
生成AIの評価結果は、運用判断の材料であって結論そのものではない。Mark as resolvedやMark as irrelevantを使う場合も、なぜ対応済みとしたのか、なぜ対象外としたのかを残すべきだ。監査やポストモーテムでは、結果よりも判断履歴が問われる場面がある。
dependency discoveryで見える依存関係と見落としやすい前提
依存先はhard dependencyとsoft dependencyに分け、顧客影響があるuser journeyに関係するものから確認する。
dependency discoveryは、次世代AWS Resilience Hubのもう一つの重要な変更だ。User Guideでは、AWS services、internal endpoints、third-party endpointsへの依存関係を自動的に識別し、場所と頻度を評価すると説明されている。DNS query log analysisを使い、想定外のcross-region call、重要なthird-party dependencies、インシデント時に故障要因になり得る低頻度サービスを見つける狙いがある。
これは構成図をきれいに描くための機能というより、障害波及の入口を探すための機能だ。普段の構成管理では見えていない名前解決や外部依存が見えると、DR計画や障害訓練の前提が変わる。
AWSサービス、内部エンドポイント、外部依存を分けて読む
依存関係は、全部を同じ扱いにしないほうがよい。AWSサービスへの依存、同一組織内の内部エンドポイント、SaaSや決済、認証、監視などの外部依存では、障害時の連絡先、代替策、SLA、契約、監査証跡が違う。
確認項目
検出結果を見たら、依存先を「止まると即影響が出るhard dependency」と「一部機能低下で済むsoft dependency」に分ける。初回検証では、検出された依存関係を既存の構成管理や運用台帳と照合し、差分がどこに出るかを見るだけでも価値がある。
unexpected cross-region callは障害訓練の材料になる
想定外のcross-region callは、平常時には見逃されやすい。アプリケーションが東京リージョン中心で動いているつもりでも、認証、ログ、外部API、バックアップ、監視などで別リージョンへ依存していれば、障害時の影響範囲は変わる。
上振れと下振れ
上振れは、構成図やIaCだけでは見えない依存を拾える可能性だ。下振れは、検出結果の解釈に運用者の知識が必要なことだ。すべての依存を即修正対象にすると、対応コストが膨らむ。まずは顧客影響があるuser journeyに関係する依存から確認するのがよい。
add-on料金と検出頻度を先に決める
料金ページでは、Automated Dependency Assessmentが任意のadd-onとして、serviceあたり月額10ドルで提供されると説明されている。全serviceで常時有効化する前に、どのserviceで依存関係検出が必要かを決めておきたい。
注意点
特に外部依存が多い決済、認証、通知、データ連携のserviceは候補になりやすい。一方で、構成が単純で依存先が明確な内部バッチまで初回から対象にすると、費用と運用レビューの負荷が先に増える可能性がある。
AWS Organizations統合で中央チームが見ること
delegated administratorから広く見えることと、各findingを誰が直すかは別問題として設計する。
次世代AWS Resilience Hubは、AWS Organizations統合によって、中央チームが全アカウントやリージョンを横断してresilience postureを見られる方向に寄っている。公式発表では、central teamsがresilience policiesを定義し、単一ダッシュボードから全アカウントとリージョンの姿勢を監視できると説明されている。
複数アカウント運用では便利な一方で、権限設計と責任分界が曖昧だと危ない。中央SREがpolicyを決め、アプリチームがfindingを修正し、セキュリティや監査が例外理由を見る、という分担を先に作る必要がある。
delegated administratorから全体を見る設計
公式ブログでは、AWS Organizations統合により、single delegated administrator accountからorganization-wide resilience managementが可能になり、個別アカウントへログインせずに企業全体のresilience postureを評価できると説明されている。
条件
この設計を使うなら、delegated administratorをどのアカウントに置くか、どのOUやアカウントを対象にするか、例外アカウントをどう扱うかを決めておく。全アカウント横断の可視化は強いが、対象範囲を曖昧にすると、見えていないserviceを「評価済み」と誤解するリスクがある。
invoker IAM roleと読み取り権限を先に設計する
公式ブログでは、開始前にinvoker IAM roleを設定し、Resilience HubにAWSリソースへの読み取りアクセスを付与する必要があると説明している。AWS Organizationsを使わない場合のcross-account roles、Organizationsを使う場合のservice-linked rolesにも触れられている。
確認項目
最初の検証前に、Resilience Hubがどのリソースを読めるのか、どのアカウントでロールを作るのか、読み取り権限の境界はどこかを確認したい。AI支援とクロスアカウント権限の組み合わせは、AWS MCP Serverのクロスアカウント対応記事でも同じく注意点になる。便利な横断アクセスほど、権限の最小化と監査ログを先に見るべきだ。
組織標準とアプリ例外を同時に扱う
modular resilience policiesは、availability SLO、multi-AZやmulti-Region DR、data recovery requirementsなどを組み合わせられる。中央チームが標準policyを定義しやすくなる一方で、すべてのserviceへ同じ目標を押し込むと、現実的でないfindingが増える。
注意点
policyは標準化と例外処理をセットで設計する。顧客向け決済serviceと、社内向けの低頻度管理バッチでは、RTOやRPO、multi-Region要件が違ってよい。重要なのは、例外を口頭で済ませず、なぜそのserviceでは別基準にしたのかを後から読める状態にすることだ。
| 役割 | 主に見るもの | 決めておくこと |
|---|---|---|
| 中央SRE | policy、dashboard、横断レポート | 標準policyと例外承認 |
| アプリチーム | service、finding、修正計画 | 対応、保留、irrelevantの理由 |
| セキュリティ | IAM role、監査ログ、権限境界 | 読み取り範囲と証跡 |
| 監査・管理部門 | レポート、判断履歴 | 期限、責任者、承認履歴 |
料金はapplication単位からservice単位へ読み替える
serviceを大きくまとめるか細かく分けるかは、安さだけでなく、findingの読みやすさと費用説明のしやすさで判断する。
導入判断で最も見落としやすいのが料金だ。旧版AWS Resilience Hubでは、最初の3つのassessed applicationsについて6カ月無料、その後はapplicationあたり月額15ドルという説明が料金ページにある。一方、次世代AWS Resilience Hubは、serviceの作成数、failure mode assessmentの実行数、dependency discovery assessmentを有効にするかで課金が決まる。
つまり、旧版のapplication数と、次世代版のservice数は単純に同じではない。3階層モデルへ移るなら、料金見積もりも作り直す必要がある。
旧版はapplication、新版はserviceが中心になる
料金ページでは、次世代版について、Resilience Hubでserviceを作成すると月額15ドルが課金され、150以下のリソースを持つserviceには月2回のfailure mode assessmentが含まれると説明されている。課金はservice作成時に始まり、serviceをResilience Hubから削除すると止まる。
根拠
AWSの料金ページとUser Guideのpricing transitionでは、旧版のbase feeが15ドル/application/month、次世代版が15ドル/service/monthと整理されている。User Guideでは、150以下のリソースで月2回以下のassessmentなら、多くの顧客は同じ金額になるという趣旨も示されている。ただしserviceへの分解数が増えれば、支払いの見え方は変わる。
月2回のfailure mode assessmentを超えるケースを見積もる
月2回の評価が含まれるとしても、実運用では回数が増えることがある。月次レビュー、主要リリース前、障害対応後、インフラ構成変更後、監査前の再評価をすべて同じserviceで行うなら、追加assessmentが発生し得る。
条件
料金ページでは、含まれる2回を超える追加failure mode assessmentは、assessed resourceあたり0.10ドルで、各追加assessmentには50リソース分の最小課金があると説明されている。月に何回評価するかを運用ルールとして決め、手動で何度も再実行する権限を誰に与えるかも考えたい。
150リソース超過とdependency discovery add-onを別枠にする
次世代版では、150を超えるリソースについて、failure mode assessmentごとに追加料金が発生する。またAutomated Dependency Assessmentは任意add-onで、serviceあたり月額10ドルと説明されている。
下振れ
大きなserviceほど、リソース超過と追加assessmentの影響を受けやすい。serviceを大きくまとめると月額service数は減るかもしれないが、findingの粒度が粗くなり、リソース超過や再評価の費用が読みにくくなる。逆にserviceを細かく分けると、障害モードは読みやすくなるが月額service数が増える。どちらが安いかではなく、どちらが運用上説明しやすいかで決めたい。
| 項目 | 旧版AWS Resilience Hub | 次世代AWS Resilience Hub |
|---|---|---|
| 主な課金単位 | application | service |
| 基本料金 | 月額15ドル/application | 月額15ドル/service |
| 含まれる評価 | 旧版の説明に従う | 150リソース以下なら月2回のfailure mode assessmentを含む |
| 追加評価 | 旧版料金モデルを確認 | 追加assessmentはassessed resource単位、最低50リソース分 |
| 依存関係検出 | 次世代機能ではない | Automated Dependency Assessmentは任意add-on |
| 導入前の注意 | application数を見る | service数、評価回数、リソース数を同時に見る |
既存Resilience Hub利用者はいつ移行するべきか
- 現行体験を継続する
既存の評価や監視が回っているなら、急いで止めずに運用を維持する。
- 旧applicationを棚卸しする
既存のapplicationがsystem、user journey、serviceのどこに対応するかを確認する。
- 重要経路を先に決める
ログイン、決済、検索など、守るべきuser journeyを人間側で定義する。
- 1つのcritical serviceで試す
料金、権限、finding対応、dependency discoveryの必要性を小さく検証する。
移行APIはマッピングを助けるが、業務上の重要経路や責任分界までは自動で決まらない。
既存利用者にとって大事なのは、次世代版が出たからすぐ移行しなければならない、という話ではないことだ。AWS What's Newでは、既存AWS Resilience Hub顧客は現行体験を継続し、次世代版を自分たちのペースで採用できると説明されている。
移行の判断は、新機能を使いたいか、3階層モデルへ再整理できるか、料金が読めるか、権限と運用ルールを整えられるかで決めたい。
現行体験は継続できる
現在のResilience HubでRTOやRPOを使った評価、推奨事項、継続的な監視を回している場合、その運用を止めてまで急ぐ必要はない。むしろ、次世代版のserviceモデルへ移すときに、既存のapplicationと責任分界がどう変わるかを先に棚卸ししたほうがよい。
根拠
AWS公式発表では、既存顧客が現行体験を続けられることと、移行ガイドが案内されていることが確認できる。AWS News Blogでも、既存のassessment policiesを新しいresilience policiesへ変換し、旧applicationを新しいモデルへマップするmigration APIsがあると説明されている。
移行APIとマッピングは過信しない
移行APIがあっても、業務上の重要経路や責任分界まで自動で決まるわけではない。旧applicationがそのまま新しいsystem、user journey、serviceの良い粒度になるとは限らない。
注意点
特に、複数の旧applicationを1つのsystemへまとめる場合、user journeyをどのように定義するかは人間側の設計になる。ログイン、決済、検索などの重要経路を先に決めずにマッピングだけ行うと、次世代版の良さである事業価値との接続が弱くなる。
移行を急ぎやすいケース
移行を急ぎやすいのは、複数アカウントでレジリエンス標準を作りたいチーム、手動レビューの負荷が高いチーム、外部依存の棚卸しが弱いチーム、監査向けに全体レポートを整えたいチームだ。
評価基準
一方で、単一アカウントの小さなワークロードで、既存のDR計画と構成管理が十分に回っているなら、まず料金とservice分割の検証からでよい。Amazon Cognitoのマルチリージョンレプリケーション記事のように、ログイン基盤など影響が大きい領域から検証対象を選ぶと、Resilience Hubのuser journey設計と相性がよい。
導入前チェックリスト：小さく試すならどこからか
全serviceを一度に入れるより、構成を説明できるcritical serviceで運用ルールまで試すほうが判断しやすい。
次世代AWS Resilience Hubは、全社横断で導入したくなる機能が多い。しかし初回は、重要だが構成を説明できるserviceを1つ選び、policy、role、resource source、assessmentの運用を確認するのがよい。最初から全serviceを入れると、料金、finding、例外処理が一度に増える。
最初の検証対象serviceを1つ選ぶ
候補は、本番影響が大きく、担当チームが明確で、現在の構成をCloudFormation、Terraform、resource tags、EKS clusterなどで説明できるserviceだ。未知の大規模serviceを初回対象にすると、Resilience Hubの評価以前に、構成棚卸しで止まりやすい。
条件
初回serviceは、顧客影響がある、RTOやRPOを仮でも置ける、修正担当がいる、検出されたfindingをチケット化できる、月内の評価回数を決められる、という条件を満たすものにする。
policy、role、resource sourceを先に揃える
公式ブログの例では、service作成時にresilience policy、invoker IAM role、service Regions、resource tags、CloudFormation stack、Terraform state file、EKS cluster and namespaceなどを指定する。ここを事前に準備できていないと、評価結果の前に入力条件で揺れる。
確認項目
resilience policyでは、availability SLO、multi-AZ、multi-Region disaster recovery、data recovery requirementsなど、どの要件を入れるかを決める。roleでは読み取り権限を絞る。resource sourceでは、IaCと実リソースのずれを把握する。追加料金の確認は、Cost ExplorerのAmazon Qコスト説明記事のように、AIによる説明と公式料金ページの確認を分けて見るのが安全だ。
findingsをチケット化する基準を決める
assessment後に重要なのは、findingを見て終わらせないことだ。対応、保留、irrelevantの基準を決め、判断理由を残す。Resilience Hubの画面上でMark as resolvedやMark as irrelevantを使う場合も、チケットや運用台帳との対応を作っておきたい。
評価基準
チケット化する基準は、顧客影響、user journey、RTO、RPO、SLO、対応工数、リリース予定、既存障害履歴で決める。すべてのfindingを同じ優先度にすると、重要な障害モードが埋もれる。逆にAIの指摘だからと軽く扱いすぎると、見落とし検出の価値がなくなる。
| 確認項目 | 担当 | 合格条件 | 保留条件 |
|---|---|---|---|
| service粒度 | SREとアプリ責任者 | 影響するuser journeyを説明できる | 責任者が複数で曖昧 |
| resilience policy | SRE | SLO、RTO、RPOを仮置きできる | 目標値が事業側と未合意 |
| IAM role | セキュリティ | 読み取り範囲と監査ログを確認済み | 権限境界が広すぎる |
| resource source | アプリチーム | IaCやタグと実構成を照合済み | 構成棚卸しが未完了 |
| assessment運用 | SRE | 月内回数と実行者を決定済み | 追加評価の費用が未見積もり |
| finding対応 | アプリチーム | 対応、保留、irrelevantの理由を残す | 判断履歴が残らない |
SRE運用に入れるなら、レポートより先に運用ループを作る
- 1評価する
月次レビュー、主要リリース前、障害対応後など、実行タイミングを決める。
- 2triageする
findingをuser journey、RTO、RPO、SLO、顧客影響で読み分ける。
- 3修正する
正本のチケットを決め、アプリチームが対応計画を持つ。
- 4再評価する
修正後にassessmentを実行し、改善が反映されたかを確認する。
- 5例外を承認する
受け入れるリスク、代替策、次回見直し日、承認者を残す。
organization-wide reportingが役に立つのは、未対応findingの理由と次の判断が残っている場合に限られる。
次世代AWS Resilience Hubは、organization-wide reportingやdashboardが目を引く。ただし、レポートを作る前に、評価、triage、修正、再評価、例外承認の運用ループを作るほうが大切だ。ダッシュボードに赤いfindingが並んでも、誰がいつ直すかが決まっていなければ改善にはつながらない。
月次レビューとリリース前レビューに組み込む
月次レビューでは、重要serviceのfindingを見直し、前月からの構成変更や新しい依存関係を確認する。主要リリース前には、変更対象のserviceでassessmentを実行し、リリース判断に必要なblocking findingがないかを見る。障害対応後には、再発防止策の反映を確認する。
確認項目
誰がassessmentを実行し、誰が結果を読み、誰が修正計画を承認するかを決める。月2回までの含まれるassessmentをどう使うかも、この運用ルールに含めたい。リリース前に何度も再評価する運用なら、追加assessmentの費用も予算化する。
Well-Architectedレビューとの重複を整理する
Resilience HubはAWS Well-Architectedの信頼性ベストプラクティスを参照するが、Well-Architectedレビューそのものを置き換えるわけではない。Well-Architectedは設計全体のレビューに向き、Resilience Hubは運用中のserviceを継続的に評価し、failure modeや依存関係を見つける支援として使う、と分けるとよい。
注意点
同じ指摘がWell-Architectedレビュー、Resilience Hub、監査、障害対応チケットに重複して出る可能性がある。重複を嫌って評価を減らすのではなく、どれを正本のチケットにするかを決める。SREチームが持つ運用ボードに集約し、各ツールの結果は根拠として残すのが現実的だ。
監査向けレポートの前に例外理由を残す
organization-wide reportingは、中央チームや監査にとって価値がある。ただ、レポートが有用になるのは、例外理由や保留理由が残っている場合だ。単に「未対応findingがある」だけでは、リスクを取っているのか、誤検出なのか、対応待ちなのかが分からない。
評価基準
例外理由には、影響するuser journey、受け入れるリスク、代替策、次回見直し日、承認者を残したい。これはAWSサービスに限らず、AI評価を運用判断へ入れるときの基本になる。2026年6月のAWS発表のような変化が続く時期は、一次情報リンク集で公式資料へ戻れる導線も合わせて残しておくと、後から見直しやすい。
導入判断のまとめ
複数アカウント、重要service、横断SRE、外部依存の棚卸し、監査向け説明が必要な場合。
小規模な単一アカウントで、既存のDR計画と構成管理が十分に回っている場合。
service粒度、policy、invoker role、resource source、assessment回数、dependency discoveryの必要性。
次世代版の価値は、AI評価そのものよりも、業務経路、責任分界、費用、判断履歴を継続運用へつなげられるかで決まる。
次世代AWS Resilience Hubは、レジリエンス評価を単発の設計レビューから、業務経路とservice単位の継続的な運用ループへ近づける更新だ。systems、user journeys、servicesの3階層、GenAI-powered failure mode assessment、dependency discovery、AWS Organizations統合は、複数アカウントや重要ワークロードを持つチームには強い材料になる。
一方で、導入前に見落としやすいのは料金と責任分界だ。serviceをどう切るかで月額料金とfindingの粒度が変わる。dependency discoveryは任意add-onで、追加assessmentや150リソース超過も見積もりが必要になる。AI評価の結果を誰が読み、何をチケットにし、何を例外にするかも、人間側の運用設計として残る。
すぐ試しやすいケース
複数アカウントで重要serviceを運用しており、SREやプラットフォームチームが横断的にレジリエンスを見たい場合は、検証価値が高い。手動レビューの負荷が高い、外部依存の棚卸しが弱い、監査向けに説明可能なレポートを整えたい場合も、まず1つのcritical serviceで試す理由がある。
条件
検証前に、service粒度、resilience policy、invoker role、resource source、月内assessment回数、dependency discoveryの必要性を1枚のメモにまとめる。ここまで説明できれば、コンソール上の評価結果を運用判断に変換しやすい。
まだ待ったほうがよいケース
単一アカウントの小規模ワークロードで、既存のDR計画と構成管理が十分に機能している場合は、急ぐ必要はない。特に、service分割や責任者が曖昧な段階で全体導入すると、料金とfindingの整理が先に膨らむ。
注意点
待つ場合でも、料金ページ、User Guide、AWS News Blogはブックマークしておきたい。既存Resilience Hub利用者なら、現行体験を継続しつつ、次世代版のserviceモデルへ移す候補だけを先に棚卸しするのがよい。
次に読むなら
参照した主な情報源
- AWS announces general availability of the next generation of AWS Resilience Hub
https://aws.amazon.com/about-aws/whats-new/2026/05/aws-announces-next-gen-aws-resilience-hub/
- Introducing the next generation of AWS Resilience Hub for generative AI-based SRE resilience journey
https://aws.amazon.com/blogs/aws/introducing-the-next-generation-of-aws-resilience-hub-for-generative-ai-based-sre-resilience-journey/
- AWS Resilience Hub 製品ページ
https://aws.amazon.com/resilience-hub/
- AWS Resilience Hub pricing
https://aws.amazon.com/resilience-hub/pricing/
- Next generation Resilience Hub – AWS Resilience Hub User Guide
https://docs.aws.amazon.com/resilience-hub/latest/userguide/next-gen.html
- What changes with Next generation Resilience Hub – AWS Resilience Hub User Guide
https://docs.aws.amazon.com/resilience-hub/latest/userguide/next-gen-what-changes.html
- How failure mode assessments work – AWS Resilience Hub User Guide
https://docs.aws.amazon.com/resilience-hub/latest/userguide/next-gen-how-assessments-work.html
- Dependency discovery – AWS Resilience Hub User Guide
https://docs.aws.amazon.com/resilience-hub/latest/userguide/next-gen-dependency-discovery.html
Amazon Watch JapanはAmazon.com, Inc.およびAmazon Web Services, Inc.と提携していません。Amazon、AWS、Resilience Hubなどの名称は各社の商標または登録商標です。この記事は公式情報の確認を助けるための一般的な整理であり、投資助言、法務助言、セキュリティ監査の代替ではありません。