APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

トップ > AWS > 【AWS】ハンズオン「サーバーのモニタリングの基本を学ぼう」（CloudWatch）にチャレンジ！(後編)

【AWS】ハンズオン「サーバーのモニタリングの基本を学ぼう」（CloudWatch）にチャレンジ！(後編)

AWS 学習

目次

はじめに

こんにちは、クラウド事業部の木幡です。

「AWS Hands-on for Beginners 監視編」やってみたブログの後編です。

前編では、メトリクスの確認、アラーム設定、そしてログ分析までを行いました。
後編では、それらの情報を集約して「監視ダッシュボード」を作成し、さらにシステムの状態変化（イベント）を検知する設定を行っていきます。

どんなひとに読んで欲しい

  • AWS SAAの認定試験を勉強中で、CloudWatchの実践的な理解を深めたい人
  • AWSを使い始めたけれど、「監視」と言われても何から手をつければいいか分からない人
  • EC2インスタンスは立てたことがあるけど、CloudWatchのコンソールはあまり触ったことがない人
  • 公式ハンズオンの動画や資料は見たものの、一人で実践するのが少し不安な人

前提

この記事は、AWS公式のハンズオン資料「AWS Hands-on for Beginners 監視編」を基に、私の学習体験をまとめたものです。
ハンズオンでは、以下の図のような一般的なWebシステムの構成を、CloudFormationテンプレートを使って自動で構築します。

構成図

  • VPC内にMulti-AZ(1a, 1c)で構成されています。

  • ALB(Application Load Balancer)がパブリックサブネットに配置され、トラフィックを2台のEC2インスタンスに振り分けます。

  • データベース(RDS)もMulti-AZで、プライベートサブネットに配置されています 。

  • まさにSAAの試験対策で学ぶ、耐障害性とセキュリティを考慮した基本的な構成です。
    この構成を「監視する」という体験ができるのは、非常に実践的だと感じました。

手順

[ハンズオン⑤]：WordPressの監視ダッシュボード作成

いよいよ集大成です。
これまで見てきた「メトリクス」「アラーム」「ログ分析結果」を、1つの画面にまとめて可視化します 。

1.CloudWatchコンソール操作

  • 「ダッシュボード」→「ダッシュボードの作成」をクリック。

2.ダッシュボード名: WordPress_dashboard と入力し、作成

3.「ウィジェットの追加」画面が表示

4.ウィジェット1：EC2のCPU（メトリクス）

  • 「折れ線」を選択 → 「メトリクス」を選択。

  • AWS/EC2 → インスタンス別メトリクス から、2台のEC2インスタンス（WebServer01とWebServer02）の CPUUtilization を両方選択します。

  • 「ウィジェットの作成」をクリック。
    　これで、2台のEC2のCPU使用率が1つのグラフにまとまりました。

5.ウィジェット2：ディスク使用率（アラーム）

  • 「ウィジェットの追加」→「アラーム」を選択。

  • ハンズオン②で作成した monitoring-1-alarm を選択し、「ウィジェットの作成」をクリック。
    これで、ダッシュボードを見るだけでディスクアラームが「OK」なのか「ALARM」なのかが一目で分かります。

6.ウィジェット3：アクセスログ分析（Logs Insights）

  • 「ウィジェットの追加」→「クエリの結果」を選択 。

  • Logs Insightsの画面に切り替わるので、wordpress_access_log を選択し、ハンズオン④で実行したクエリを再度貼り付けます。

  • 「クエリの実行」を行い、結果が表示されたら「ウィゲストの作成」をクリック。

7.完成！

3つのウィジェット（EC2 CPUグラフ、ディスクアラーム、ログ分析結果）が並んだ WordPress_dashboard の完成図

  • ウィジェットはドラッグ＆ドロップで自由に配置変更できます。
    自分だけの「WordPress監視ダッシュボード」が完成しました。

[このハンズオンでの学び]

ダッシュボードの威力を体感しました。
これぞ「監視の単一ペイン（Single Pane of Glass）」です 。

メトリクス（数値）、アラーム（状態）、ログ（分析結果）という異なる種類の情報を、1つの画面に集約できるCloudWatchダッシュボードは非常に強力だと感じました 。

[ハンズオン⑥]：EC2インスタンス停止時の通知

次は、メトリクス（数値）ではなく、「イベント（出来事）」をトリガーにした通知です。

1.EventBridgeルールの作成

※注意点: ハンズオン資料は2020年のもので、「CloudWatch Events」と記載されています。
しかし、現在（2025年）コンソールで「CloudWatch Events」は無く、「Amazon EventBridge」で行う必要があります。

EventBridgeのコンソール画面

SAAの勉強でも「CloudWatch EventsはEventBridgeに統合された」と学びましたが、まさにそれを体感しました。
サービスが進化しても、基本的な概念（イベントをルールで拾ってターゲットに渡す）は同じです。

  • Amazon EventBridgeコンソールで、「ルール」→「ルールを作成」をクリック。

  • 名前: monitoring-1-event-rule

2.イベントパターンの定義

  • イベントソース: 「AWS のイベントまたは EventBridge パートナーイベント」

  • イベントパターン:

    • イベントソース: 「AWS サービス」
    • AWS サービス: EC2
    • イベントタイプ: EC2 Instance State-change Notification

  • 特定の状態（stopped）だけを拾うように、イベントパターンを編集します。

JSON

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped"]
  }
}

EventBridgeのイベントパターン設定画面

3.ターゲットの設定

  • ターゲットタイプ: 「AWS のサービス」

  • ターゲット: SNS トピック

  • トピック: ハンズオン②で作成した monitoring-1-topic を選択します 。

  • 「作成」をクリックしてルールを有効化します。

4.テスト

  • EC2のコンソールを開き、monitoring-1-ec2-WebServer01 を選択し、「インスタンスの状態」→「インスタンスを停止」をクリックして手動で停止させます。

  • 数分後...
    メールが届きました！

EC2が停止したことを知らせるJSON形式の通知メール

  • 内容はJSON形式で、「state": "stopped"」となっていることが確認できました。
    大成功です。

[このハンズオンでの学び]

「メトリクス監視」（CloudWatch Alarms）と「イベント監視」（EventBridge）の明確な違いを理解しました。

前者は「CPUが90%を超え続けている」という状態を監視し、後者は「EC2インスタンスが停止した」という出来事（イベント）をトリガーにします。
この使い分けが重要ですね。

[ハンズオン⑦]：お片付け/リソースの削除

ハンズオンで最も重要な作業です。
お財布を守るために、使ったリソースは必ず削除（お片付け）しましょう。

ここで非常に重要な学びがありました。
ハンズオン資料によると、CloudFormationスタックを削除すればOK...
かと思いきや、それだけでは不十分です。

CloudFormationは、自分が作成したリソース（EC2, ALB, RDS, VPCなど）は削除してくれます。

しかし、ハンズオンの途中で手動で作成したリソース（アラーム、ダッシュボード、SNSトピック、EventBridgeルール、ロググループ）は、CloudFormationの管理外です。

したがって、これらは手動で個別に削除する必要があります。これは非常に重要な学びです。
削除手順 (チェックリスト) ハンズオン資料を参考に、以下の順番で削除しました。

1.CloudFormation スタックの削除

  • CloudFormationコンソールで monitoring-1 スタックを選択し、「削除」をクリック。
    DELETE_IN_PROGRESS になります。（EC2やRDSが消えるまで時間がかかります）

2.EventBridge (CloudWatch Events) ルールの削除

  • EventBridgeコンソールで monitoring-1-event-rule を選択し、「削除」。

3.CloudWatch アラームの削除

  • CloudWatchコンソール > アラーム で monitoring-1-alarm を選択し、「削除」。

4.CloudWatch ダッシュボードの削除

  • CloudWatchコンソール > ダッシュボード で WordPress_dashboard を選択し、「削除」。

5.SNS トピックの削除

  • SNSコンソール > トピック で monitoring-1-topic を選択し、「削除」。

6.CloudWatch ロググループの削除

  • CloudWatchコンソール > ロググループ で wordpress_access_log と wordpress_error_log を選択し、「アクション」→「ロググループの削除」。

これで、ハンズオンで作成したリソースは（ほぼ）すべて削除され、クリーンな状態に戻りました。

おわりに

前後編にわたり、「AWS Hands-on for Beginners 監視編」の体験記をお届けしました。

実際に手を動かしてみることで、

  • Agentを入れないとメモリやディスクが見えないこと

  • Logs Insightsを使えばログファイルもSQLのように分析できること

  • EventBridgeとAlarmの使い分け
    など、テキスト学習だけではイメージしづらかった部分がクリアになりました。

特に、前編の「事前準備」でRDSのインスタンスタイプのエラーに遭遇した際は焦りましたが、トラブルシューティングも含めて良い経験になりました。

これからAWS監視を学ぶ方には、自信を持っておすすめできるハンズオンです。

お知らせ

APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。

その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp

https://www.ap-com.co.jp/service/utilize-aws/

また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

www.ap-com.co.jp