EC2 の基本モニタリングと詳細モニタリングで CloudWatch アラームの挙動を比較してみた
はじめに
こんにちは、SOA 勉強中の山本 翔大です。
SOA を勉強する中で CloudWatch の詳細モニタリングを知りました。
今回は、基本モニタリングと詳細モニタリングの両方を使用し、メトリクスの見え方や CloudWatch アラームの挙動を比較します。
基本モニタリングと詳細モニタリングとは
CloudWatch のモニタリングには基本モニタリングと詳細モニタリングの 2 種類があります。
| 項目 | 基本モニタリング | 詳細モニタリング |
|---|---|---|
| メトリクスの送信間隔 | 5 分 | 1 分 |
| 料金 | 追加料金なし | 追加料金あり |
| デフォルト | 有効 | 無効 |
基本モニタリングでは CPUUtilization などのメトリクスが 5 分間隔で CloudWatch に送信されます。
一方、詳細モニタリングを有効にすると 1 分間隔で送信されるようになります。
やってみた
構成
以下の構成で検証を行います。
| 対象 | EC2 モニタリング | CloudWatch アラーム期間 |
|---|---|---|
| インスタンス A | 基本モニタリング | 1 分 |
| インスタンス B | 詳細モニタリング | 1 分 |
両方の EC2 に同じ条件で CPU 負荷をかけ、メトリクスの見え方やアラームの状態遷移を比較します。
通知には SNS の E メール通知を使用します。
1. SNS トピックの作成
まず CloudWatch アラームの通知先となる SNS トピックを作成します。
マネジメントコンソールから Amazon SNS を開いてください。
左メニューから「トピック」を選択し「トピックの作成」をクリックします。
- タイプ：スタンダード
- 名前：ec2-monitoring-alarm-topic
トピックの作成後、サブスクリプションを追加します。
- プロトコル：E メール
- エンドポイント：通知を受け取りたいメールアドレス
サブスクリプションを作成すると確認メールが届くので、メール内の「Confirm subscription」をクリックしてください。
ステータスが「Confirmed」になっていれば OK です。
2. EC2 インスタンスの作成
EC2 インスタンスを 2 台作成します。
設定は詳細モニタリングの有効・無効以外は同じにします。
基本モニタリング用
マネジメントコンソールから EC2 を開き「インスタンスを起動」をクリックしてください。
- 名前：basic-monitoring-test
- AMI：Amazon Linux 2023
- インスタンスタイプ：t2.micro
- キーペア：任意
- セキュリティグループ：SSH（ポート 22）を自分の IP から許可
「高度な詳細」を開き、詳細な CloudWatch モニタリングが「無効化」になっていることを確認してからインスタンスを起動してください。
詳細モニタリング用
同じ手順で 2 台目を作成します。
- 名前：detailed-monitoring-test
- AMI：Amazon Linux 2023
- インスタンスタイプ：t2.micro
こちらは「高度な詳細」で詳細な CloudWatch モニタリングを「有効化」に変更してからインスタンスを起動してください。
3. CloudWatch アラームの作成
両方の EC2 に対して CloudWatch アラームを作成します。
マネジメントコンソールから CloudWatch を開き「アラームの作成」をクリックしてください。
基本モニタリング用アラーム
「メトリクスの選択」から EC2 > インスタンス別メトリクスを選択し、basic-monitoring-test の CPUUtilization を選択します。
- 統計：Average
- 期間：1 分
- しきい値の種類：静的
- 条件：CPUUtilization >= 70 %
- 評価期間：1
- Datapoints to alarm：1/1
- 欠落データの処理：欠落データを見つかりませんとして処理
（画像では 0.7 になっていますが 70 % で作成してください）
通知設定では、アラーム状態になったときに先ほど作成した SNS トピック（ec2-monitoring-alarm-topic）へ通知するよう設定します。
- アラーム名：basic-monitoring-cpu-1min-alarm
詳細モニタリング用アラーム
同じ手順で detailed-monitoring-test の CPUUtilization に対してもアラームを作成します。
条件はすべて基本モニタリング側と同じにしてください。
- アラーム名：detailed-monitoring-cpu-1min-alarm
4. CPU 負荷をかける
両方の EC2 に接続して CPU 負荷をかけます。
接続方法は EC2 Instance Connect や SSH など任意の方法で構いません。
以下のコマンドを両方の EC2 で実行します。
for n in 1 2 3 4 5; do
echo "[$(date)] start load test: ${n}"
pids=""
for i in $(seq 1 $(nproc)); do
yes > /dev/null &
pids="$pids $!"
done
sleep 90
echo "[$(date)] stop load test: ${n}"
kill $pids
sleep 180
done
このスクリプトは 90 秒間 CPU に負荷をかけたあと 180 秒間停止する、という動作を 5 回繰り返します。
t2.micro は 1 vCPU のため nproc 分の yes プロセスを起動して CPU 全体に負荷をかけています。
合計で約 22 分かかります。
5. 結果の確認
負荷テストが完了したら CloudWatch コンソールから結果を確認します。
メトリクスの比較
CloudWatch の「メトリクス」から EC2 > インスタンス別メトリクスを開き、両方の CPUUtilization を期間 1 分で表示します。
基本モニタリング側は平均 40% 程度で安定したグラフになりました。
5 分間隔でデータが送信されるため、90 秒の CPU 負荷と 180 秒の停止が平均化され、CPU の上昇が見えにくくなっています。
一方、詳細モニタリング側は 80% 付近と約 0% が交互に表示されるグラフになりました。
1 分間隔でデータが送信されるため、負荷をかけたタイミングと停止したタイミングがはっきり見えています。
アラーム状態の比較
アラームの履歴を確認したところ、以下の結果になりました。
| 項目 | 基本モニタリング + 1 分アラーム | 詳細モニタリング + 1 分アラーム |
|---|---|---|
| ALARM 通知メール数 | 0 通 | 4 通 |
| CPU グラフの見え方 | 平均 40% で安定 | 80% と約 0% が交互 |
基本モニタリング側はアラームが 1 回も発生しませんでした。
メトリクスが 5 分間隔のため、90 秒の負荷が平均化されてしきい値の 70% を超えなかったことが原因と考えられます。
詳細モニタリング側は 5 回中 4 回アラームが発生しました。
1 分間隔でメトリクスが送信されるため、CPU の上昇を正しく検知できています。
おわりに
今回は EC2 の基本モニタリングと詳細モニタリングで、CloudWatch アラーム（期間 1 分）の挙動を比較してみました。
CloudWatch アラームの期間を 1 分に設定しても、EC2 が基本モニタリングのままだと 1 分単位の監視にはなりません。
元のメトリクスが 5 分間隔で送信されるため、短時間の負荷が平均化されてアラームが発生しないケースがあります。
EC2 の標準メトリクスを 1 分単位で評価したい場合は、詳細モニタリングを有効にする必要があります。
参考資料
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイト をぜひご覧ください。※2026年1月 アノテーション㈱から社名変更しました
