【AWS】CloudWatchでEC2のCPU使用率を監視！アラーム通知メールの設定手順

AWSのCloudWatchとAmazon SNSを組み合わせれば、EC2のCPU高負荷を検知して自動でメール通知を受け取る仕組みを構築可能です。EC2インスタンスを立ち上げたばかりの段階では、サーバーの停止や想定外の負荷増大に気づけないリスクがつきまとうのではないでしょうか。この記事では、CloudWatchアラームの設定手順からSNSによるメール通知、実際に負荷をかけて通知を確かめるテスト方法までを分かりやすく解説します。手順通りに進めることで、今日から安心してEC2を運用できる状態が見込めるはずです。

CloudWatchによるEC2監視の全体像と仕組み

EC2監視の基本とCloudWatchの役割

EC2運用において、CPU使用率などのメトリクス監視はシステムを安定稼働させるために不可欠な要素と言えるでしょう。サーバーへの過剰な負荷を放置すれば、サービスの遅延やシステムダウンを引き起こす原因になりかねません。AWSが提供するCloudWatchを利用すると、リソースのパフォーマンスデータを収集および監視できます。この機能を活用し、EC2のCPU使用率が一定の基準を超えた際にAmazon SNSを経由して管理者のメールアドレス宛へアラートを送信する仕組みを作ってみてください。

EC2からCloudWatch、そしてSNSを経てメールへ通知が届く一連の流れをあらかじめ構築しておくことで、異常発生時の迅速な対応が期待できます。

CloudWatch標準メトリクスでできること・できないこと

CloudWatchの標準モニタリングを活用すると、CPU使用率やネットワークトラフィック、インスタンスのステータスチェックといった基本的な項目をすぐに取得可能です。これらはEC2の基盤側であるハイパーバイザーから直接計測可能なデータとして扱われるためです。一方で、メモリ使用率やディスクの空き容量は標準機能の対象外と言えるでしょう。OS内部で管理されている指標であり、AWS側からは直接確認できない仕組みになっています。メモリやディスクの状況も監視したいのであれば、CloudWatch AgentをEC2内部にインストールし、カスタムメトリクスとして送信する追加設定が求められます。

【CloudWatch Agentによるメモリ・ディスク監視手順記事（公開予定）】

まずは標準メトリクスで把握できる範囲を理解し、必要に応じて拡張していくアプローチを検討してみてください。

基本モニタリングと詳細モニタリングの違い

CloudWatchのモニタリングには、5分間隔でデータを取得する基本モニタリングと、1分間隔の取得に対応する詳細モニタリングが存在します。取得頻度によって、異常を検知するスピードや発生するコストが変化するからです。基本モニタリングは標準で有効になっており、追加料金なしで利用できる点が特徴と言えます。初学者や個人開発の初期段階であれば、この5分間隔のデータ収集で十分に状況を把握できるのではないでしょうか。対して詳細モニタリングは、より細かい粒度でデータを可視化できる分、別途費用が発生します。

詳細な課金体系についてはAWS公式ページをあわせて確認し、要件に適したモニタリング方式を選択してみてください。

CloudWatchアラームとSNSメール通知の設定手順

ステップ1：Amazon SNSで通知先トピックとサブスクリプションを作成する

まずは通知の受け皿となるAmazon SNSの設定から進めていきます。アラームが発生した際、どこにメッセージを届けるかをあらかじめ定義しておく必要があるからです。AWSマネジメントコンソールからSNSを開き、通知をまとめるグループである「トピック（標準）」を新規作成してみてください。

続いて、作成したトピックに対して自身のメールアドレスをサブスクリプションとして登録します。ここで最も重要になるのが、登録直後に届く「AWS Notification – Subscription Confirmation」という件名の確認メールへの対応と言えるでしょう。メール本文内の「Confirm subscription」リンクをクリックして承認を完了させないと、その後の通知が一切届かない仕組みになっているため、忘れずに処理を進めておくことをおすすめします。

ステップ2：CloudWatchでEC2のCPU使用率メトリクスを選択する

通知先の準備が整ったら、CloudWatchコンソールへ移動して「アラームの作成」画面を開きます。ここからは監視対象とする具体的なデータ（メトリクス）を指定する段階に入ったと言えます。メトリクスの選択画面で「EC2」から「インスタンス別メトリクス」へと進み、対象となるEC2インスタンスの「CPUUtilization（CPU使用率）」を選んでください。

次に、取得したデータをどのように評価するかを決定します。一般的なCPU監視であれば、統計を「平均」、期間を「5分」程度に設定しておくと、一時的な負荷の跳ね上がりによる誤検知を防ぎやすくなるのではないでしょうか。

ステップ3：アラームのしきい値と条件を設定する

続いて、どの程度の負荷がかかったらアラームを発火させるのか、具体的な条件を定義していきます。しきい値の種類には「静的」を選択し、例えば「CPU使用率が80%以上」といったアラーム条件を入力してみてください。CloudWatchのアラームは、設定した条件に対して現在どのような状況にあるかを3つの状態で判定する仕組みを持っています。

メトリクスが正常な範囲内であれば「OK」、しきい値を超えて異常とみなされれば「ALARM」、データが届いていないか判定に十分な情報がない場合は「データ不足」として扱われます。今回は「ALARM」状態に移行したタイミングを検知の基準として定めておくとよいでしょう。

ステップ4：通知アクションにSNSトピックを関連付ける

最後に、アラーム状態が変化した際のアクションとして、先ほど作成したSNSトピックを紐づけます。アラーム状態トリガーを「アラーム状態（ALARM）」に指定し、通知先としてステップ1で準備した既存のSNSトピックを選択してください。

あとはアラーム名と説明（例：WebサーバーCPU高負荷アラームなど）を管理しやすいように入力するだけです。設定内容のプレビュー画面で各項目に誤りがないかを確認のうえ、「アラームの作成」ボタンを押せば、監視と通知の仕組み作りは完了となります。

アラーム動作確認！実際にCPU負荷をかけてメール通知をテストする方法

Linux/WindowsでCPU負荷テストを実行する手順

設定したアラームが正しく機能するか確認するためには、実際にEC2インスタンスへ負荷をかけてみるテストが不可欠と言えます。理論上の設定が完了していても、いざという時に通知が届かなければ意味がありません。

Linux環境であれば、ターミナルから一時的にCPU使用率を上昇させるコマンドを実行してみてください。手軽な方法として、「yes > /dev/null &」を複数回実行して意図的に負荷をかける手法が存在します。より本格的なテストを実施したい場合は、stressコマンドをインストールして利用することも視野に入るでしょう。Windows環境においては、コマンドプロンプトで無限ループ処理を走らせるか、CPU負荷テスト専用のフリーソフトを活用する手段が有効です。

ただし、負荷をかけたまま放置するとシステム全体に悪影響を及ぼしかねません。テストが完了した後は、テストが終わったら pkill yes を実行し、起動した yes プロセスをまとめて停止させ、安全な状態へ戻すよう配慮が求められます。

通知メールの受信確認とアラーム状態の推移

負荷テストを開始したら、CloudWatchコンソール上で対象アラームのステータス推移を観察してみてください。CPU使用率が設定したしきい値を超過し、指定した期間（例えば5分など）が経過すると、状態が「OK」から「ALARM」へと変化するはずです。

このステータス変更とほぼ同タイミングで、SNSに登録したメールアドレス宛に通知が送信されます。受信トレイを開き、件名や本文にアラームの詳細情報が含まれているかの確認をおすすめします。

無事に通知の到着を確認できたら、先述の手順で負荷テストのプロセスを速やかに停止させましょう。数分待機してCPU使用率が正常な水準まで低下すると、CloudWatch上のステータスも再び「OK」へと復帰する様子を視認できるのではないでしょうか。これをもって、一連の監視と通知の仕組みが正しく稼働していることの証明となります。

アラーム通知メールが届かない場合のチェックポイント

SNSサブスクリプションの承認状態（Confirm subscription）の確認

アラーム通知が届かない際、最も高頻度で発生している原因がSNSサブスクリプションの未承認と言えます。登録手順の段階で確認メールのリンクをクリックしていない場合、AWS側からの送信がブロックされたままになります。まずはAmazon SNSのコンソール画面を開き、対象サブスクリプションのステータスを確認してみてください。状態が「Pending confirmation」と表示されているならば、承認手続きが完了していません。登録したメールアドレスの受信トレイを再度確認し、メール内の承認リンクを押し込むことでこの問題は解消に向かうでしょう。

迷惑メールフォルダやメーラーのフィルター設定

サブスクリプションが正常に承認されているにもかかわらず通知を受け取れないならば、受信側のフィルター機能が影響している可能性を疑いましょう。AWSからの自動通知メールは「no-reply@sns.amazonaws.com」などの送信元アドレスから送られます。セキュリティ設定やメーラーの自動仕分けルールによって、迷惑メールフォルダへと直行してしまうケースは少なくありません。一度スパムフォルダやゴミ箱の中身を検索し、該当のアドレスからの受信を許可するルールを追加する対応をおすすめします。

CloudWatchアラームの設定値と期間の再確認

メール受信側に問題が見当たらないケースでは、CloudWatchアラームの設定自体が発火条件を満たしていないケースが挙げられます。設定したCPU使用率のしきい値が高すぎたり、評価期間（例：5分間が1回など）に及ぶ連続した負荷が発生していなかったりすると、ステータスは「ALARM」へ推移しません。設定画面でメトリクスの推移グラフと条件を照らし合わせ、意図通りに判定が行われているかチェックしてみてください。

まとめ

CloudWatchとAmazon SNSを組み合わせる仕組みは、EC2インスタンスのCPU使用率を監視し、異常時にメールで迅速な通知を受け取るための基本ツールとなります。設定手順はシンプルであり、SNSトピックの作成とメール承認を行い、CloudWatchでアラーム条件を定義した上で実際に負荷テストを実施する流れを押さえれば完了です。万が一通知が届かない際も、サブスクリプションの承認状況やメーラーのフィルター、アラームのしきい値を順に確認することで円滑に対処できるのではないでしょうか。

今回の設定でCPUの監視体制は整いましたが、サーバー運用の質をより高めるためには、標準機能では取得できないメモリ使用率やディスク空き容量の監視へステップアップしていく姿勢も大切になります。必要に応じてCloudWatch Agentの導入などを検討し、より堅牢なインフラ運用を目指してみてください。