はじめに
「Aurora、シングル AZ のままだよな…」「NAT Gateway、1 個しかないけどまあいいか…」
心のどこかで気づいていたのに放置していた設計上の弱点、ありませんか？
私はたくさんありました笑
2026 年 5 月 28 日に GA した Resilience Hub 次世代（v2） は、従来のルールベースを捨てて GenAI（生成 AI） マルチエージェントによる障害モード分析に切り替えた大型アップデートです。
「ルールに引っかかるか」ではなく「この構成でどんな障害シナリオが起きるか」を推論してくれます。
今回、自分の学習用 CDK スタック 4 本（ECS 3 層 / CI/CD パイプライン / インシデント Bot / ドリフト検知）を v2 に食わせて、精度・限界・実務での使いどころを検証しました。
結論から言うと：
- \$60/月（4 サービス × $15）で、放置していた弱点を 26 個の Finding として言語化してくれた
- ARC Zonal Shift や ECR タグ immutability など、最新機能の未適用まで指摘してくる
- ただし「直しても消えない Finding」がある
この記事は 2026 年 7 月時点の検証結果です。GA 直後のため、今後のサービスアップデートで挙動が変わる可能性があります。
サービスをResilience Hubに追加するだけで料金がかかります。（ \$15/サービス ）
私は6/30に検証を行いましたが、追加した4つのサービスを削除せずに7/1を迎えてしまったので、計 $120 かかりました。。。
Resilience Hub v2 とは — v1 から何が変わったか
v1の限界
v1 は「このリソースタイプにはこのベストプラクティス」というルールベースの評価でした。
チェックリスト型なので網羅的ではあるものの、リソース間の組み合わせから生じる障害シナリオは検出できませんでした。
v2（次世代）の特徴
| 観点 | v1 | v2（次世代） |
|---|---|---|
| 分析エンジン | ルールベース | GenAI マルチエージェント |
| 評価対象 | リソース単体 | リソース間の依存関係・データフロー |
| 出力 | Pass/Fail チェックリスト | 障害モード + 影響範囲 + 推奨事項 |
| 構造 | App → リソース直接紐付け | System → Service → リソース（階層化） |
| ポリシー | 固定テンプレート | モジュラーポリシー（SLO 別に定義可） |
v2 の核心は 「障害モード分析」 です。単に「マルチ AZ じゃない」と指摘するのではなく、「この構成だと AZ 障害時に何が起きて、復旧にどのくらいかかるか」まで推論します。
検証構成
今回の検証では、以前自身で作成したCDKリソースをサービスとして登録しました。
サービスリソースはCloudFormationが選べるので、それを選択してます。
対象スタック
| スタック | 構成概要 | 主要リソース |
|---|---|---|
| ecs-3tier-webapp | ECS + ALB + Aurora | Fargate / ALB / Aurora Serverless v2 |
| cicd-ecs-pipeline | Blue/Green デプロイ | CodePipeline / CodeBuild / ECR / ECS |
| incident-bot | サーバーレス通知基盤 | Step Functions / Lambda × 4 / Bedrock |
| drift-detection | IaC ドリフト検知 | Lambda / CloudFormation API / SNS |
耐障害性ポリシー定義
耐障害性ポリシー（SLO、DR（RTO/RPO）、データ復旧要件）をそれぞれ選択して目標の値をポリシーで定義することが可能です。
このポリシーはサービスごとに共有することが可能です。
本検証では、全 4 サービスに同一ポリシーを適用し、構成の違いによる Findings の差を比較しました。
具体的な設定値は以下です。
SLO: 99.9%（月間ダウンタイム約 43 分まで許容）
Multi-AZ DR: RTO 5 分 / RPO 1 分
Multi-Region DR: Pilot Light — RTO 4 時間 / RPO 1 時間
データ復旧要件: 60 分
評価結果
各サービスに対して評価を実行します。（評価自体は10～15分程度かかりました。）
画像は修正後の結果ですが、結果はこのように出力されます。
以下が、各サービスに対する評価結果のサマリになります。
| サービス | Findings | HIGH | MEDIUM | LOW | Availability SLO | Multi-AZ | Multi-Region |
|---|---|---|---|---|---|---|---|
| ecs-3tier-webapp | 9 | 4 | 2 | 3 | ACHIEVABLE | NOT_ACHIEVABLE | NOT_ACHIEVABLE |
| cicd-ecs-pipeline | 10 | 4 | 3 | 3 | ACHIEVABLE | NOT_ACHIEVABLE | NOT_ACHIEVABLE |
| incident-bot | 4 | 0 | 2 | 2 | ACHIEVABLE | NOT_ACHIEVABLE | NOT_ACHIEVABLE |
| drift-detection | 3 | 0 | 1 | 2 | ACHIEVABLE | NOT_ACHIEVABLE | NOT_ACHIEVABLE |
| 合計 | 26 | 8 | 8 | 10 |
面白いのは、サーバーレス構成ほど Findings が少ないこと。マネージドサービスに寄せると自分で管理すべき耐障害性ポイントが減るのは当然ですが、数字で可視化されると説得力があります。
Multi-AZ / Multi-Region が全て NOT_ACHIEVABLE なのは、シングルリージョン・最小構成で作った学習スタックなので想定通りです。
注目 Findings — 「なぜこれが鋭いか」
26 件の中から特に印象的だったものをピックアップします。
| サービス | Finding | 深刻度 | 一言コメント |
|---|---|---|---|
| ecs-3tier | Aurora 単一 AZ・レプリカなし | HIGH | 復旧 5〜15 分という時間感覚まで言語化 |
| ecs-3tier | ARC Zonal Shift / Autoshift 未有効化 | HIGH | v1 では出なかった最新機能の未適用指摘 |
| cicd-pipeline | NAT Gateway が単一で SPOF | HIGH | 01 で解消済み・03 に残存という差分を正確に検出 |
| cicd-pipeline | ECR ImageTagMutability MUTABLE | MEDIUM | CDK デフォルトの落とし穴。ロールバック時のリスク |
| incident-bot | Slack Webhook が唯一の通知経路 | MEDIUM | 通知ツール自体の耐障害性を問う運用設計レベルの指摘 |
| drift-detection | SNS メール通知先が 1 件のみ | LOW | 地味だが実務で確実に問題になるポイント |
この中で特に「GenAI ならではだな」と感じた 2 件を深掘りします。
ARC Zonal Shift / Autoshift 未有効化（ecs-3tier）
ARC Zonal Shift 未有効化。グレー障害時にトラフィック退避不可
これは v1 では絶対に出なかった指摘 です。
ARC Zonal Shift は 2023 年、Zonal Autoshift は 2024 年の比較的新しい機能で、「ヘルスチェックは通るが劣化している」グレー障害への対策として、ALB からの AZ 退避を自動化する仕組みです。
ルールベースでは「ALB にこの属性があるか」しかチェックできません。
GenAI は「2AZ 構成 + グレー障害シナリオ」を推論した上で「この構成には Zonal Shift が必要」と結論づけています。
Slack の単一障害点（incident-bot）
Slack Webhook が唯一の通知経路。Slack 障害時に通知不到達
インシデント通知 Bot なのに、通知経路が Slack 一本。
「インシデント対応ツール自体のインシデント耐性」 を問う、運用設計レベルの指摘です。
これはインフラ構成図を見ただけでは出てこない指摘で、「このサービスの目的（障害通知）」と「依存先の障害リスク（Slack 停止）」を組み合わせて推論しているようです。
GenAI 分析の精度評価
| 観点 | 評価 | コメント |
|---|---|---|
| 既知の弱点の検出 | ◎ | Aurora 単一 AZ、NAT GW SPOF、2AZ 配置を正確に検出 |
| 過検知（ノイズ） | △ | ECS DesiredCount=0 を HIGH 判定（デプロイ直後の一時状態） |
| 推論の具体性 | ◎ | 秒数・パーセンテージ・具体的リソース名を含む |
| アプリロジックへの踏み込み | ○ | Step Functions ループ、Bedrock タイムアウトを指摘 |
| 最新機能の認知 | ◎ | Zonal Shift / Autoshift / ATW を把握 |
唯一の過検知は DesiredCount=0 の HIGH 判定です。
今回はスタック再デプロイ直後でタスクが未起動だっただけですが、v2 は「一時的な状態」と「恒常的な設計不備」を区別できないようです。
改善 → 再評価 Before/After
評価するだけでは検証として面白くないので、実際に指摘を受けた部分について修正してみました。
適用した修正
| # | 修正内容 | 対象 Finding |
|---|---|---|
| 1 | Aurora Reader レプリカ追加（Serverless v2, scaleWithWriter） | Aurora 単一 AZ（HIGH） |
| 2 | ALB zonal_shift.config.enabled = true
|
ARC Zonal Shift 未有効化（HIGH） |
| 3 | ALB + Aurora deletionProtection: true
|
削除保護無効（LOW） |
結果の変化
| Finding | 1 回目 | 2 回目 | 3 回目 | 判定 |
|---|---|---|---|---|
| ARC Zonal Shift 未有効化 | OPEN | RESOLVED | RESOLVED | ✅ 即時反映 |
| Aurora 単一 AZ レプリカなし | OPEN | OPEN | OPEN | ⚠️ 未解消 |
| ALB + Aurora 削除保護無効 | OPEN | OPEN | OPEN | ⚠️ 未解消 |
| Aurora Serverless v2 cold start | — | — | NEW | 🆕 新規出現 |
非対称性の発見
ここが今回最も興味深かった発見です。
ALB の属性変更（Zonal Shift 有効化）は即座に RESOLVED になったのに、RDS のインスタンス追加（Reader レプリカ）と設定変更（削除保護）は 3 回評価しても RESOLVED にならない。
さらに矛盾する事象が起きています。
3 回目の評価で「Aurora Serverless v2 の minimum capacity が cold start latency を引き起こすリスク」という 新規 Finding が出現しました。これは Reader レプリカの存在を認識していないと出せない指摘です。
つまり、GenAI はリソースの追加・変更を認識して新しい Finding を生成する能力はあるが、既存 Finding の解消判定ロジックが正しく動作していない
これは GA 直後の制限事項と考えられます。
リソースタイプによって解消判定の対応状況に差があるようです。
今後のサービスアップデートで解消される可能性が高いでしょう。
GA 直後の制限と実務活用
制限事項まとめ
- 一時的な状態 vs 恒常的な設計不備を区別できない（DesiredCount=0 問題）
- リソースタイプによる解消判定の非対称性（ALB は即反映、RDS は未反映）
- Dependency Discovery はまだ発展途上（今回はオフで検証）
それでも実務で使えるシーン
1. 案件提案での客観的評価レポート
「あなたのシステムの耐障害性、第三者視点で評価しました」というレポートを $15/サービス/月で出せます。自分のレビューに加えて「AWS の GenAI もこう言ってます」と添えると説得力が全然違います。
2. CI/CD パイプライン組み込み
今回の検証では試してませんが、CLI で Assessment 実行 → Findings 取得が可能です。
デプロイ後に自動評価を走らせて「HIGH Finding が増えたらデプロイ差し戻し」というガードレールが作れます。
3. 月次レジリエンスレポート
月 2 回の評価が料金に含まれているので、「先月 vs 今月で改善した / 悪化した」を定点観測できます。
まとめ — 人間レビューはもう不要か？
正直に言うと、今回の 26 Findings のうち 「知らなかった」ものはゼロ でした。
全部「放置してた」ものです。
でも、それが価値なんです。
人間のレビューは「知っているのに指摘しない」バイアスがかかります。
「学習用だからいいか」「コスト優先だから仕方ない」と自分を納得させてしまいますが、GenAI はその忖度をしません。
とはいえ、v2 は Well-Architected レビューの代替ではなく補完 です。
- v2 が得意なこと: 網羅的なリソース走査、最新機能の未適用検出、定量的な影響分析
- 人間が得意なこと: ビジネスコンテキストを踏まえた優先度判断、「この Finding は今は対応不要」の決断
「GenAI が弱点を洗い出し、人間が優先度を決める」— この分業が、$60/月で手に入る時代になりました。
今回検証に使った CDK スタックの実装詳細は、以下の過去記事で公開しています。
- ECS 3 層 Web アプリ
- CI/CD ECS パイプライン
- インシデント Bot