AlertingとAutomatic Remediation

ゴール

CloudWatch アラームなどの正常性シグナルに対し、単なる通知で終わらず、誰が対応するか、何を実行するか、自動化してよいか、承認が必要か、いつエスカレーションするかまで設計できる状態を目指します。

1. アラーム・アラート・復旧アクションを分ける

最初に、この3つを同じものとして扱わないことが重要です。

エラー率上昇
↓
CloudWatch アラーム = ALARM
↓
運用担当へアラート
↓
担当者がランブックを実行
↓
復旧アクション

一方で、アラームから安全な自動修復へ直接つなぐ設計もあります。ALARMになったから必ず人へ通知する、または必ず自動修復する、という意味ではありません。

2. アラートには「受信後に行うこと」が必要

通知先が設定されているだけでは、実行可能な運用プロセスとは言えません。アラートには少なくとも次を対応付けます。

アラートごとに明確な対応計画、担当、エスカレーション経路を持たせます。

3. 応答方法は3段階で考える

アラームへの対応は、すべて同じ方式にする必要はありません。

例えば、対象が限定され、手順が確定し、実行結果を機械判定できる処理は自動修復の候補になります。一方、本番データ処理停止など業務判断が必要な操作では、アラートから承認を経て復旧アクションへ進む方が適切です。

自動化できることと、無条件に自動実行してよいことは別の判断です。

4. 既存の検知を運用応答へ接続する

CloudWatch アラームによる状態評価や、Amazon EventBridgeを利用したイベントルーティングの基本は既習です。

ここで重要なのは、それらをもう一度設計することではなく、検知された異常に対してどの対応方法を選ぶかを決めることです。

検知された異常
↓
その異常に対して
どの対応方法を選ぶか

例えば同じALARM状態でも、業務影響や復旧操作の安全性によって、人による対応、承認付きAutomation、完全な自動修復のどれを選ぶかは異なります。

既存の正常性シグナルを入口として、運用上の対応ポリシーを定義します。

5. 対応ポリシーに応じて処理を振り分ける

既存のイベントルーティングを利用する場合も、重要なのはAmazon EventBridgeそのものの仕組みではなく、どの条件ならどの運用応答へ進めるかです。

CloudWatch アラーム
        ↓
Amazon EventBridge
        ↓
運用上の対応ポリシー
        ↓
├─ 人による対応
├─ 承認付きAutomation
└─ 自動修復

判断材料には、障害原因を十分に判定できるか、復旧操作が確定しているか、誤実行時の影響を限定できるか、業務上の承認が必要か、などを使います。

EventBridgeを使うこと自体ではなく、同じ正常性シグナルから条件に応じて適切な運用応答を選択することが重要です。

6. Automationは復旧手順ではなく運用ポリシーと組み合わせる

Systems Manager Automationによるランブックや複数ステップ処理の基本は既習です。

ここでは、どのアラートで、どのランブックを、どの権限で、人の承認を入れるか、どの安全条件で停止するか、というアラートと自動修復を接続する設計に集中します。

同じランブックが実行可能でも、低影響で判断が確定し安全に影響を限定できるなら自動実行、高影響で業務判断が必要なら承認付き実行、原因が不確定なら人による調査、というように使い分けます。

Automationを利用できることと、自動実行してよいことは別の判断です。

7. 高影響の処理は承認付きAutomationにできる

復旧手順自体は決まっていても、本番サービス停止、データ処理停止、大規模切り替えなど、業務影響が大きい操作では人による判断を残したい場合があります。

Systems Manager Automationでは、ランブックにaws:approveを入れ、指定された承認者が承認または拒否するまで処理を一時停止できます。

アラート
↓
Automation開始
↓
aws:approve
↓
承認？
├─ はい → 復旧操作
└─ いいえ → 停止 / 人による対応

これにより、全部手作業と全部自動実行の中間を作れます。

現行仕様上の注意

aws:approveは、複数アカウント・複数リージョンのAutomation実行ではサポートされません。そのため、中央から多数アカウントへ実行しつつ承認を必須にする場合は、承認プロセスを別途設計します。

8. 完全自動修復に向くのは「判断が十分に確定した処理」

完全な自動修復では、人が確認する前にリソースへ変更が加わります。

自動修復に向く条件は、障害状態を十分に判定できること、復旧操作が決まっていること、実行結果を検証できること、影響範囲を制御できることです。

逆に、原因候補が複数ある、復旧操作による業務影響が大きい、誤判定した場合の影響が大きい場合は、人へのアラートまたは承認付きAutomationを検討します。

9. Automation実行中にも安全条件を監視できる

復旧開始時には問題がなくても、処理の途中で別の状態が悪化する可能性があります。

10台ずつ設定変更
↓
処理途中でエラー率が急増
↓
残りの対象へ変更を続けたくない

Systems Manager Automationでは、実行時にCloudWatch アラームを監視できます。指定したアラームがALARMになった場合、Automationは実行を停止します。対象を分散実行している場合は、保留中の実行もキャンセルされます。

Automation
↓
復旧処理を実行
        ↘
      安全性アラームを監視
        ↓
      ALARM
        ↓
      実行停止

復旧開始のトリガーとなるアラームと、復旧を続けてよいか判断する安全条件を分けて設計します。

10. 自動修復には実行権限も必要

EventBridgeがAutomationを開始できても、Automationが対象リソースを変更できるとは限りません。

復旧ランブックには、EC2の再起動、設定変更、リソース状態取得など、その処理に必要なIAM権限が必要です。

Systems Manager Automationは、明示的なassumeRoleを使用しない場合、Automationを開始したIAMプリンシパルのコンテキストで動作します。運用ではAutomation用のIAMサービスロールを利用し、ランブックに必要な権限だけを明示的に設計します。

11. エスカレーションは「通知先を増やすこと」ではない

エスカレーションの目的は、解決できない問題を必要な権限・知識・責任を持つ人へ引き継ぐことです。

単に通知人数を増やすのではなく、現在の担当者ではできない判断や対応を行える担当者へ引き継ぎます。

12. エスカレーション条件は自動修復にも必要

自動修復を導入しても、処理が必ず成功するとは限りません。

ALARM
↓
自動修復
↓
正常化？
├─ はい → 通常運用
└─ いいえ → エスカレーション

復旧処理の成功だけでなく、ワークロードが期待する状態へ戻ったかを確認し、未復旧なら人へ引き継げるようにします。

13. 代表的なアンチパターン

14. SAP-C02での判断フロー

既存環境でアラームは存在するものの、対応が遅い、人によって異なる、手作業の復旧がある場合は、次の順番で考えます。

アラーム発生
↓
このアラートで誰が何をするか定義済み？
│
├─ いいえ
│   ↓
│ 担当者・対応・エスカレーションを定義
│
└─ はい
    ↓
対応方法は十分に確定している？
│
├─ いいえ → 人による対応 / 調査
│
└─ はい
    ↓
自動実行しても影響を安全に制御できる？
│
├─ はい → 自動修復
│
└─ いいえ
    ↓
承認後なら実行可能？
│
├─ はい → 承認付きAutomation
│
└─ いいえ → 人による対応

複数の対応先へ条件に応じて振り分ける必要がある場合は、CloudWatch アラームの状態変更をAmazon EventBridgeから対応ポリシーへ接続する構成を検討します。

Automation実行中にも安全条件を監視したい場合は、AutomationとCloudWatch アラーム監視を組み合わせます。

自動修復失敗、承認不可、所定時間内に未復旧、想定以上の業務影響などはエスカレーションへ切り替える条件になります。

まとめ

アラートと自動修復では、アラームを作ることではなく、アラーム発生後にどの運用プロセスが動くかを設計します。

正常性シグナル
↓
CloudWatch アラーム
↓
アラート
↓
対応ポリシー
↓
┌──────────────────┐
│ 人による対応          │
│ 承認付きAutomation    │
│ 自動修復              │
└──────────────────┘
↓
復旧アクション
↓
正常化しない / 判断が必要
↓
エスカレーション

通知は対応完了ではなく、Automation開始も復旧完了ではありません。アラートごとに担当者と対応方法を決め、安全に自動化できる部分だけを自動化し、人の判断が必要な部分には承認やエスカレーションを残します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 3.1
• AWS Well-Architected Framework — Operational Excellence Pillar / Process per alert
• Amazon CloudWatch — Alarm actions
• Amazon EventBridge / AWS Systems Manager — Automationの実行
• AWS Systems Manager Automation — aws:approve
• AWS Systems Manager Automation — CloudWatch アラーム監視
• AWS Systems Manager Automation — IAMサービスロール