CloudWatchでAWSリソースを監視する

前回の記事では、Auto Scalingによる自動スケーリングについて解説しました。本記事では、AWSリソースの監視に欠かせないAmazon CloudWatchについて解説します。メトリクスの収集、アラームによる異常検知、CloudWatch Logsによるログ管理、ダッシュボードの作成まで、運用に必要な監視の基礎を身につけましょう。

Amazon CloudWatchとは

Amazon CloudWatchは、AWSリソースとアプリケーションのモニタリングと可観測性を提供するマネージドサービスです。メトリクスの収集、ログの管理、アラームの設定、ダッシュボードによる可視化など、運用に必要な機能を統合的に提供します。

CloudWatchの主な機能

CloudWatchには以下の主要機能があります。

なぜCloudWatchが必要か

クラウド環境では、リソースの状態をリアルタイムで把握し、問題を早期に検知することが重要です。

graph TB
    subgraph "監視なしの問題"
        NoMonitor[監視なし]
        NoMonitor --> Problem1[障害に気づかない]
        NoMonitor --> Problem2[パフォーマンス低下の<br/>原因がわからない]
        NoMonitor --> Problem3[コスト最適化が<br/>できない]
    end

graph TB
    subgraph "CloudWatch導入のメリット"
        CW[CloudWatch]
        CW --> Benefit1[異常の早期検知と<br/>自動通知]
        CW --> Benefit2[パフォーマンスの<br/>可視化と分析]
        CW --> Benefit3[リソース使用量の<br/>把握とコスト最適化]
    end

CloudWatchを導入することで、以下のメリットが得られます。

• 可視性の向上: システムの状態をリアルタイムで把握
• 障害の早期検知: 異常値を検知してアラートを送信
• 自動対応: アラームをトリガーにAuto Scalingやアクションを実行
• トラブルシューティング: ログとメトリクスを組み合わせた原因分析
• コスト最適化: リソース使用状況の把握による最適化

CloudWatch Metricsの基礎

CloudWatch Metricsは、AWSリソースとアプリケーションのパフォーマンスデータを収集・可視化するサービスです。

メトリクスの基本概念

graph TB
    subgraph "メトリクスの構成要素"
        Namespace[名前空間<br/>AWS/EC2] --> Metric[メトリクス名<br/>CPUUtilization]
        Metric --> Dimension[ディメンション<br/>InstanceId=i-xxxx]
        Dimension --> Datapoint[データポイント<br/>タイムスタンプ + 値]
    end

EC2の標準メトリクス

EC2インスタンスでは、以下のメトリクスが自動的に収集されます。

EC2の標準メトリクスには、メモリ使用率やディスク使用率が含まれていません。これらを監視するには、CloudWatch Agentを使用してカスタムメトリクスを収集する必要があります。

他のAWSサービスのメトリクス

主要なAWSサービスで収集される代表的なメトリクスを示します。

詳細モニタリング

EC2インスタンスでは、標準モニタリング（5分間隔）と詳細モニタリング（1分間隔）を選択できます。

Auto Scalingと連携する場合は、より迅速なスケーリング判断のために詳細モニタリングを有効にすることを推奨します。

graph LR
    subgraph "モニタリング間隔の違い"
        Standard[標準モニタリング<br/>5分間隔] --> Detect1[異常検知まで<br/>最大10分]
        Detailed[詳細モニタリング<br/>1分間隔] --> Detect2[異常検知まで<br/>最大2分]
    end

カスタムメトリクス

CloudWatch Agentを使用することで、OSレベルのメトリクスやアプリケーション固有のメトリクスを収集できます。

CloudWatch Agentとは

CloudWatch Agentは、EC2インスタンスやオンプレミスサーバーにインストールして、メトリクスとログを収集するソフトウェアです。

graph TB
    subgraph "CloudWatch Agentの役割"
        Agent[CloudWatch Agent]
        Agent --> OS[OSメトリクス<br/>メモリ、ディスク]
        Agent --> Log[ログ収集<br/>アプリログ、システムログ]
        Agent --> Custom[カスタムメトリクス<br/>アプリ固有の指標]
        OS --> CW[CloudWatch]
        Log --> CW
        Custom --> CW
    end

CloudWatch Agentで収集できるメトリクス

CloudWatch Agentのインストール

CloudWatch Agentのインストール手順を示します。

1
2
3
4
5

# Amazon Linux 2023の場合
sudo dnf install -y amazon-cloudwatch-agent

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

CloudWatch Agent設定ファイルの作成

設定ファイルは、ウィザードを使用して対話的に作成するか、JSONファイルを直接作成します。

1
2

# 設定ウィザードの起動
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

設定ファイル（JSON）の例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

{
  "agent": {
    "metrics_collection_interval": 60,
    "run_as_user": "cwagent"
  },
  "metrics": {
    "namespace": "CustomMetrics/WebServer",
    "metrics_collected": {
      "mem": {
        "measurement": [
          "mem_used_percent",
          "mem_available"
        ],
        "metrics_collection_interval": 60
      },
      "disk": {
        "measurement": [
          "disk_used_percent",
          "disk_free"
        ],
        "resources": [
          "/"
        ],
        "metrics_collection_interval": 60
      },
      "cpu": {
        "measurement": [
          "cpu_usage_user",
          "cpu_usage_system",
          "cpu_usage_idle"
        ],
        "metrics_collection_interval": 60,
        "totalcpu": true
      }
    }
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/nginx/access.log",
            "log_group_name": "/webserver/nginx/access",
            "log_stream_name": "{instance_id}"
          },
          {
            "file_path": "/var/log/nginx/error.log",
            "log_group_name": "/webserver/nginx/error",
            "log_stream_name": "{instance_id}"
          }
        ]
      }
    }
  }
}

CloudWatch Agentの起動

設定ファイルを使用してエージェントを起動します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 設定ファイルを指定してエージェントを起動
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config \
  -m ec2 \
  -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json

# エージェントの状態確認
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a status

IAMロールの設定

EC2インスタンスにCloudWatch Agentを使用する場合、以下の権限を持つIAMロールをアタッチする必要があります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:PutMetricData",
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents",
        "logs:DescribeLogStreams"
      ],
      "Resource": "*"
    }
  ]
}

AWSが提供するマネージドポリシーCloudWatchAgentServerPolicyを使用することも推奨されます。

PutMetricData APIによるカスタムメトリクス

アプリケーションから直接カスタムメトリクスを送信することも可能です。

1
2
3
4
5
6
7

# AWS CLIでカスタムメトリクスを送信
aws cloudwatch put-metric-data \
  --namespace "CustomMetrics/MyApp" \
  --metric-name "ActiveUsers" \
  --value 150 \
  --unit "Count" \
  --dimensions "Environment=Production,Service=WebApp"

graph TB
    subgraph "カスタムメトリクスの送信方法"
        App[アプリケーション] --> SDK[AWS SDK<br/>PutMetricData API]
        Agent[CloudWatch Agent] --> Auto[自動収集]
        CLI[AWS CLI] --> Manual[手動送信]
        SDK --> CW[CloudWatch]
        Auto --> CW
        Manual --> CW
    end

CloudWatch Alarms

CloudWatch Alarmsは、メトリクスを監視し、しきい値を超えた場合にアクションを実行する機能です。

アラームの状態

CloudWatchアラームは3つの状態を持ちます。

graph LR
    subgraph "アラームの状態遷移"
        OK[OK<br/>正常] --> |しきい値超過| ALARM[ALARM<br/>警告]
        ALARM --> |しきい値以下に回復| OK
        OK --> |データ不足| INSUFFICIENT[INSUFFICIENT_DATA<br/>データ不足]
        ALARM --> |データ不足| INSUFFICIENT
        INSUFFICIENT --> |データ受信| OK
        INSUFFICIENT --> |しきい値超過| ALARM
    end

アラームの作成

CloudWatchコンソールから「アラーム」→「アラームの作成」を選択します。

ステップ1: メトリクスの選択

ステップ2: 条件の設定

graph TB
    subgraph "アラーム条件の評価"
        Collect[メトリクス収集<br/>5分間隔] --> Evaluate[評価期間<br/>5回分を評価]
        Evaluate --> Check{3回以上<br/>しきい値超過?}
        Check -->|はい| Alarm[ALARM状態]
        Check -->|いいえ| OK[OK状態]
    end

「3/5」のような設定は、一時的なスパイクによる誤検知を防ぐために有効です。

ステップ3: アクションの設定

SNS連携によるアラート通知

アラーム発生時にSNS（Simple Notification Service）を使用して通知を送信する構成を示します。

graph LR
    subgraph "アラート通知の流れ"
        CW[CloudWatch<br/>Alarm] --> SNS[SNS<br/>Topic]
        SNS --> Email[メール通知]
        SNS --> Lambda[Lambda関数]
        SNS --> Slack[Slack通知<br/>（Lambda経由）]
    end

SNSトピックの作成とサブスクリプションの設定手順を示します。

1
2
3
4
5
6
7
8

# SNSトピックの作成
aws sns create-topic --name CloudWatch-Alerts

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

実用的なアラーム設定例

本番環境で設定すべき代表的なアラームを示します。

複合アラーム（Composite Alarms）

複合アラームは、複数のアラームの状態を組み合わせて評価する機能です。

graph TB
    subgraph "複合アラームの構成"
        Alarm1[CPU高負荷<br/>アラーム] --> Composite[複合アラーム<br/>AND条件]
        Alarm2[メモリ高負荷<br/>アラーム] --> Composite
        Composite --> Action[通知アクション]
    end

複合アラームの設定例を示します。

1
2
3
4
5

aws cloudwatch put-composite-alarm \
  --alarm-name "HighResourceUsage" \
  --alarm-rule "ALARM(CPUHighAlarm) AND ALARM(MemoryHighAlarm)" \
  --actions-enabled \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:CloudWatch-Alerts

複合アラームを使用することで、以下のメリットが得られます。

• アラートノイズの削減: 複数条件が揃った場合のみ通知
• 重大度の判断: 複数の問題が同時発生した場合を検知
• 誤検知の防止: 一時的なスパイクによる誤報を削減

異常検出（Anomaly Detection）

CloudWatch Anomaly Detectionは、機械学習を使用してメトリクスの正常な範囲を自動的に学習し、異常を検出します。

graph TB
    subgraph "異常検出の仕組み"
        History[過去のメトリクス<br/>履歴データ] --> ML[機械学習<br/>モデル]
        ML --> Band[予測バンド<br/>上限・下限]
        Current[現在のメトリクス] --> Compare[予測バンドと比較]
        Band --> Compare
        Compare --> |バンド外| Anomaly[異常検出]
        Compare --> |バンド内| Normal[正常]
    end

異常検出は、以下のような動的なワークロードに有効です。

• 日次・週次で変動するトラフィックパターン
• 季節性のあるビジネスメトリクス
• 固定しきい値が設定しにくいメトリクス

CloudWatch Logs

CloudWatch Logsは、AWSリソースやアプリケーションからのログを一元的に収集、保存、分析するサービスです。

CloudWatch Logsの構成要素

graph TB
    subgraph "CloudWatch Logsの階層構造"
        LogGroup[ロググループ<br/>/webserver/nginx/access]
        LogGroup --> Stream1[ログストリーム<br/>i-xxxxxxxxa]
        LogGroup --> Stream2[ログストリーム<br/>i-xxxxxxxxb]
        Stream1 --> Event1[ログイベント<br/>タイムスタンプ + メッセージ]
        Stream1 --> Event2[ログイベント<br/>タイムスタンプ + メッセージ]
    end

ログの収集方法

CloudWatch Logsにログを送信する主な方法を示します。

CloudWatch Agentによるログ収集

CloudWatch Agentの設定ファイルでログ収集を設定します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/nginx/access.log",
            "log_group_name": "/webserver/nginx/access",
            "log_stream_name": "{instance_id}",
            "timestamp_format": "%d/%b/%Y:%H:%M:%S %z"
          },
          {
            "file_path": "/var/log/messages",
            "log_group_name": "/system/messages",
            "log_stream_name": "{instance_id}"
          },
          {
            "file_path": "/var/log/app/application.log",
            "log_group_name": "/application/myapp",
            "log_stream_name": "{instance_id}",
            "multi_line_start_pattern": "^\\d{4}-\\d{2}-\\d{2}"
          }
        ]
      }
    }
  }
}

ログの保持期間設定

ログの保持期間は、コスト管理とコンプライアンス要件に基づいて設定します。

1
2
3
4

# 保持期間の設定（AWS CLI）
aws logs put-retention-policy \
  --log-group-name "/webserver/nginx/access" \
  --retention-in-days 30

CloudWatch Logs Insights

CloudWatch Logs Insightsは、ログデータを対話的にクエリ・分析するための機能です。

graph LR
    subgraph "Logs Insightsの処理フロー"
        Query[クエリ記述] --> Scan[ロググループ<br/>スキャン]
        Scan --> Parse[フィールド<br/>抽出]
        Parse --> Result[結果表示<br/>グラフ化]
    end

代表的なクエリ例を示します。

1
2
3
4
5

# エラーログの検索
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 100

1
2
3
4
5

# HTTPステータスコード別の集計
fields @timestamp, @message
| parse @message '* * * * * * * * *' as ip, identity, user, timestamp, request, status, size, referer, agent
| stats count(*) by status
| sort status

1
2
3
4

# レスポンスタイムの統計
fields @timestamp, @message
| parse @message '* response_time=* *' as prefix, response_time, suffix
| stats avg(response_time), max(response_time), min(response_time) by bin(5m)

1
2
3
4
5

# 特定のIPアドレスからのアクセスを検索
fields @timestamp, @message
| filter @message like /192\.168\.1\.100/
| sort @timestamp desc
| limit 50

メトリクスフィルター

メトリクスフィルターを使用すると、ログからメトリクスを抽出してアラームを設定できます。

graph LR
    subgraph "メトリクスフィルターの仕組み"
        Log[ログイベント] --> Filter[フィルター<br/>パターンマッチ]
        Filter --> Metric[カスタムメトリクス]
        Metric --> Alarm[CloudWatch<br/>Alarm]
    end

メトリクスフィルターの設定例を示します。

1
2
3
4
5
6
7

# エラーログのカウント用フィルター
aws logs put-metric-filter \
  --log-group-name "/webserver/nginx/error" \
  --filter-name "ErrorCount" \
  --filter-pattern "ERROR" \
  --metric-transformations \
    metricName=NginxErrorCount,metricNamespace=CustomMetrics/Nginx,metricValue=1,defaultValue=0

これにより、ログにERRORが出現するたびにメトリクスがカウントされ、しきい値を超えた場合にアラームを発報できます。

サブスクリプションフィルター

サブスクリプションフィルターを使用すると、ログをリアルタイムでストリーミングできます。

graph LR
    subgraph "サブスクリプションフィルターの活用"
        Logs[CloudWatch Logs] --> Filter[サブスクリプション<br/>フィルター]
        Filter --> Firehose[Kinesis<br/>Data Firehose]
        Firehose --> S3[S3<br/>長期保存]
        Filter --> Lambda[Lambda]
        Lambda --> Slack[Slack<br/>通知]
    end

CloudWatch Dashboards

CloudWatch Dashboardsは、メトリクスとログを可視化するカスタマイズ可能なダッシュボードを作成する機能です。

ダッシュボードの特徴

ウィジェットの種類

ダッシュボードの設計例

Webアプリケーションの監視ダッシュボード構成例を示します。

graph TB
    subgraph "ダッシュボードのレイアウト"
        subgraph "上段: 概要"
            Alarm[アラーム状態]
            Users[アクティブユーザー数]
            ErrorRate[エラー率]
        end
        subgraph "中段: インフラ"
            EC2CPU[EC2 CPU使用率<br/>折れ線グラフ]
            Memory[メモリ使用率<br/>折れ線グラフ]
            Network[ネットワーク<br/>積み上げ面グラフ]
        end
        subgraph "下段: アプリケーション"
            ALBLatency[ALBレスポンスタイム<br/>折れ線グラフ]
            RequestCount[リクエスト数<br/>折れ線グラフ]
            Logs[直近のエラーログ<br/>ログテーブル]
        end
    end

ダッシュボードの作成（AWS CLI）

AWS CLIを使用してダッシュボードを作成することもできます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

{
  "widgets": [
    {
      "type": "metric",
      "x": 0,
      "y": 0,
      "width": 12,
      "height": 6,
      "properties": {
        "metrics": [
          ["AWS/EC2", "CPUUtilization", "InstanceId", "i-xxxxxxxxa"],
          ["AWS/EC2", "CPUUtilization", "InstanceId", "i-xxxxxxxxb"]
        ],
        "title": "EC2 CPU Utilization",
        "region": "ap-northeast-1",
        "period": 300,
        "stat": "Average"
      }
    },
    {
      "type": "alarm",
      "x": 12,
      "y": 0,
      "width": 12,
      "height": 6,
      "properties": {
        "title": "Alarm Status",
        "alarms": [
          "arn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:EC2-CPU-High",
          "arn:aws:cloudwatch:ap-northeast-1:123456789012:alarm:ALB-5XX-High"
        ]
      }
    }
  ]
}

1
2
3
4

# ダッシュボードの作成
aws cloudwatch put-dashboard \
  --dashboard-name "WebApp-Production" \
  --dashboard-body file://dashboard.json

CloudWatchの料金体系

CloudWatchの主な料金項目を理解し、コストを最適化しましょう。

主な料金項目

コスト最適化のポイント

CloudWatchを活用した監視設計

実践的な監視設計のベストプラクティスを示します。

監視の階層

graph TB
    subgraph "監視の階層"
        Infra[インフラ層<br/>EC2, EBS, ネットワーク]
        Platform[プラットフォーム層<br/>RDS, ElastiCache, ALB]
        App[アプリケーション層<br/>カスタムメトリクス, ログ]
        Business[ビジネス層<br/>KPI, SLI/SLO]
        Infra --> Platform --> App --> Business
    end

各層の監視項目

SLI/SLOベースの監視

SLI（Service Level Indicator）とSLO（Service Level Objective）に基づいた監視を実装しましょう。

graph LR
    subgraph "SLOベースのアラート"
        Metric[メトリクス収集] --> Calculate[SLI計算<br/>エラー率 = 5XX/Total]
        Calculate --> Compare[SLO比較<br/>0.1%以下?]
        Compare -->|超過| Alert[アラート発報]
        Compare -->|OK| Continue[継続監視]
    end

まとめ

本記事では、Amazon CloudWatchを使用したAWSリソースの監視について解説しました。

CloudWatchの主要機能として、以下の内容を学びました。

• CloudWatch Metrics: AWSリソースのメトリクスを収集し可視化
• カスタムメトリクス: CloudWatch Agentを使用してOS・アプリレベルの指標を収集
• CloudWatch Alarms: しきい値を設定し、異常時にSNS通知やAuto Scalingをトリガー
• CloudWatch Logs: ログを一元管理し、Logs Insightsで分析
• CloudWatch Dashboards: メトリクスとログを可視化するダッシュボードを作成

監視設計のポイントとして、以下を押さえておきましょう。

• インフラ、プラットフォーム、アプリケーション、ビジネスの各層を監視
• SLI/SLOに基づいた監視とアラート設計
• コスト最適化を意識したログ保持期間とメトリクス解像度の設定

次回の記事では、Route 53を使用したDNS管理とドメイン管理について解説します。CloudWatchによる監視と組み合わせて、可用性の高いシステム運用を実現しましょう。

参考リンク

• Amazon CloudWatch ユーザーガイド
• CloudWatch Agent のインストール
• CloudWatch Logs Insights クエリ構文
• CloudWatch アラームの作成
• CloudWatch 料金