【ハンズオン】 CloudWatch メトリクスとアラームの違いを実際に触って整理してみた
はじめに
こんにちは、クラスメソッドオペレーションズの小原です。
AWS の学習を進める中で CloudWatch メトリクスとアラームの違いについて迷うことがあったため、今回は違いについて実際にハンズオンを行いながら整理していきます。
この記事では、EC2 インスタンスの CPUUtilization を題材に、次のことを確認します。
- CloudWatch・メトリクス・アラームの関係
- メトリクスで「見る」、アラームで「気づく」の違い
- 手を動かして分かったポイント
3 つの関係を整理
結論として、「CloudWatch」「メトリクス」「アラーム」は並列の比較対象ではなく、包含関係にあります。
| 名称 | 位置づけ | 一言で言うと |
|---|---|---|
| CloudWatch | AWS リソースや AWS 上のアプリケーションをリアルタイムでモニタリングするサービス全体 | 監視の「箱」 |
| メトリクス | CloudWatchで収集・追跡する、時系列のデータポイントの集まり（例：EC2 インスタンスの CPUUtilization） |
状態を見るためのデータ |
| アラーム | メトリクスをしきい値に対して継続的にモニタリングし、違反時に通知や自動アクションを行う機能 | 異常に気づくための仕組み |
EC2 インスタンス → メトリクス(CPUUtilization) → アラーム → SNS → メール通知
CloudWatch は、メトリクス、アラーム、ダッシュボードなどを通じて運用状況を可視化するサービスです。
多くの AWS サービスは、自動的に CloudWatch へメトリクスを報告します。
EC2 インスタンスのメトリクスは AWS/EC2 という名前空間にまとまっています。
メトリクスは CloudWatch の基本的な概念で、アラームはそのメトリクスを監視する機能です。
そのため、メトリクスが先にあり、アラームはメトリクスの上に作ることになります。
検証環境の準備
EC2 インスタンスの起動
検証用に、Amazon Linux 2023（Amazon Linux 2023.12.20261016）・t3.micro の EC2 インスタンスを 1 台起動します。
名前は cw-handson-ec2 とし、ネットワーク設定などはデフォルトのままです。
※ 検証専用の AWS アカウントで実施しています。
時刻はすべてローカルタイム（2026 年 10 月 21 日）です。
SNS トピックの作成
アラームの通知先として、SNS トピック cw-handson-topic を作成し、自分のメールアドレスをサブスクリプションに登録します。
メールアドレスをエンドポイントにする場合、メッセージを受信する前にサブスクリプションの確認が必要です。
登録後に届く確認メールの Confirm subscription を選んで、確認を済ませる必要があります。
ステップ 1：メトリクスで「見る」
CloudWatch コンソールの「メトリクス」→「クラシックメトリクス」で、CloudWatch メトリクス側から「EC2」→「インスタンス別メトリクス」を開きます。
インスタンス ID で絞り込むと、CPUUtilization の行が見つかります。
負荷をかけていない状態では、CPUUtilization は 0.19% でした。
CPUUtilization は、デフォルトで確認可能なメトリクスです。
EC2 インスタンスのメトリクスは、基本モニタリング（5 分ごと）と詳細モニタリング（1 分ごと）のどちらかで送られます。
今回は基本モニタリングのまま使っています。
メトリクスはデータを記録して見せてくれるもので、しきい値を超えたときに知らせる機能はアラーム側にあります。
ステップ 2：アラームで「気づく」
メトリクスのグラフからアラームを作成しました。
条件は次のとおりです。
| 項目 | 設定値 |
|---|---|
| メトリクス | EC2 インスタンス / CPUUtilization |
| 統計 | 平均 |
| 期間 | 5 分 |
| 条件 | 80 より大きい |
| データポイント | 1/1 |
| アクション | ALARM 時に SNS トピックへ通知 |
| アラーム名 | cw-handson-ec2-cpu-high |
「データポイント 1/1」は、「アラームを発生させるデータポイント数」と「評価期間数」の設定です。
「アラームを発生させるデータポイント数」は、アラームが ALARM 状態になるのに必要な違反データポイントの数、「評価期間数」は、アラームの評価時に考慮される期間の数です。
両方が同じ場合は、その数だけ連続してしきい値を超えたときに ALARM になります。
今回は 1/1 なので、1 回超えた場合に ALARM になります。
ポイント①：作成直後の INSUFFICIENT_DATA
アラームを作成してから、約 9 秒で OK になっていました。
メトリクスアラームの状態は、OK （しきい値の範囲内）、ALARM （しきい値を超えている）、INSUFFICIENT_DATA の 3 つです。
CloudWatch アラームは、作成すると INSUFFICIENT_DATA 状態で開始されます。
モニタリング対象のメトリクスが評価されるまでこの状態が続き、作成後数分以内に別の状態へ移行します。
履歴で「データ不足」から始まっていたのは、この説明のとおりです。
今回は、事前に EC2 インスタンスを起動済みで既にメトリクスデータが存在していたため、初回評価が速やかに完了したと考えられます。
また、アラームの評価範囲内のデータポイントがすべて欠落していると、欠落データの処理が missing（既定の選択肢の1つ）の場合に、アラームは INSUFFICIENT_DATA に移行します。
EC2 インスタンスのメトリクスに設定したアラームは、データポイントが欠落すると、一時的に INSUFFICIENT_DATA になることがあります。
ステップ 3：負荷をかけて変化を観察
EC2 インスタンスに EC2 Instance Connect で接続し、stress-ng で負荷をかけました。
sudo dnf install -y stress-ng
stress-ng --cpu 0 --timeout 600s
--cpu 0 は、搭載している CPU 数ぶんのワーカーを起動するオプションです。
`--timeout 600s で、10 分経過すると自動で終わります。
結果
実際の経過は次のとおりです。
| 時刻 | 内容 |
|---|---|
| 13:15ごろ | stress-ng のインストール中。CPUUtilization が約 5〜10%まで上昇（グラフのデータ点） |
| 13:20ごろ | stress-ng の実行を開始 |
| 13:20 | グラフのデータ点が約 94.5%（ツールチップの値は 94.476583048） |
| 13:22:57 | アラームが OK から ALARM に変化。同じ秒に SNS へのアクションが実行された |
| 13:22ごろ | 通知メールが届いた |
| 13:25 | グラフのデータ点が 100% |
| 13:30ごろ | 負荷の終了。CPUUtilization が約 10%まで低下 |
| 13:31:57 | アラームが ALARM から OK に変化 |
※ 13:15 と 13:30 の値は、削除前に撮ったスクリーンショットから読み取った概算です。13:20 の値と、履歴の時刻は、画面に表示された値をそのまま記載しています。
CPUUtilization は、最大 100%まで上がりました。
アラームは、メトリクスがしきい値を超えると ALARM に、しきい値の範囲内に戻ると OK になります。
また、アクションが呼び出されるのは、アラームの状態が変わったときです。
今回は、OK から ALARM に変わったときに SNS 通知が実行され、履歴でも、状態の更新とアクションの実行が同じ時刻（13:22:57）で記録されていました。
ALARM から OK に戻った 13:31:57 の行には、アクションの記録はありませんでした。
これは通知を ALARM のときだけに設定していたためです。
ポイント②：反映までのタイムラグと、想定より早かった通知
負荷をかけてから ALARM になるまでの時間は、約 3 分でした。
EC2 インスタンスの基本モニタリングでは、メトリクスが 5 分間隔で集計・送信されます。
今回はアラームの評価期間を「5 分」に設定していたため、13:20 の集計ウィンドウ（13:15〜13:20）のデータが確定して CloudWatch に取り込まれたタイミング（13:22:57）で評価が行われ、ALARM 状態へ遷移しました。
基本モニタリングでは「最大 5 分以上の遅れ」が発生するケースもありますが、負荷開始が集計ウィンドウの境目に近かったため、開始から約 3 分という比較的早いタイミングで通知を受け取ることができました。
1 分間隔のメトリクスが必要な場合は、詳細モニタリングを使います。
詳細モニタリングには追加料金がかかります。
Amazon EC2 Auto Scaling のように負荷の変動に素早く対応したい場合は、詳細モニタリングが推奨されています。
ポイント③：準備作業でも CPUUtilization は使われる
アラームを作成したあとに stress-ng をインストールしたところ、インストール中の 13:15 に、グラフが約 5〜10%まで動きました。
このときの値はしきい値の 80 を大きく下回っていたので、ALARM にはなりませんでした。
しかし、準備作業でも CPUUtilization は使われます。
アラームを作る前にインストールを済ませておくと、グラフの変化と、負荷の本番を区別しやすくなります。
比較まとめ
| 観点 | CloudWatch | メトリクス | アラーム |
|---|---|---|---|
| 位置づけ | 監視サービス全体 | データそのもの | 通知・アクションのトリガー |
| できること | メトリクス・アラーム・ダッシュボードなどによる可視化 | 状態の確認・グラフ化 | しきい値に対する継続的な監視と、通知・自動アクション |
| 使い方のイメージ | 全体の入れ物 | 自分で見に行く | 向こうから知らせてくる |
| 今回の体験 | 全体の入口 | CPUUtilization が 0.2%から 100%まで動くのをグラフで確認 | 13:22:57 に ALARM になり、同じ秒に通知が実行された |
| 課金の目安 | 機能ごと | 詳細モニタリングは追加料金あり | 料金体系は公式の料金ページで確認 |
※ 料金はリージョンによって異なり、変更される可能性があります。最新の内容は、AWS 公式の CloudWatch 料金ページで確認してください。
リソースの削除
課金を防ぐため、次の順で削除しました。
- CloudWatch アラーム
- SNS のサブスクリプションとトピック
- EC2 インスタンス（停止ではなく終了）
インスタンスを停止しても、EBS ボリュームは残り、EBS ストレージボリュームの保存には料金がかかります。
一方、インスタンスの状態が shutting-down または terminated に変わると、そのインスタンスの料金は発生しなくなります。
終了時の EBS の扱いは、ボリュームの種類によって違います。
起動時にアタッチしたルートボリュームは、デフォルトで削除されます。
一方、コンソールで起動時に追加したデータボリュームは、デフォルトで保持されます。
そのため、インスタンス終了後には EBS ボリューム一覧を確認し、不要なボリュームが残っていないかチェックすることをおすすめします。
まとめ
- CloudWatch は監視サービス全体を指し、メトリクスとアラームはその中に含まれる機能
- メトリクス は状態を「見る」ためのデータ、アラーム はメトリクスを基に「気づく」ための仕組み
- Amazon SNS のメール通知は、サブスクリプション確認（Confirm subscription）を済ませるまで受信できない
実際に検証したことで、アラーム作成直後の INSUFFICIENT_DATA から約 9 秒で OK へ遷移する挙動や、負荷開始から約 3 分で ALARM となり同秒内に SNS 通知が実行されるリアルタイムな動作を体感して整理できました。
また、インストールのような準備作業でも CPUUtilization が使われることは実際に触れてみて気づいたため、アラームを作る前にインストールを済ませておくと、変化の原因を切り分けやすくなると感じました。
参考文献
- Amazon CloudWatch とは - Amazon CloudWatch ユーザーガイド
- メトリクスの概念 - Amazon CloudWatch ユーザーガイド
- Amazon CloudWatch でのアラームの使用 - Amazon CloudWatch ユーザーガイド
- CloudWatch アラームの欠落データの処理の設定 - Amazon CloudWatch ユーザーガイド
- 推奨アラーム - Amazon CloudWatch ユーザーガイド
- CloudWatch アラームが INSUFFICIENT_DATA の状態になっている場合のトラブルシューティング方法を教えてください - AWS re:Post ナレッジセンター
- Auto Scaling インスタンスのモニタリングを設定する - Amazon EC2 Auto Scaling ユーザーガイド
- Amazon SNS トピックのサブスクリプションの作成 - Amazon Simple Notification Service デベロッパーガイド
- EC2 インスタンスの停止および開始の動作 - Amazon EC2 ユーザーガイド
- インスタンスの終了方法 - Amazon EC2 ユーザーガイド
クラスメソッドオペレーションズ株式会社について
クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。
※2026年1月 アノテーション㈱から社名変更しました。
