AWS CloudWatchとは?監視・ログ・アラームの仕組みを初心者向けに徹底解説

AWSでシステムを運用していると、「サーバーのCPUがどのくらい使われているか確認したい」「エラーログが出たら自動で通知を受け取りたい」「どの時間帯にアクセスが集中しているか把握したい」といった監視の需要が必ず出てきます。こうした運用監視のニーズをまとめて解決するのが「Amazon CloudWatch」です。今回は、CloudWatchの基本的な仕組みから、CloudWatch Agentの設定方法、実際の活用パターンまで、初心者にも分かりやすく解説します。

Amazon CloudWatchとは

Amazon CloudWatchは、AWSリソースやアプリケーションの監視・ログ収集・アラート通知を一元的に行うサービスです。EC2・RDS・Lambda・ALBなど、ほぼすべてのAWSサービスと標準で統合されており、特別な設定をしなくても基本的なメトリクスが自動的に収集されます。

CloudWatchは大きく以下の4つの要素で構成されています。

デフォルトで取得できるメトリクスと取得できないメトリクス

CloudWatchはAWSサービスと統合されているため、多くのメトリクスが自動収集されます。しかし、EC2に関しては「デフォルトで取得できるもの」と「取得できないもの」があり、この違いは試験でもよく問われる重要なポイントです。

デフォルトで取得できるメトリクス(EC2)

デフォルトでは取得できないメトリクス

なぜ取得できないかというと、これらはEC2インスタンスの「内側(OS内部)」の情報だからです。AWSはインスタンスの外側からしか情報を取得できないため、OS内部の情報は別途エージェントを使って取得する必要があります。ここで登場するのが「CloudWatch Agent」です。

CloudWatch Agentとは

CloudWatch Agent(CWエージェント)は、EC2インスタンスにインストールすることで、OS内部のメトリクスやログをCloudWatchに送信できるようにするソフトウェアです。

CWエージェントをインストールすることで、以下のことが可能になります。

CloudWatch Agentのインストール方法

CWエージェントのインストールは、Systems ManagerのRun Commandを使って複数インスタンスに一括で行う方法が一般的です。手動でインストールする場合は、以下の手順で進めます。

まず、EC2インスタンスにCloudWatchAgentServerPolicyポリシーを持つIAMロールをアタッチします。次に、AWS CLIやSystems Managerを使ってエージェントをインストールします。そして、設定ファイルを作成してエージェントを起動します。

CloudWatch Agentの設定ファイル

CWエージェントの動作はJSON形式の設定ファイルで定義します。設定ファイルは「ウィザード形式」で対話的に作成することもできます。設定ファイルには主に2つのセクションがあります。

metricsセクションでは収集するメトリクスを定義します。たとえばメモリ使用率を収集する場合はmem_used_percent、ディスク使用率はdisk_used_percentを指定します。収集間隔(60秒・10秒など)もここで設定します。

logsセクションでは収集するログファイルのパスと、CloudWatch Logsの送信先(ロググループ名)を定義します。たとえば/var/log/messagesや/var/log/nginx/access.logなど、任意のログファイルを指定できます。

設定ファイルをSystems ManagerのParameter Storeに保存しておくと、複数のインスタンスに同じ設定を配布しやすくなります。

CloudWatch Logsの活用

CloudWatch Logsは、アプリケーションやシステムのログをAWS上に集約・管理するサービスです。CWエージェントと組み合わせることで、複数のEC2インスタンスのログを一か所に集めて管理できます。

ロググループとログストリームという概念を押さえておく必要があります。ロググループは「アプリケーションごと・インスタンスごと」のログのまとまり(フォルダのようなもの)で、ログストリームはその中の個々のログ(ファイルのようなもの)です。

メトリクスフィルターはCloudWatch Logsの強力な機能の一つです。ログの中から特定のパターン(たとえば「ERROR」という文字列)を検出し、その出現回数をメトリクスとして数値化できます。このメトリクスに対してアラームを設定することで、「エラーログが1分間に10件以上出たらSNSで通知する」という仕組みが作れます。

CloudWatch Logs Insightsは、CloudWatch Logsに蓄積されたログをSQLライクなクエリ言語で検索・分析できる機能です。「過去1時間のエラーログを集計する」「特定のユーザーIDに関連するログをすべて抽出する」といった分析が、コンソール上から簡単に行えます。

ログの保持期間は、デフォルトでは「無期限」に設定されています。ログが増え続けるとストレージコストがかかるため、用途に応じて「30日」「90日」「1年」などの保持期間を設定することがベストプラクティスです。

CloudWatch Alarmsの設定と活用

CloudWatch Alarmsは、メトリクスが設定した閾値を超えた場合に、通知やアクションを自動実行する機能です。

アラームには3つの状態があります。「OK」は正常な状態、「ALARM」は閾値を超えた異常な状態、「INSUFFICIENT_DATA」はデータが不足していてまだ評価できない状態です。

アラームに設定できるアクションは主に以下の3種類です。

SNS通知は、アラーム発火時にSNSトピックに通知を送る設定です。SNSからメール・Slack・SMS・Lambda関数など様々な宛先に通知を届けられます。「CPU使用率が80%を超えたらメールで通知する」という基本的なアラートはこの組み合わせで実現できます。

EC2アクションは、アラーム発火時にEC2インスタンスを再起動・停止・終了させる設定です。「インスタンスレベルのステータスチェックが失敗したら自動再起動する」という自己修復の仕組みを作れます。ここで重要なのはStatusCheckFailedのアラームには2種類あるという点です。StatusCheckFailed_Instanceはインスタンス自体の問題なので「再起動(Reboot)」が有効で、StatusCheckFailed_SystemはハードウェアなどAWS側の問題なので「リカバリー(Recover)」が有効です。この使い分けはSOAの試験でも頻出の知識です。

Auto Scalingアクションは、アラーム発火時にAuto Scalingポリシーをトリガーして、EC2インスタンスの台数を増減させる設定です。「CPU使用率が70%を超えたらインスタンスを追加する」というスケールアウトの仕組みを作れます。

複合アラーム(Composite Alarm)

複数のアラームを組み合わせた「複合アラーム」という機能もあります。「CPU使用率が高い」AND「メモリ使用率も高い」という両方の条件が揃ったときだけ通知する、というようにAND/OR条件で組み合わせることで、誤検知(一時的なスパイクでの無駄な通知)を減らせます。

CloudWatch Dashboardの活用

CloudWatch Dashboardは、複数のメトリクスやグラフを一画面にまとめて可視化できる機能です。EC2のCPU使用率・RDSのクエリレイテンシー・ALBのリクエスト数・Lambda関数のエラー率など、システム全体の状態を一覧で把握できるカスタムダッシュボードを作成できます。

ダッシュボードはアカウントをまたいで共有することもでき、運用チームが常に同じ画面でシステムの状態を確認できる環境を作れます。

CloudWatch Container InsightsとLambda Insights

コンテナ(ECS・EKS)やLambdaを監視する場合は、専用の拡張機能があります。

Container Insightsは、ECSやEKSクラスターのコンテナレベルのメトリクス(CPU・メモリ・ネットワーク・ディスク)を収集・可視化する機能です。通常のEC2メトリクスでは見えないコンテナ単位の情報を把握できます。

Lambda Insightsは、Lambda関数の詳細なパフォーマンスメトリクス(コールドスタート時間・メモリ使用量・実行時間の分布など)を収集できる機能です。Lambda関数のパフォーマンスチューニングに役立ちます。

まとめ

Amazon CloudWatchは、AWSシステムの監視・ログ管理・アラート通知を一元的に担う、クラウド運用に欠かせないサービスです。デフォルトで取得できないメモリやディスク使用率はCWエージェントで補い、メトリクスフィルターでログから異常を検知し、アラームで自動アクションにつなげるという一連の流れを理解しておくことが、クラウドエンジニアとしての運用力の基盤になります。まずはCWエージェントの導入とメトリクスフィルターを使ったアラートの設定から始めると、CloudWatchの価値を実感しやすいと思います。