AWS未経験が実務を想定してWebサーバ検証環境を構築してみた③ CloudWatchでEC2の基本監視を確認

はじめに

前回は、EC2の停止・起動後の挙動や、Security GroupによるHTTP通信の許可・遮断を確認しました。

今回は、作成したEC2 WebサーバをCloudWatchで監視する方法を確認します。

実務では、サーバを構築して終わりではなく、稼働状態を確認できることが重要になります。

今回は費用を抑えるため、CloudWatchアラームや詳細モニタリングは設定せず、標準メトリクスの確認まで行いました。

今回の目的

今回の目的は、EC2の基本的な状態をCloudWatchで確認することです。

確認した項目は以下です。

• CPU使用率
• ネットワーク受信量
• ネットワーク送信量
• ステータスチェック失敗の有無

EC2上でWebページが表示されていても、実務ではCPU負荷やネットワーク通信、ステータスチェックの状態を確認する必要があります。

そのため今回は、EC2コンソールのモニタリング画面とCloudWatchのメトリクス画面の両方を確認しました。

検証対象

前回までに作成したEC2 Webサーバを使用します。

項目	内容
EC2名	handson-web-ec2
AMI	Amazon Linux 2023
Webサーバ	Apache
表示内容	Hello AWS
監視サービス	Amazon CloudWatch
モニタリング	標準モニタリング

費用を抑えるために実施しなかったこと

今回は無料枠が使えない環境のため、追加課金や管理対象の増加を避ける方針にしました。

そのため、以下は実施していません。

項目	今回の扱い
CloudWatchアラーム	作成しない
詳細モニタリング	有効化しない
CloudWatch Agent	設定しない
CloudWatch Logs	設定しない
CloudWatch Dashboard	作成しない

今回は、EC2標準メトリクスの確認に絞ります。

本番環境では、CPU使用率やステータスチェック失敗などに対してCloudWatchアラームを設定し、異常時に通知を受け取る構成が必要になります。

EC2コンソールのモニタリング確認

まず、EC2コンソールからモニタリング情報を確認しました。

→ インスタンス
→ handson-web-ec2 を選択
→ モニタリング

この画面では、EC2に関する基本的なメトリクスを確認できます。

主に確認した項目は以下です。

メトリクス	確認内容
CPU使用率	CPU負荷が異常に高くないか
ネットワーク受信	EC2に入ってくる通信量
ネットワーク送信	EC2から外へ出ていく通信量
ステータスチェック	EC2またはAWS基盤側の異常がないか
CPUクレジット	t3系インスタンスのバースト性能に関する値

今回の検証環境は Hello AWS を表示するだけの簡単なWebサーバのため、CPU使用率はかなり低い状態でした。

これは異常ではなく、アクセス量や処理負荷が小さいためです。

CloudWatchのメトリクス確認

次に、CloudWatchの画面からEC2メトリクスを確認しました。

AWSコンソール上部の検索バー
→ CloudWatch
→ メトリクス
→ すべてのメトリクス
→ EC2
→ インスタンス別メトリクス

対象のEC2インスタンスを選択し、以下のメトリクスを確認しました。

メトリクス	意味
CPUUtilization	CPU使用率
NetworkIn	EC2に入ってきた通信量
NetworkOut	EC2から外に出た通信量
StatusCheckFailed	ステータスチェック失敗の有無

EC2コンソールのモニタリング画面も、裏側ではCloudWatchのメトリクスを利用しています。

そのため、EC2コンソールから確認する方法と、CloudWatchから直接確認する方法の両方を知っておくと、障害調査時に使い分けやすくなります。

CPUUtilizationの確認

まず、CPUUtilization を確認しました。

CPUUtilization はEC2のCPU使用率を表します。

今回のWebサーバは、Apacheで簡単な文字列を表示しているだけのため、CPU使用率は低い状態でした。

CPU使用率が低いこと自体は問題ありません。

一方で、実務では以下のような状態に注意が必要です。

• CPU使用率が常に高い
• 急にCPU使用率が上昇した
• アクセス数が少ないのにCPU使用率だけ高い
• CPU使用率が高く、Webサイトの応答が遅い

このような場合は、アクセス増加、アプリケーション処理の問題、バッチ処理、異常プロセスなどを確認する必要があります。

NetworkIn / NetworkOutの確認

次に、NetworkIn と NetworkOut を確認しました。

メトリクス	内容
NetworkIn	EC2に入ってくる通信量
NetworkOut	EC2から外に出ていく通信量

ブラウザからEC2のパブリックIPv4アドレスへアクセスすると、EC2にリクエストが届きます。

そのため、NetworkIn に通信が発生します。

また、EC2はブラウザに対してHTMLを返すため、NetworkOut にも通信が発生します。

今回の検証では、Webページへアクセスした際にネットワーク通信が発生していることを確認しました。

実務では、Webサイトにアクセスできない場合に、ネットワーク通信が発生しているかを確認することで、原因切り分けの材料になります。

例えば、以下のような見方ができます。

状況	考えられること
NetworkInがほぼない	リクエストがEC2まで届いていない可能性
NetworkInはあるがNetworkOutが少ない	EC2側で応答できていない可能性
NetworkIn / NetworkOutが急増	アクセス増加や異常通信の可能性

StatusCheckFailedの確認

次に、StatusCheckFailed を確認しました。

StatusCheckFailed は、EC2のステータスチェックに失敗していないかを確認するメトリクスです。

今回の検証では、ステータスチェックに問題がないことを確認できました。

実務では、Webページが表示されない場合に、まずEC2自体が正常かを確認する必要があります。

ステータスチェックに失敗している場合、以下のような原因が考えられます。

• EC2インスタンス内部の異常
• AWS基盤側の問題
• OSの起動不良
• ネットワーク到達性の問題

ブラウザでWebページが表示されない場合でも、原因がApacheやSecurity Groupとは限りません。

そのため、EC2のステータスチェックを確認することは重要です。

EC2コンソールとCloudWatchの使い分け

今回、EC2コンソールのモニタリング画面とCloudWatchのメトリクス画面の両方を確認しました。

それぞれの使い分けは以下のように整理できます。

画面	使い方
EC2のモニタリングタブ	対象EC2の状態をすぐ確認する
CloudWatchメトリクス	複数メトリクスを選択して詳しく確認する
CloudWatchアラーム	異常時に通知を受ける
CloudWatch Dashboard	複数リソースを一覧で監視する

今回は費用を抑えるため、CloudWatchアラームやDashboardは作成しませんでした。

ただし、実務では毎回EC2やCloudWatchを検索して確認するのは非効率です。

そのため、よく使うAWSサービスをお気に入りに登録したり、CloudWatch Dashboardを作成して監視項目をまとめたりすることが多いです。

今回の学習環境では、まず以下をお気に入りに追加しておくと確認しやすくなります。

• EC2
• VPC
• CloudWatch
• Billing and Cost Management
• IAM

障害時の確認観点

今回確認したCloudWatchメトリクスは、障害時の切り分けにも使えます。

Webページが表示されない場合、以下のように確認できます。

ブラウザで表示されない
↓
EC2は起動しているか
↓
ステータスチェックは成功しているか
↓
CPU使用率が異常に高くないか
↓
NetworkIn / NetworkOut に通信があるか
↓
Security GroupでHTTP 80番は許可されているか
↓
Route TableやInternet Gatewayは正しく設定されているか
↓
Apacheは起動しているか

第2章ではSecurity Groupによる通信制御を確認しました。

今回の第3章では、CloudWatchを使ってEC2の状態や通信量を確認しました。

これにより、ネットワーク設定だけでなく、監視情報からも原因を切り分ける考え方を学べました。

今回学んだこと

今回の検証を通じて、以下を学びました。

• EC2のモニタリングタブで基本メトリクスを確認できる
• EC2コンソールのモニタリング画面はCloudWatchメトリクスを利用している
• CloudWatchからEC2のメトリクスを直接確認できる
• CPUUtilizationでCPU使用率を確認できる
• NetworkIn / NetworkOutで通信量を確認できる
• StatusCheckFailedでEC2の異常有無を確認できる
• 費用を抑える場合は、まず標準メトリクス確認だけでも学習になる
• 実務ではアラームやDashboardを使い、異常に気づける仕組みを作る必要がある

実務観点での気づき

今回の検証で、EC2が起動してWebページが表示されているだけでは、運用としては不十分だと感じました。

実務では、CPU使用率、ネットワーク通信量、ステータスチェックなどを確認し、異常が起きていないかを把握する必要があります。

また、本番環境では人が毎回CloudWatchを見に行くのではなく、CloudWatchアラームや通知によって異常を検知できる仕組みを作ることが重要です。

今回は費用を抑えるためアラーム作成までは行いませんでしたが、今後の検証で通知設定も確認したいと思います。

コスト対策

今回も、確認後は不要な課金を避けるためEC2を停止しました。

EC2を停止するとインスタンス利用料は止まりますが、EBSボリュームの料金は残ります。

そのため、今後使わないEC2については、最終的に終了する必要があります。

次回

次回は、料金確認とリソース棚卸しを行います。

無料枠が使えない環境のため、次の構築に進む前に、現在残っているリソースと料金発生ポイントを整理します。

確認予定の内容は以下です。

• EC2停止状態の確認
• EBSボリュームの確認
• Security Groupの確認
• VPC関連リソースの確認
• AWS Budgetsの確認
• 不要リソースの削除判断