セクション 07 · タスク 2.2 · SAP-C02-059
Centralized MonitoringとProactive Recovery
Amazon CloudWatch / アラーム / Amazon EventBridge / 正常性 検知 / 自動化された復旧 / 集中監視
ゴール
複数アカウントの正常性シグナルを中央で観測し、信頼できるアラームから安全な復旧ワークフローへ接続し、復旧結果まで再確認できるようにします。
ワークロードテレメトリ
↓
集中監視
↓
正常性検知
↓
CloudWatch アラーム
↓
復旧判断
↓
直接アラームアクション
または
Amazon EventBridge ワークフロー
↓
自動化された復旧
↓
復旧後の検証メトリクスが見えるだけでは復旧は完成しません。シグナルの意味、アラーム条件、復旧権限、アクション受け渡し、復旧後の正常性まで一続きで設計します。
1. クロスアカウントオブザーバビリティで正常性シグナルを中央化する
CloudWatch クロスアカウントオブザーバビリティでは、複数送信元アカウントのオブザーバビリティデータを監視アカウントから確認できます。
送信元アカウント A ─┐
送信元アカウント B ─┼─→ 監視アカウント
送信元アカウント C ─┘
メトリクス / ログ / トレース / アプリケーションシグナル監視アカウントから送信元アカウントのメトリクスを利用したアラームを作成できるため、中央で正常性判断を行う構成にも利用できます。
2. 監視アカウントと送信元アカウントを分ける
| ロール | 主な責任 |
|---|---|
| 送信元アカウント | ワークロードとテレメトリを保持する |
| 監視アカウント | 共有されたテレメトリを可視化し、必要なアラームを作成する |
オブザーバビリティアクセスマネージャーのSinkとリンクを利用して接続します。AWS Organizationsを利用した送信元アカウントのオンボーディングも可能です。
3. クロスアカウントオブザーバビリティにはリージョン範囲がある
クロスアカウント可観測性は同一リージョン内で構成します。
アカウント 境界
+
リージョン 境界
↓
監視アーキテクチャ1つのリンクで全リージョンのテレメトリが自動集約されるとは考えません。マルチリージョンワークロードではリージョンごとの可視性を設計します。
4. 可視性と復旧権限を分離する
監視アカウントで送信元メトリクスを確認・アラーム化できても、送信元リソースを変更する復旧権限が自動的に付与されるわけではありません。
可観測性の権限
≠
復旧権限復旧には対象アカウント / リージョンのIAMロール、リソース権限、実行権限を別途設計します。
5. アラームはテレメトリを復旧判断可能な正常性状態へ変換する
CloudWatch アラームはメトリクスを継続評価し、OK / ALARM / INSUFFICIENT_DATAへ変換します。
メトリクス
↓
しきい値
+
評価 期間
+
アラームを評価するデータポイント数
↓
正常性状態復旧自動化では単発急増ではなく、ビジネス影響を十分早く、かつ安定して検知する条件を設計します。
6. 不足データはメトリクス 意味に合わせる
不足データは一律に障害でも正常でもありません。CloudWatch アラームでは、breaching、notBreaching、ignore、missingから扱いを選択できます。
| メトリクスの性質 | 判断例 |
|---|---|
| 正常時も継続送信するハートビート | 欠損自体を障害シグナルとして評価する候補 |
| エラー発生時だけ値が出るメトリクス | 欠損を正常側として扱う候補 |
7. 監視アカウント内の複合アラームでクロスアカウントシグナルを集約する
送信元アカウントのメトリクスをOAMで共有し、監視アカウント側にメトリクスアラームを作成できます。複合アラームが参照する基盤となる アラームオブジェクトは、複合アラームと同じアカウント・同じリージョンに置きます。
送信元 A メトリクス ─┐
送信元 B メトリクス ─┼─ OAM → 監視アカウント
送信元 C メトリクス ─┘
↓
メトリクスアラーム A / B / C
↓
複合アラーム
↓
復旧判断つまり「クロスアカウント複合アラーム」を作るのではなく、クロスアカウントメトリクスを監視する監視アカウント内アラームを、同アカウント / リージョンの複合アラームで集約します。送信元アカウントに存在するアラームオブジェクトをアカウント越しに直接参照する構成ではありません。
8. 複合アラームでノイズと誤復旧を抑える
1つのメトリクスだけでは障害を正確に表せない場合があります。
高エラー率
AND
低い 正常キャパシティ
↓
複合アラーム複数シグナルを組み合わせることで、一時的な単一アラームだけで復旧が起動することを抑制できます。
9. 計画済み変更ではアクション抑制を利用する
デプロイやメンテナンス中の想定内アラームで復旧を起動すると、変更と復旧が競合する場合があります。複合アラームのサプレッサーアラームを使うと、検知は維持しながらアクションを抑制できます。
アプリケーションアラーム = ALARM
+
メンテナンス用サプレッサーアラーム = ALARM
↓
アクション抑制中10. 直接アラームアクションとEventBridge ワークフローを使い分ける
単純な復旧ならCloudWatch アラームから直接アクションを実行できます。
| 方式 | 候補 |
|---|---|
| 直接アラームアクション | Lambda / SNS / EC2 アクション / Auto Scaling / Systems Manager OpsItem・インシデント |
| イベント駆動 ワークフロー | EventBridge → Lambda / 手順 機能 / Systems Manager 自動化 / 実行 コマンドなど |
複数イベント送信元、条件分岐、複数対象、オーケストレーションが必要ならEventBridgeを利用します。
11. アラームアクションの多くは状態切り替え時に実行される
CloudWatch アラームアクションの多くは、例えばOK → ALARMの状態切り替え時に実行されます。
OK
↓ 状態切り替え
ALARM
↓
アクションALARM状態が続く間、毎評価 期間同じアクションを自動実行し続けるものとして設計しません。継続再試行やエスカレーションが必要ならワークフロー側へ持たせます。Auto Scalingアクションには異なる動作があります。
12. アラーム状態変更をEventBridgeでワークフローへ渡す
CloudWatch アラームの状態変更はEventBridgeへ送信されます。
CloudWatch アラーム
↓
状態変更イベント
↓
Amazon EventBridge
↓
ルール
↓
復旧対象検知と復旧ワークフローを疎結合にし、サービスやアカウントを跨ぐ自動化へ接続できます。
13. イベント受け渡しと復旧成功を分離する
EventBridgeにイベントが届いたことと、復旧対象が成功したことは別です。
EventBridge
↓
対象
├─ 成功
└─ 障害
↓
再試行
↓
DLQ復旧処理は重複受け渡しでも安全になるよう冪等性を考慮し、受け渡し障害には再試行 / DLQを設計します。
14. 復旧アクション後に正常性を再評価する
自動化実行が成功でも、ビジネスサービスが復旧したとは限りません。
正常性検知
↓
復旧アクション
↓
復旧後の正常性検証
↓
正常?
├─ はい → 通常 運用
└─ いいえ → 次 復旧 / エスカレーションアクション実行済み ≠ 復旧成功として扱います。
15. AWS Healthイベントを事前予防的シグナルとして使う
ワークロードメトリクスだけでなく、AWS Healthのスケジュールされた変更、必要なアクション、リソース影響も復旧判断の入力になります。
AWS Healthイベント
↓
Amazon EventBridge
↓
影響を受けるリソースを特定
↓
メンテナンス / 移行 / 復旧ワークフローユーザーが認識できる障害が発生する前に対応できる場合があります。
16. 組織ビューで正常性イベントを中央判断する
AWS OrganizationsではAWS Healthの組織ビューを利用し、管理アカウントまたは委任管理者から組織内アカウントの正常性イベントを集約できます。
アカウント A 正常性イベント ─┐
アカウント B 正常性イベント ─┼→ 組織ビュー
アカウント C 正常性イベント ─┘
↓
中央判断
↓
EventBridgeアカウント固有のスケジュールされた変更や必要なアクションを中央運用へ集約し、組織全体のワークフローへ接続できます。
17. 重要度はしきい値ではなくビジネス上の意味を標準化する
中央監視で重要なのは、全ワークロードへ同じしきい値を強制することではありません。
ワークロード A
エラー率 > 5%
→ 重要
ワークロード B
正常キャパシティ < 2
→ 重要
重要
=
同程度のビジネスへの影響ワークロード特性に応じてメトリクス / しきい値は変えてよい一方、同じ重要度が同じビジネス上の意味を持つようにします。
18. ローカル自己修復と中央監視を併存させる
中央化のためにサービス-ネイティブ復旧をすべて中央ワークフローへ移す必要はありません。
| レイヤー | 主な責任 |
|---|---|
| ローカル / サービス-ネイティブ復旧 | Auto Scalingやサービス固有の高速自己修復 |
| 中央監視 | クロスアカウント可視性、インシデント判断、重要度統一 |
| 中央自動化 | 複数アカウント / サービスを跨ぐ復旧オーケストレーション |
監視アカウントが一時的に利用できなくても、送信元ワークロードのローカル自己修復まで止まる依存を不要に作らないことが重要です。
19. 事前予防的復旧の判断フロー
ビジネス継続性要件
↓
正常性シグナル
├─ メトリクス
├─ ログ由来のシグナル
├─ 依存関係シグナル
└─ AWS Healthイベント
↓
クロスアカウント可視性
↓
アラーム条件
├─ しきい値 / N個中M個
├─ 不足データ
└─ 複合条件
↓
メンテナンス / 抑制設定の確認
↓
直接アクションまたはEventBridgeワークフロー
↓
復旧アクション
↓
復旧後の検証
↓
正常?
├─ はい → 通常 運用
└─ いいえ → エスカレーション / 次 復旧20. 混同ポイント
| 混同 | 正しい判断 |
|---|---|
| OAM リンク = 復旧権限 | オブザーバビリティと復旧 IAMを分離する |
| 1 リンクで全リージョンを監視 | リージョン範囲を考慮する |
| 送信元アカウントのアラームを中央複合が直接参照 | 送信元メトリクスを監視アカウント側でアラーム化して組み合わせる |
| 不足データ = 常に障害 | メトリクス 意味に合わせる |
| ALARM中は毎期間アクション実行 | 多くのアクションは状態切り替え時。継続処理はワークフローで設計する |
| イベント受け渡し = 復旧成功 | 対象実行と復旧後の正常性を別に確認する |
| 集中化 = ローカル自己修復削除 | ローカル復旧と中央可視性 / オーケストレーションを分離する |
| 重要度標準化 = しきい値統一 | 重要度が表すビジネス影響を統一する |
21. まとめ
- CloudWatch クロスアカウントオブザーバビリティで送信元アカウントのテレメトリを監視アカウントへ共有できる。
- 監視アカウントでは送信元メトリクスを利用したアラームを作成できるが、復旧権限は別に設計する。
- クロスアカウント可観測性はリージョン範囲を持つ。
- 評価 期間、アラームを評価するデータポイント数、不足データの扱いをシグナルの意味に合わせる。
- 複合アラームは監視アカウント内のアラームを組み合わせ、ノイズや誤復旧を減らす。
- メンテナンス時はサプレッサーアラームでアクションを抑制できる。
- 直接アラームアクションとEventBridge ワークフローを復旧複雑さに応じて使い分ける。
- 多くのアラームアクションは状態切り替え時に実行される。
- EventBridge 受け渡しと復旧成功は別であり、再試行 / DLQ / 冪等性を設計する。
- 復旧後は正常性を再評価し、未復旧ならエスカレーションする。
- AWS Healthの組織ビューで複数アカウントの正常性イベントを中央判断できる。
- 重要度は同じしきい値ではなく同じビジネス上の意味を持つよう標準化する。
- ローカル自己修復と中央監視 / 自動化は責任を分けて併存させる。
22. 主要AWS公式資料
理解確認
このページの内容を15問で確認します。
理解確認15問へ →