初心者向けCloudWatch入門｜EC2監視とアラート設定

AWSでEC2やLambdaを使い始めると、次に必要になるのが監視です。

アプリやサーバーは「動いたら終わり」ではなく、CPU使用率が高い、エラーが増えた、Lambdaがタイムアウトした、ログに例外が出ている、といった変化に気づける状態を作る必要があります。

この記事では、Amazon CloudWatchの基本から、EC2のCPU使用率を監視してメール通知するCloudWatchアラームの作り方までを初心者向けに整理します。

EC2監視を入口にしつつ、Lambda監視や通知設定との違いも分かるようにまとめます。

この記事で作るもの

この記事では、次の構成を作ります。

EC2

  ↓ CPU使用率などのメトリクス

CloudWatch Alarm

  ↓ しきい値を超えたら通知

Amazon SNS

  ↓ メール送信

自分のメールアドレス

具体的には、EC2インスタンスのCPU使用率が一定時間しきい値を超えたときに、メールで通知を受け取れる状態を作ります。

この記事で扱う内容は次の通りです。

CloudWatchでできること
メトリクス、ログ、アラーム、通知の違い
EC2監視、Lambda監視、通知設定の違い
EC2のCPU使用率を監視するアラーム作成手順
CloudWatchアラームでよくある失敗

CloudWatchとは

CloudWatchは、AWSリソースやアプリケーションの状態を確認するための監視サービスです。

EC2、Lambda、RDS、ECS、API Gatewayなど、AWS上で動いている多くのサービスのメトリクスやログを確認できます。

初心者のうちは、CloudWatchを次のように捉えると分かりやすいです。

メトリクス: CPU使用率、エラー数、実行時間などの数値を見る
ログ: アプリやLambdaが出力したログを見る
アラーム: 条件を決めて異常を検知する
通知: 異常が起きたときにメールなどへ知らせる

CloudWatchは単にグラフを見るためのサービスではありません。

「異常に気づく」「原因を追う」「再発防止のために監視項目を増やす」ための入口になります。

CloudWatchでできること

CloudWatchでできることは、大きく分けると次の4つです。

区分	できること	例
メトリクス	AWSリソースの数値を確認する	EC2のCPU使用率、Lambdaのエラー数、RDSのCPU使用率
ログ	アプリケーションやサービスのログを確認する	Lambdaの実行ログ、API Gatewayのアクセスログ
アラーム	メトリクスに条件を設定して異常を検知する	CPU使用率が80%以上、Lambdaエラーが1回以上
通知	アラーム状態になったときに連絡する	SNS経由でメール通知、Chatbot連携

最初に覚えるべき順番は、メトリクス、ログ、アラーム、通知です。

数値やログを見られるようになってから、しきい値を決めてアラーム化すると理解しやすくなります。

EC2監視、Lambda監視、通知設定の違い

CloudWatchは複数のAWSサービスを監視できますが、見るべきポイントはサービスごとに違います。

対象	主に見るもの	代表的なメトリクス	通知で使うもの	向いている用途
EC2監視	サーバーの負荷や状態	CPUUtilization、StatusCheckFailed	CloudWatch Alarm + SNS	CPU高騰、インスタンス異常の検知
Lambda監視	関数の実行結果	Errors、Duration、Throttles、Invocations	CloudWatch Alarm + SNS	エラー、タイムアウト、実行時間増加の検知
通知設定	誰にどう知らせるか	アラーム状態	SNS、メール、Chatbot	メール通知、Slack通知、運用連絡

EC2では、まずCPU使用率とステータスチェックを見ます。

Lambdaでは、エラー数、実行時間、タイムアウトに近いDurationを見るのが基本です。

Lambdaのタイムアウト監視を具体的に作りたい場合は、関連記事の LambdaのタイムアウトをCloudWatch Alarmで検知してメール通知する方法へ進むと理解しやすいです。

LambdaのタイムアウトをCloudWatch Alarmで検知し、メール通知する方法

AWS LambdaのタイムアウトエラーをCloudWatch AlarmとSNS通知で即時検知する方法を、コード例付きでわかりやすく解説します

EC2のCPU監視で使う主なメトリクス

EC2監視で最初に押さえたいメトリクスは次の通りです。

メトリクス	意味	初心者向けの見方
CPUUtilization	CPU使用率	高い状態が続くと処理が詰まっている可能性がある
NetworkIn	受信ネットワーク量	急増している場合はアクセス増加や不審な通信を疑う
NetworkOut	送信ネットワーク量	大量送信が続く場合は配信処理や異常通信を確認する
StatusCheckFailed	インスタンスの状態チェック失敗	1以上ならインスタンスや基盤側の異常を確認する
DiskReadBytes / DiskWriteBytes	ディスク読み書き量	I/O負荷が高い処理の確認に使う

初心者が最初に作るなら、CPUUtilizationのアラームがおすすめです。

理由は、グラフで変化が見やすく、アラームの考え方を理解しやすいからです。

EC2のCPU使用率アラームを作る前提

手順に入る前に、次の前提を確認してください。

EC2インスタンスが起動している
CloudWatchでEC2のメトリクスが表示されている
通知を受け取るメールアドレスを用意している
AWSアカウントでCloudWatchとSNSを操作できる権限がある

EC2の標準メトリクスは、基本的にCloudWatchへ自動で送られます。

ただし、メモリ使用率やディスク使用率の詳細を見たい場合は、CloudWatch Agentの導入が必要です。

この記事では、標準で扱いやすいCPUUtilizationを使います。

EC2のCPU使用率アラームを作成する手順

ここから、EC2のCPU使用率が高くなったときにメール通知するアラームを作ります。

CloudWatchを開く

AWSマネジメントコンソールにログインし、検索欄で CloudWatch を検索します。

CloudWatchの画面を開いたら、左メニューからアラームを選択します。

次に、アラームの作成をクリックします。

メトリクスを選択する

アラーム作成画面で、メトリクスの選択をクリックします。

EC2のCPU使用率を監視したいので、次の流れで選びます。

EC2を選択する
インスタンス別メトリクスを選択する
対象のEC2インスタンスを探す
CPUUtilizationにチェックを入れる
メトリクスの選択をクリックする

複数のEC2がある場合は、インスタンスIDやNameタグを見て対象を間違えないようにします。

しきい値を設定する

次に、アラーム条件を設定します。

初心者向けの例として、次のように設定します。

項目	設定例
統計	平均
期間	5分
条件	静的
しきい値	CPUUtilization が 80 より大きい
評価期間	2回中2回

この設定では、5分平均のCPU使用率が80%を超える状態が2回続いたらアラームになります。

つまり、約10分間CPUが高い状態なら通知する、という考え方です。

1回だけの急上昇で通知したくない場合は、評価期間を複数回にします。

逆に、すぐ気づきたい重要サーバーでは、期間や評価回数を短めにします。

通知先を設定する

次に、アラーム状態になったときの通知先を設定します。

CloudWatchアラームの通知には、Amazon SNSを使います。

初めて設定する場合は、次のように進めます。

通知の設定でアラーム状態を選ぶ
新しいトピックの作成を選ぶ
トピック名を入力する
通知先メールアドレスを入力する
トピックの作成をクリックする

設定後、入力したメールアドレスにSNSの確認メールが届きます。

メール内の確認リンクをクリックしないと通知は有効になりません。

アラーム名を付ける

アラーム名は、後から見て意味が分かる名前にします。

おすすめは、対象、環境、条件が分かる名前です。

ec2-test-cpu-alert

alarm-1 のような名前にすると、アラームが増えたときに何を監視しているか分からなくなります。

内容を確認して作成する

最後に、設定内容を確認してアラームを作成します。

確認するポイントは次の通りです。

対象EC2インスタンスは正しいか
メトリクスは CPUUtilization になっているか
しきい値は意図した値か
評価期間は厳しすぎないか
通知先メールアドレスは正しいか
SNSの確認メールを承認したか

作成直後は、アラーム状態がデータ不足になることがあります。

これは、CloudWatchがまだ判定に必要なデータを集めている状態です。

しばらく待って OK になれば正常です。

アラーム設定の考え方

CloudWatchアラームでは、しきい値を厳しくしすぎると通知が多くなり、ゆるすぎると異常に気づけません。

初心者は、最初から完璧なしきい値を決めようとしなくて大丈夫です。

まずは仮の値で設定し、実際のグラフを見ながら調整します。

用途	しきい値の例	考え方
学習用EC2	CPU 80%以上が10分継続	通知の仕組みを理解する
小規模Webサーバー	CPU 70%以上が10分継続	高負荷に早めに気づく
本番サーバー	CPU、ステータスチェック、メモリなど複数監視	CPUだけでなく複数条件を見る

本番運用では、CPU使用率だけで判断しない方が安全です。

ステータスチェック、ディスク、メモリ、アプリケーションログもあわせて確認します。

Lambda監視では何を見るべきか

CloudWatchはEC2だけでなく、Lambda監視でもよく使います。

Lambdaの場合は、CPU使用率ではなく、関数の実行結果を見るのが基本です。

主に確認するメトリクスは次の通りです。

メトリクス	意味	見る理由
Errors	エラー回数	関数が失敗していないか確認する
Duration	実行時間	タイムアウトに近づいていないか確認する
Throttles	実行制限回数	同時実行数の上限に当たっていないか確認する
Invocations	実行回数	想定通り呼ばれているか確認する

たとえば、Lambdaのタイムアウトを検知したい場合は、Durationがタイムアウト設定に近い状態を監視する方法があります。

また、Errorsが1回以上発生したら通知するアラームもよく使います。

CloudWatchアラームでよくある失敗

CloudWatchアラーム設定でつまずきやすいポイントを整理します。

メトリクスが取得されていない

アラームを作っても、対象メトリクスが取得されていないと判定できません。

作成直後にデータ不足になるだけなら問題ありませんが、長時間変わらない場合は設定を確認します。

確認すること

対象のEC2インスタンスが起動しているか
対象のメトリクスを選べているか
リージョンが正しいか
詳細監視やCloudWatch Agentが必要な項目を見ようとしていないか

EC2のCPUUtilizationは標準で見られますが、メモリ使用率は標準では取得されません。

メモリ監視をしたい場合は、CloudWatch Agentの設定が必要です。

通知先メールが未認証になっている

SNSでメール通知を設定すると、確認メールが届きます。

このメール内のリンクをクリックして購読確認しないと、通知は届きません。

通知が来ない場合は、まずSNSのサブスクリプションが Confirmedになっているか確認してください。

しきい値設定ミスで通知が多すぎる

しきい値が低すぎたり、評価期間が短すぎたりすると、少しの変化で通知が大量に来ます。

例

CPU使用率50%以上で毎回通知する
評価期間が1回だけ
学習用環境なのに本番並みに細かく通知する

通知が多すぎると、本当に重要な異常を見落としやすくなります。

最初はややゆるめに設定し、実際の利用状況を見て調整するのがおすすめです。

対象インスタンスを間違える

EC2が複数ある場合、インスタンスIDだけでは見分けにくいことがあります。

アラーム設定前に、Nameタグや環境名を整理しておくと間違いを防げます。

おすすめの管理

EC2に分かりやすいNameタグを付ける
本番、検証、学習用で名前を分ける
アラーム名にも対象名を入れる
不要なEC2は停止または削除する

初心者が作るべき監視セット

AWS初心者が最初に作るなら、次の監視セットがおすすめです。

段階	監視対象	内容
1	EC2	CPU使用率のアラーム
2	EC2	ステータスチェック失敗のアラーム
3	Lambda	Errorsのアラーム
4	Lambda	Durationのアラーム
5	API Gateway	5XXエラーの確認
6	全体	SNS通知先の整理

最初からすべてを完璧に監視する必要はありません。

ただし、エラーが出たときにCloudWatch Logsを確認する習慣と、重要な異常を通知する仕組みは早めに作っておくと安心です。

まとめ