AWS CloudWatchで監視・アラート設定｜運用担当者のための実践ガイド

AWSでシステムを運用していると、「サーバーが落ちていることにユーザーからの連絡で初めて気づいた」「コストが急増しているのに把握できていなかった」といった問題に直面することがあります。

こうした運用課題を解決するのがAWS CloudWatchです。この記事では、CloudWatchの基本概念から、メトリクス監視、ログの収集・分析、アラート通知の設定、ダッシュボード構築まで、運用担当者が即座に実践できる内容を体系的に解説します。

AWS CloudWatchとは？監視サービスの全体像

AWS CloudWatchは、AWSリソースとアプリケーションの監視・可観測性サービスです。メトリクスの収集、ログの集約、アラートの通知、ダッシュボードによる可視化を統合的に提供します。

CloudWatchの主要機能は以下の通りです。

機能	概要	主な用途
CloudWatch Metrics	リソースの数値データ収集	CPU使用率、メモリ、リクエスト数の監視
CloudWatch Logs	ログデータの収集・保存・検索	アプリケーションログ、エラー分析
CloudWatch Alarms	閾値ベースの通知	異常検知時のメール・Slack通知
CloudWatch Dashboards	可視化ダッシュボード	運用状況の一元把握
CloudWatch Logs Insights	ログの高速クエリ	障害時の原因調査
CloudWatch Synthetics	外形監視	Webサイトの死活監視

EC2、RDS、Lambda、ECS、ALBなどの主要サービスは、CloudWatchへのメトリクス送信が標準で有効になっています。追加設定なしで基本的な監視を始められる点が魅力です。

メトリクス監視の基本設定

CloudWatch Metricsは、AWSリソースの状態を数値で把握するための機能です。適切なメトリクスを監視することで、障害の予兆を捉え、パフォーマンス問題に早期に対処できます。

標準メトリクスとカスタムメトリクス

AWSサービスが自動的に送信する標準メトリクスと、自分で定義するカスタムメトリクスの2種類があります。

EC2の主要な標準メトリクス：

• CPUUtilization：CPU使用率（%）
• NetworkIn / NetworkOut：ネットワーク受信/送信バイト数
• DiskReadOps / DiskWriteOps：ディスクI/O操作数
• StatusCheckFailed：ステータスチェック失敗

注意点として、EC2のメモリ使用率とディスク使用率は標準メトリクスに含まれません。これらを監視するには、CloudWatchエージェントをインストールしてカスタムメトリクスとして送信する必要があります。

CloudWatchエージェントの導入

CloudWatchエージェントは、EC2インスタンス内のOS・アプリケーションレベルのメトリクスとログを収集するためのツールです。以下のコマンドでインストールします。

# Amazon Linux 2の場合
sudo yum install amazon-cloudwatch-agent -y

# エージェント設定ウィザードの実行
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

# エージェントの起動
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/bin/config.json

設定ファイル（config.json）でメモリ使用率やディスク使用率を収集対象として指定します。

{
  "metrics": {
    "metrics_collected": {
      "mem": {
        "measurement": ["mem_used_percent"],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": ["disk_used_percent"],
        "resources": ["/"],
        "metrics_collection_interval": 60
      }
    }
  }
}

サービス別の重要メトリクス一覧

運用で特に注意すべきメトリクスをサービス別にまとめます。

サービス	メトリクス	閾値の目安
EC2	CPUUtilization	80%以上で警告
EC2	mem_used_percent（カスタム）	85%以上で警告
RDS	FreeableMemory	1GB以下で警告
RDS	DatabaseConnections	最大接続数の80%で警告
ALB	HTTPCode_Target_5XX_Count	0より大で警告
ALB	TargetResponseTime	2秒以上で警告
Lambda	Errors	0より大で警告
Lambda	Duration	タイムアウト値の80%で警告

RDSのデータベース運用ガイドやAWS Lambdaの基本ガイドも参考にしながら、各サービスの特性に合った監視設計を行いましょう。

CloudWatch Logsでログを一元管理する

CloudWatch Logsは、アプリケーションログ、システムログ、AWSサービスのログを一箇所に集約して管理するための機能です。ログが分散していると障害調査に時間がかかりますが、CloudWatch Logsに集約することで迅速な原因特定が可能になります。

ロググループとログストリームの設計

CloudWatch Logsは、ロググループとログストリームの階層構造でログを管理します。

• ロググループ：ログの種類ごとにまとめる単位（例：/app/production/api）
• ログストリーム：ログの送信元ごとの単位（例：各EC2インスタンスID）

命名規則の例を示します。

/environment/service/component

例：
/production/api-server/application
/production/api-server/access
/production/batch/error
/staging/api-server/application

一貫した命名規則を採用することで、ログの検索性が大幅に向上します。

ログの保持期間とコスト管理

CloudWatch Logsはデータ量に応じた従量課金です。ログの保持期間を適切に設定することでコストを管理できます。

• 本番環境のアプリケーションログ：90日（障害調査に必要な期間）
• アクセスログ：30日（短期の分析用、長期保存はS3へ）
• デバッグログ：7日（開発時の一時的な用途）

長期保存が必要なログは、CloudWatch Logsのサブスクリプションフィルターを使ってS3に自動エクスポートする設定がコスト効率に優れています。S3の実践的な活用方法も確認しておくと良いでしょう。

Logs Insightsで障害を迅速に調査する

CloudWatch Logs Insightsは、ログデータに対してSQL風のクエリを実行できる機能です。障害発生時の原因特定に非常に有効です。

よく使うクエリ例：

# 直近1時間のエラーログを時系列で表示
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 50

# エラーの種類別に件数を集計
fields @message
| filter @message like /ERROR/
| parse @message "ERROR: *" as errorType
| stats count(*) as errorCount by errorType
| sort errorCount desc

# レスポンスタイムが遅いリクエストを抽出
fields @timestamp, @message
| parse @message "duration=* ms" as duration
| filter duration > 3000
| sort duration desc
| limit 20

Logs Insightsはスキャンしたデータ量に応じた課金のため、クエリの時間範囲を絞ることでコストを抑えられます。

アラート設定の実践｜CloudWatch Alarms

CloudWatch Alarmsは、メトリクスが指定した閾値を超えた場合に自動で通知を送る機能です。障害を人手に頼らず検知するために、適切なアラート設定は運用の生命線です。

アラームの3つの状態

CloudWatch Alarmには以下の3つの状態があります。

• OK：メトリクスが閾値の範囲内
• ALARM：メトリクスが閾値を超過
• INSUFFICIENT_DATA：データ不足で評価不可

SNSトピックを使った通知設定

アラームが発火した際の通知先として、Amazon SNS（Simple Notification Service）を設定します。SNSを使うことで、メール、SMS、Lambda関数の呼び出し、さらにはSlack通知まで柔軟に連携できます。

AWS CLIでアラーム設定を行う例を示します。

# SNSトピックの作成
aws sns create-topic --name production-alerts

# メールサブスクリプションの追加
aws sns subscribe \
  --topic-arn arn:aws:sns:ap-northeast-1:123456789012:production-alerts \
  --protocol email \
  --notification-endpoint ops-team@example.com

# CPU使用率のアラーム作成
aws cloudwatch put-metric-alarm \
  --alarm-name "EC2-High-CPU" \
  --alarm-description "EC2 CPU utilization exceeds 80%" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 3 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:production-alerts \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0

evaluation-periodsを3に設定することで、5分間隔で3回連続（15分間）閾値を超えた場合にのみアラームが発火します。一時的なスパイクでの誤報を防ぐ重要な設定です。

Slack通知の設定方法

運用チームがSlackを使っている場合、AWS Chatbotを利用してCloudWatchアラームの通知をSlackチャンネルに送ることができます。

1. AWS Chatbotコンソールで新しいSlackクライアントを設定
2. Slackワークスペースを認証し、通知先チャンネルを選択
3. SNSトピックをAWS Chatbotのチャンネル設定に紐づけ
4. IAMロールで必要な権限を付与

これにより、アラーム発火時にSlackにリッチな通知カードが投稿され、チーム全体で即座に状況を把握できます。

ダッシュボード構築で運用状況を可視化する

CloudWatch Dashboardsは、複数のメトリクスやログを1つの画面にまとめて可視化する機能です。運用チームが日常的に確認する「運用ダッシュボード」を構築しましょう。

実践的なダッシュボード構成例

Webアプリケーションの運用ダッシュボードに含めるべきウィジェットを紹介します。

インフラレイヤー：

• EC2/ECSのCPU使用率・メモリ使用率のグラフ
• RDSの接続数・CPU使用率・空きストレージのグラフ
• ALBのリクエスト数・レスポンスタイムのグラフ

アプリケーションレイヤー：

• HTTP 5xxエラー数のグラフ
• APIレスポンスタイムの95パーセンタイル
• Lambda関数のエラー数・実行時間

ビジネスレイヤー：

• 1分あたりのリクエスト数（トラフィック推移）
• アクティブユーザー数（カスタムメトリクス）

ダッシュボードのJSON定義

ダッシュボードはJSON形式で定義し、コードとして管理できます。

{
  "widgets": [
    {
      "type": "metric",
      "x": 0,
      "y": 0,
      "width": 12,
      "height": 6,
      "properties": {
        "title": "EC2 CPU Utilization",
        "metrics": [
          ["AWS/EC2", "CPUUtilization", "InstanceId", "i-0123456789abcdef0"]
        ],
        "period": 300,
        "stat": "Average",
        "region": "ap-northeast-1",
        "view": "timeSeries"
      }
    },
    {
      "type": "metric",
      "x": 12,
      "y": 0,
      "width": 12,
      "height": 6,
      "properties": {
        "title": "ALB 5xx Errors",
        "metrics": [
          ["AWS/ApplicationELB", "HTTPCode_Target_5XX_Count",
           "LoadBalancer", "app/my-alb/1234567890"]
        ],
        "period": 60,
        "stat": "Sum",
        "region": "ap-northeast-1"
      }
    }
  ]
}

ダッシュボードは最大3つまで無料で作成できます。4つ目以降は月額3ドルの課金が発生します。

CloudWatch活用のコスト最適化

CloudWatchは便利な反面、設定を誤るとコストが急増する可能性があります。Cost Explorerでの費用分析と合わせて、以下のポイントを押さえましょう。

コストが膨らむポイントと対策

課金項目	コストが増える原因	対策
カスタムメトリクス	メトリクス数が多すぎる	必要なメトリクスのみ送信
ログの取り込み	デバッグログの大量出力	ログレベルの適切な管理
ログの保存	保持期間が長すぎる	保持期間の設定とS3エクスポート
Logs Insights	広範囲のクエリ実行	時間範囲を絞ったクエリ
詳細モニタリング	全インスタンスで有効化	本番環境のみ有効化

特にログの取り込みコストは見落としがちです。アプリケーションのDEBUGレベルのログが本番環境で有効になっている場合、月額で数万円の追加コストが発生することもあります。本番環境ではINFO以上のログレベルに設定することを徹底してください。

運用で実践すべき監視設計のポイント

最後に、CloudWatchを使った監視設計で押さえるべき実践的なポイントをまとめます。

アラート疲れを防ぐ設計

アラームを大量に設定すると、通知が多すぎて重要なアラートを見逃す「アラート疲れ」が発生します。以下の対策を講じましょう。

• 重要度による分類：Critical（即座に対応）、Warning（業務時間内に対応）、Info（情報共有）の3段階に分ける
• 通知先の分離：Criticalは電話・SMS、WarningはSlack、InfoはメールとSNSトピックを分ける
• 適切な閾値設定：一時的なスパイクで発火しないよう、evaluation-periodsを適切に設定する

CloudWatchだけで十分か？

CloudWatchはAWSネイティブの監視サービスとして優れていますが、以下のケースではサードパーティツール（Datadog、New Relicなど）の併用も検討に値します。

• マルチクラウド環境の統合監視が必要な場合
• APM（Application Performance Monitoring）で詳細なトレースが必要な場合
• より柔軟なダッシュボードやアラート条件が必要な場合

ただし、中小企業の多くのケースではCloudWatchで十分な監視体制を構築できます。まずはCloudWatchで基盤を固め、不足があれば段階的に拡張していく方針が費用対効果に優れています。

まとめ：まず最低限の監視から始めよう

AWS CloudWatchを活用した監視体制の構築について解説しました。要点を振り返ります。

• メトリクス監視：標準メトリクスに加え、CloudWatchエージェントでメモリ・ディスクも収集する
• ログ管理：命名規則を統一し、保持期間を適切に設定してコストを管理する
• アラート設定：重要度を3段階に分け、アラート疲れを防ぐ設計にする
• ダッシュボード：インフラ・アプリ・ビジネスの3レイヤーで可視化する
• コスト管理：ログレベルの管理と保持期間の設定で無駄なコストを抑える

最初からすべてを完璧に設計する必要はありません。まずはCPU使用率とエラー数のアラームを設定するところから始め、運用しながら監視項目を充実させていきましょう。VPCのネットワーク設計と合わせて監視基盤を整備したい方は、VPCネットワーク設計入門も参考にしてください。