AWS Certified CloudOps Engineer - Associate (SOA-C03) #2 Domain 1-1 モニタリング — CloudWatch メトリクス・アラーム・ダッシュボード

2026年5月27日水曜日

読了 8分

#1 試験の紹介で、SOA-C03 の 5 つのドメインのうち モニタリング・ロギング・復旧・パフォーマンスが 22% で最も大きい と述べました。そのドメインの出発点が CloudWatch です。CloudWatch は単なるグラフツールではなく、AWS 環境で起きるすべての出来事を数値 (メトリクス) と記録 (ログ) として受け取っておく観測レイヤー です。運用のほぼすべての対応が「CloudWatch が何かを検知する」から始まります。

この記事は、その観測レイヤーの前半である メトリクス・アラーム・ダッシュボード を扱います。ログと Logs Insights は #3 で、検知のあとの自動復旧は #4 で続けます。

メトリクス (Metric) とは何か #

メトリクスは 時間に沿って記録される数値データポイントの時系列 です。EC2 インスタンスの CPUUtilization、ELB の RequestCount、SQS キューの ApproximateNumberOfMessagesVisible がすべてメトリクスです。CloudWatch はこれらのメトリクスを次の構造でまとめます。

概念	説明	例
Namespace	メトリクスのまとまり。サービス単位で隔離	`AWS/EC2`, `AWS/RDS`, カスタムは `MyApp`
Metric name	測定項目の名前	`CPUUtilization`, `RequestCount`
Dimension	メトリクスを識別するキー・値のペア	`InstanceId=i-0abc...`, `AutoScalingGroupName=web-asg`
Resolution	データポイントの間隔	標準 60 秒、高解像度 1 秒

核心は ディメンション (dimension) です。同じ CPUUtilization でも InstanceId ごとに別々に記録され、ASG 名でまとめて見ることもできます。試験で「特定のインスタンスだけにアラームをかけたい」というシナリオは、結局 ディメンションでメトリクスを絞り込む 問題です。

標準メトリクス vs カスタムメトリクス #

区分	標準メトリクス	カスタムメトリクス
提供主体	AWS サービスが自動で公開	ユーザーが `PutMetricData` で公開
例	EC2 CPU, ELB レイテンシ	アプリケーションの応答時間、キューの滞留長
メモリ・ディスク	EC2 標準メトリクスにない	CloudWatch Agent で公開して初めて収集

試験で最もよく出る落とし穴の一つは、EC2 のメモリ使用率とディスク使用率は標準メトリクスではない という点です。ハイパーバイザーの外からは見えないからです。メモリ・ディスクをアラームで監視するには、CloudWatch Agent をインスタンスにインストールしてカスタムメトリクスとして公開する必要があります。このパターンはほぼ定番です。

アラーム (Alarm): 検知の核心 #

アラームは メトリクスが定められた条件を満たすかどうかを定期的に評価して状態を変える 仕組みです。状態は 3 つです。

状態	意味
`OK`	メトリクスがしきい値の内側にある
`ALARM`	メトリクスがしきい値を違反している
`INSUFFICIENT_DATA`	評価するデータが不足している (開始直後、データ欠落など)

アラームを作るときに決める値が正解を分けます。

Period (期間): メトリクスを集計する単位時間。例: 60 秒
Evaluation Periods (評価期間数): いくつの期間を見て判断するか
Datapoints to Alarm (アラームデータポイント数): 評価期間のうちいくつが違反すれば ALARM に行くか

たとえば Period=60s, Evaluation Periods=5, Datapoints to Alarm=3 なら、直近 5 分のうち 3 分がしきい値を超えると アラームが鳴ります。この M of N 設定は一時的なスパイクでアラームが誤作動するのを防ぐ標準的な方法で、試験によく出ます。

欠落データ (Missing Data) の処理 #

メトリクスのデータが入ってこないときにアラームがどう振る舞うかも設定します。

オプション	動作
`missing` (デフォルト)	欠落した期間を評価から無視
`notBreaching`	欠落を正常とみなす
`breaching`	欠落を違反とみなす
`ignore`	現在のアラーム状態を維持

バッチ処理のように データがまばらに入ってくるメトリクス では、この設定を誤ると、アラームがずっと INSUFFICIENT_DATA にとどまります。「間欠的なメトリクスなのにアラームが鳴らない」というシナリオの答えは、たいてい欠落データ処理オプションの調整です。

アラームの動作 (Action) #

アラームが状態を変えると、動作をトリガーできます。

SNS 通知: 最も一般的な形。メール・Slack・Lambda へ伝播
Auto Scaling ポリシー: ASG の容量を増やしたり減らしたり
EC2 動作: インスタンスの停止・終了・再起動・復旧
Systems Manager 動作: OpsItem の作成、Automation の実行

特に EC2 自動復旧 (recover) 動作は、ハードウェア障害でインスタンスが損傷したときに同じインスタンスを新しいハードウェア上で復旧します。「インスタンスがシステムステータスチェックに失敗したら自動復旧」は、StatusCheckFailed_System メトリクスアラームに復旧動作をかける定番パターンです。

複合アラーム (Composite Alarm) #

単一メトリクスアラームを複数つなげて 論理式 (AND・OR・NOT) でまとめる アラームです。

ALARM("high-cpu") AND ALARM("high-latency")

複合アラームの核心的な効用は アラームノイズ (noise) の削減 です。CPU が少し跳ねるたびに通知が来ると、運用者が鈍感になります。「CPU も高くレイテンシも高いときだけ」通知するように複合アラームでまとめれば、本当の問題のときだけ通知が行きます。「通知が多すぎて減らしたい」というシナリオの答えとしてよく出ます。

ダッシュボード (Dashboard) #

ダッシュボードは、複数のメトリクスグラフとアラーム状態を 一画面にまとめて見る 構成です。

クロスリージョン・クロスアカウント のウィジェットを 1 つのダッシュボードにまとめられる
JSON で定義され、CloudFormation・コードで再現 可能
自動更新で運用状況ボード (NOC) 用途

試験でダッシュボードそのものの比重は小さいですが、「複数のアカウント・リージョンのメトリクスを一箇所で見る」という要求の答えとして登場します。クロスアカウントの観測は、通常 CloudWatch cross-account observability を合わせて構成します。

メトリクス数学 (Metric Math) と異常検知 #

Metric Math: 複数のメトリクスを数式で結合して新しいメトリクスを作ります。たとえば「成功リクエスト率 = 成功数 / 全体数」を計算し、その結果にアラームをかけます。
Anomaly Detection: 過去のパターンを学習して正常範囲のバンドを作り、そのバンドを外れたらアラームを鳴らします。トラフィックが時間帯ごとに揺れるワークロードで、固定しきい値の代わりに使います。

「昼間・夜間のトラフィック差が大きく、固定しきい値ではアラームが不正確だ」というシナリオの答えが異常検知です。

試験での出題パターン #

EC2 の メモリ・ディスクメトリクス が見えない → CloudWatch Agent をインストール (カスタムメトリクス)
一時的なスパイクでアラームが誤作動する → Datapoints to Alarm を上げて M of N 設定
間欠的なメトリクスなのにアラームが鳴らない → 欠落データ (treat missing data) オプションの調整
通知が多すぎる → 複合アラームで条件を AND でまとめる
時間帯ごとの変動が大きくしきい値を決められない → 異常検知
システムステータスチェック失敗時に自動で復旧させたい → StatusCheckFailed_System アラーム + EC2 復旧動作

よくある落とし穴 #

1) メモリ・ディスクが標準メトリクスにあると思い込む #

EC2 標準メトリクスには CPU・ネットワーク・ディスク I/O はあっても、OS の中のメモリ使用率とファイルシステム使用率はありません。Agent が必要です。

2) Period と Evaluation Periods を混同する #

Period は「1 つのデータポイントを集計する時間」、Evaluation Periods は「いくつ見るか」です。2 つを掛けた値が実際の判断ウィンドウの長さです。

3) 複合アラームがメトリクスを直接評価すると誤解する #

複合アラームはメトリクスではなく 他のアラームの状態 を入力として受け取ります。まず単一アラームを作り、それらをまとめる順序です。

4) 高解像度メトリクスのコストを無視する #

1 秒解像度のカスタムメトリクスは標準の 60 秒よりコストが大きいです。「すべてのメトリクスを 1 秒で」のような答案は、コスト制約のシナリオでは通常は不正解です。

まとめ #

この記事で押さえたこと:

メトリクスは Namespace・Metric・Dimension・Resolution で整理される時系列。ディメンションで対象を絞る
EC2 の メモリ・ディスクは標準メトリクスではない。CloudWatch Agent でカスタムメトリクスとして公開
アラームは Period・Evaluation Periods・Datapoints to Alarm で M of N 判断。欠落データ処理オプションは別
アラーム動作は SNS・Auto Scaling・EC2 復旧・Systems Manager。EC2 自動復旧 はシステムステータスチェック失敗の定番
複合アラーム で条件をまとめてアラームノイズを削減。異常検知 で変動の大きいワークロードの動的しきい値
ダッシュボードは JSON 定義でコードとして再現可能、クロスアカウント・リージョンの統合観測

次へ: Domain 1-2 CloudWatch Logs と Logs Insights #

メトリクスで「何が起きたか」を捉えたので、次は その出来事の詳しい記録であるログ です。

#3 Domain 1-2 モニタリング — CloudWatch Logs・Logs Insights・エージェントでは、ロググループとログストリームの構造、CloudWatch Agent でログを収集する方法、ログベースのメトリクスフィルター (Metric Filter)、Logs Insights クエリで大量のログを分析する方法、そしてサブスクリプションフィルター (Subscription Filter) でログをリアルタイムに転送する構成まで整理します。