Amazon CloudWatch 完全ガイド 2026

初心者から実務者向けの包括的解説

Amazon CloudWatch は、AWS リソースとアプリケーションの監視・観測可能性（Observability）を実現する ネイティブ監視プラットフォーム です。2009 年のサービス開始から現在まで、メトリクス・ログ・トレース・アラーム・ダッシュボードの 5 機能を統合し、EC2・Lambda・RDS・ECS など 200+ の AWS サービスと深く統合されています。本ドキュメントは、CloudWatch の本質・コンポーネント・ユースケース・エコシステム・最新動向を体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： CloudWatch とは何か、なぜ AWS で標準的な選択肢かを学びたい方
• 開発者向け： カスタムメトリクス・ログ・ダッシュボード・アラームを実装したい方
• SRE / インフラ向け： CloudWatch を中心に AWS インフラの観測基盤を構築したい方
• 意思決定者向け： Datadog / New Relic / Grafana+Prometheus との比較・投資判断

2025-2026 年の CloudWatch 最新動向

• Application Signals SLO 機能拡張（2026年3月）：SLO Recommendations（30日の自動分析）、Service-Level SLOs（全体的なサービス信頼性）、SLO Performance Report（カレンダーベースの履歴分析）を新規追加
• Application Signals EKS デフォルト有効化（2026年2月）：CloudWatch Observability EKS add-on v5.0.0 で自動有効化
• Kiro IDE 統合（2026年1月）：AI エージェント支援によるアプリケーション健全性調査
• Database Insights：RDS / Aurora / DynamoDB の深層的なパフォーマンスメトリクス
• AI Operations：機械学習による異常検知、予測的スケーリング
• GenAI Observability：LLM API 呼び出しのログ・トレース・コスト追跡
• Internet Monitor 拡張：エッジロケーション単位のトラフィック分析
• CloudWatch Logs Unified Query：複数リージョンのログ統一検索

目次

1. 概要
2. CloudWatch が解決する課題
3. 主な特徴
4. アーキテクチャ
5. メトリクス（Metrics）
6. CloudWatch Logs
7. CloudWatch Logs Insights
8. アラーム（Alarms）
9. ダッシュボード（Dashboards）
10. CloudWatch Application Signals
11. CloudWatch RUM
12. CloudWatch Synthetics
13. Container Insights
14. Lambda Insights
15. Database Insights
16. CloudWatch Internet Monitor
17. EventBridge との関係
18. 主要ユースケース
19. 他の類似ツールとの比較
20. クライアントとエコシステム
21. ベストプラクティス
22. トラブルシューティング
23. コスト最適化
24. 学習リソース
25. 実装チェックリスト
26. まとめ
27. 参考文献

概要

初心者向けメモ： CloudWatch は「AWS の公式監視サービス」です。EC2・Lambda・RDS などが自動的にメトリクスを送信し、CloudWatch がそれを受け取って保存・検索・アラームする。外部ツール（Datadog など）とは異なり、AWS サービスとの統合が深く、追加設定なしに 200+ のメトリクスを自動収集できます。

CloudWatch は AWS リソースとアプリケーションの メトリクス・ログ・トレース・アラーム・ダッシュボード を統合管理するネイティブ監視プラットフォームです。EC2・Lambda・RDS・DynamoDB・ALB など AWS サービスのメトリクスを自動収集し、カスタムメトリクス・カスタムログの送信、Logs Insights による分析、Composite Alarms による複合アラーム、Application Signals による APM、RUM によるエンドユーザー監視を提供します。

CloudWatch の位置づけ

【図1】AWS オブザーバビリティスタックにおける CloudWatch の位置：

graph TD
    subgraph AWSServices[AWS Services]
        EC2[EC2]
        Lambda[Lambda]
        RDS[RDS]
        ALB[ALB/NLB]
        DDB[DynamoDB]
        ECS[ECS/EKS]
    end

    subgraph CloudWatchCore[CloudWatch Core]
        Metrics[Metrics Standard/Custom/High-res]
        Logs[Logs Groups/Streams/Insights]
        Alarms[Alarms Simple/Composite/ML]
        Dashboards[Dashboards Custom Views]
    end

    subgraph CloudWatchAdvanced[CloudWatch Advanced Features]
        AppSignals["Application Signals APM"]
        RUM["RUM エンドユーザー監視"]
        Synthetics["Synthetics 合成監視"]
        Internet["Internet Monitor"]
        ContainerInsights["Container Insights"]
        DatabaseInsights["Database Insights"]
    end

    subgraph Integrations[連携先]
        SNS[SNS 通知]
        EventBridge[EventBridge]
        Lambda2[Lambda 自動修復]
        XRay["X-Ray トレース"]
        Grafana["Grafana"]
    end

    AWSServices -->|自動メトリクス| CloudWatchCore
    CloudWatchCore -->|クエリ・分析| CloudWatchAdvanced
    CloudWatchCore -->|通知・アクション| Integrations
    CloudWatchAdvanced -->|通知・アクション| Integrations

CloudWatch が解決する課題

CloudWatch は、AWS 環境における次の問いに答えるための基盤です。

初心者向けメモ： CloudWatch がない時代は、エンジニアが SSH で EC2 にログインして top コマンドを実行していました。CloudWatch はそれを「自動化・集約・可視化」し、「誰でも・いつでも」リアルタイムで状態を把握できるようにしたサービスです。

主な特徴

アーキテクチャ

初心者向けメモ： CloudWatch は 2 層構造です。下層は「メトリクス・ログ・トレース」の データ収集・保存層、上層は「ダッシュボード・アラーム・Insights」の 分析・アクション層。AWS リソースからのデータは自動的に下層に流れ込み、ユーザーが上層で好きなように分析・アラームを設定します。

【図2】CloudWatch の 2 層アーキテクチャ：

graph TD
    subgraph DataCollection[データ収集層]
        EC2M["EC2 Auto Metrics"]
        LambdaM["Lambda Auto Metrics"]
        RDSM["RDS Auto Metrics"]
        ALB["ALB/NLB Metrics"]
        ECS["ECS/EKS Metrics"]
        Custom["Custom Metrics API"]
    end

    subgraph Transport[転送・保存]
        CWMetrics["CloudWatch Metrics TSDB"]
        CWLogs["CloudWatch Logs ストレージ"]
    end

    subgraph AnalysisLayer[分析・アクション層]
        Dashboard["Dashboards 可視化"]
        Insights["Logs Insights クエリ"]
        Alarms["Alarms + Composite"]
        Anomaly["Anomaly Detection"]
        AppSig["Application Signals"]
        RUM["RUM"]
    end

    subgraph Outputs[出力・通知]
        SNS["SNS 通知"]
        EventBridge["EventBridge 自動化"]
        Lambda["Lambda 修復スクリプト"]
        Grafana["Grafana/Datadog 連携"]
    end

    DataCollection --> Transport
    Transport --> AnalysisLayer
    AnalysisLayer --> Outputs

メトリクス（Metrics）

CloudWatch メトリクスは、時系列データポイント（タイムスタンプ・値・ディメンション）の集合です。

1. 標準メトリクス（Standard Metrics）

AWS サービスから自動的に送信される無料メトリクス（追加設定不要）。

EC2 の標準メトリクス例

Lambda の標準メトリクス例

RDS の標準メトリクス例

2. カスタムメトリクス（Custom Metrics）

アプリケーションから API・SDK・Agent を通じて送信するメトリクス。

カスタムメトリクス送信例（AWS CLI）

aws cloudwatch put-metric-data \
  --namespace "MyApp" \
  --metric-name "OrdersProcessed" \
  --value 42 \
  --timestamp 2026-04-26T10:30:00Z \
  --dimensions Name=Environment,Value=Production

カスタムメトリクス送信例（Python SDK）

import boto3

cloudwatch = boto3.client('cloudwatch')

cloudwatch.put_metric_data(
    Namespace='MyApp',
    MetricData=[
        {
            'MetricName': 'OrdersProcessed',
            'Value': 42,
            'Unit': 'Count',
            'Dimensions': [
                {'Name': 'Environment', 'Value': 'Production'},
                {'Name': 'Service', 'Value': 'OrderService'}
            ]
        }
    ]
)

3. 高分解能メトリクス（High-Resolution Metrics）

1 秒間隔でのメトリクス送信（Lambda・カスタムメトリクスで利用可能）。リアルタイム監視やスケーリング判断に適しています。

# 1 秒間隔でメトリクス送信
aws cloudwatch put-metric-data \
  --namespace "MyApp" \
  --metric-name "RequestLatency" \
  --value 42.5 \
  --storage-resolution 1  # 1秒間隔

4. Metric Math（メトリクス演算）

複数のメトリクスを組み合わせて新しいメトリクスを作成。

Metric Math の例

# エラー率を計算（エラー数 / 総リクエスト数 * 100）
(m2 / m1) * 100

# m1 = Invocations（総関数呼び出し数）
# m2 = Errors（エラー数）

5. ディメンション（Dimensions）

メトリクスを細分化するためのラベル。複数の環境・サービス・リージョンを区別可能にします。

CloudWatch Logs

CloudWatch Logs は、アプリケーション・システム・AWS サービスのログを一元管理するサービスです。

ログの構造

ロググループ（Namespace、保持期間設定可能）
├── ロググストリーム（ソースごと：EC2インスタンスID、Lambda関数版、Lambdaエイリアス等）
│   ├── ログイベント（タイムスタンプ + メッセージ + オプション情報）
│   ├── ログイベント
│   └── ...
└── ロググストリーム
    └── ...

ログ送信方法

ログ保持期間

ログフィルタリング

特定パターンのログを抽出・統計。

# ERROR を含むログをカウント
[timestamp, request_id, level = ERROR, ...]

# 500 エラーを含むログ
{ ($.httpCode = 500) }

CloudWatch Logs Insights

SQL ライクな強力なクエリ言語で、ロググループ内のログを分析します。

基本クエリ構文

• fields @timestamp, @message, @duration
• | filter @message like /ERROR/
• | stats count(*) as errorCount by bin(5m)
• | sort errorCount desc

Logs Insights クエリ例

1. エラーレート計算

fields @timestamp, @message
| filter @message like /ERROR/
| stats count(*) as errors, 
        count(*) as total by bin(1m)
| stats (errors/total)*100 as error_rate

2. レスポンスタイム分析

fields @duration, @message
| filter ispresent(@duration)
| stats avg(@duration) as avg_latency,
        pct(@duration, 95) as p95,
        pct(@duration, 99) as p99

3. トップエラーメッセージ

fields @message
| filter @message like /ERROR/
| stats count() as count by @message
| sort count desc
| limit 10

Logs Insights フィールド

アラーム（Alarms）

CloudWatch アラームは、メトリクスが特定の条件を満たすときに通知・アクションを実行します。

1. 単純アラーム（Simple Alarm）

単一メトリクスの値がしきい値を超えた場合に発火。

aws cloudwatch put-metric-alarm \
  --alarm-name "High CPU" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789:alert

2. 複合アラーム（Composite Alarm）

複数のアラームを AND・OR・NOT で組み合わせて誤検知を削減。

# 例：CPU > 80% AND メモリ > 90% の場合のみ発火
aws cloudwatch put-composite-alarm \
  --alarm-name "Critical System State" \
  --alarm-rule "(alarm(HighCPU) AND alarm(HighMemory))" \
  --alarm-actions arn:aws:sns:...

3. 異常検知アラーム（Anomaly Detection）

機械学習によるベースライン検出。過去 2 週間のデータを学習して異常を判定。

aws cloudwatch put-metric-alarm \
  --alarm-name "RequestCount Anomaly" \
  --metrics '[{"expression":"ANOMALY_DETECTION_BAND(m1, 2)", "id":"ad1"}, {"id":"m1", "metric":{"metric_name":"RequestCount"}}]' \
  --threshold-metric-id ad1

アラームアクション

アラーム状態

初心者向けメモ： アラームを「つけっぱなし」にするとノイズが増え、やがて無視されます。「真に重要な条件」に絞り、Composite Alarms で複数条件を組み合わせて「本物の問題」のみを検出することが重要です。

ダッシュボード（Dashboards）

CloudWatch ダッシュボードは、メトリクス・アラーム・ログを視覚化・一元管理するカスタムビューです。

ダッシュボード機能

ダッシュボード構成例

{
  "widgets": [
    {
      "type": "metric",
      "properties": {
        "metrics": [
          ["AWS/EC2", "CPUUtilization", {"stat": "Average"}],
          ["AWS/Lambda", "Errors", {"stat": "Sum"}]
        ],
        "period": 300,
        "stat": "Average",
        "region": "ap-northeast-1",
        "title": "System Health"
      }
    },
    {
      "type": "log",
      "properties": {
        "query": "fields @timestamp, @message | filter @message like /ERROR/",
        "region": "ap-northeast-1",
        "title": "Recent Errors"
      }
    }
  ]
}

CloudWatch Application Signals

Application Signals は、EKS・EC2 上のアプリケーションの APM（Application Performance Monitoring）機能です。

Application Signals が提供する機能

Application Signals セットアップ

# EKS クラスタ向け ADOT コレクタ インストール
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install adot open-telemetry/opentelemetry-collector \
  --set config.exporters.logging.loglevel=debug

CloudWatch RUM

RUM（Real User Monitoring）は、JavaScript SDK を使用してブラウザ経由の実ユーザー体験を測定します。

RUM が測定する指標

RUM JavaScript SDK 統合例

<script>
window.AWSRUM = window.AWSRUM || {};
window.AWSRUM.config = {
  sessionSampleRate: 1.0,
  identityPoolId: "ap-northeast-1:xxxxxxxx",
  endpoint: "https://aws-rum-xxx.ap-northeast-1.amazonaws.com",
  telemetries: ["performance", "errors", "http"],
  pageTitleQueryParams: ["pageName"],
  pageIdTemplate: "[a-z0-9/]+"
};
</script>
<script src="https://client.rum.us-east-1.amazonaws.com/aws-rum-web-client.js"></script>

CloudWatch Synthetics

Synthetics は、定期的にエンドポイント・GUI フロー・API を検査して可用性をプロアクティブに監視します。

Canary タイプ

Canary スクリプト例（JavaScript）

const synthetics = require('Synthetics');
const https = require('https');

const apiCanary = async function () {
  const postData = JSON.stringify({
    test: 'data'
  });

  const options = {
    hostname: 'api.example.com',
    path: '/api/health',
    method: 'GET',
    port: 443
  };

  return new Promise((resolve, reject) => {
    const request = https.request(options, (response) => {
      if (response.statusCode !== 200) {
        reject(new Error(`Status code: ${response.statusCode}`));
      }
      resolve();
    });

    request.on('error', (error) => {
      reject(error);
    });

    request.end();
  });
};

exports.handler = async function(event, context) {
  return await apiCanary();
};

Container Insights

Container Insights は、ECS・EKS のコンテナレベルメトリクスを自動収集します。

Container Insights が提供するメトリクス

Container Insights セットアップ（EKS）

# CloudWatch Container Insights ADOT コレクタをインストール
curl https://raw.githubusercontent.com/aws-observability/aws-otel-community/master/sample-configs/operator/local/config.yaml -o config.yaml

helm install adot-collector open-telemetry/opentelemetry-collector \
  -f config.yaml

Lambda Insights

Lambda Insights は、Lambda 関数の拡張メトリクス（メモリ使用量・コールドスタート・CPU 時間）を収集します。

Lambda Insights が提供するメトリクス

Lambda Insights Lambda レイヤーの追加

# Terraform の例
resource "aws_lambda_layer_version" "lambda_insights" {
  filename   = "/opt/aws-lambda-insights-extension.zip"
  layer_name = "aws-lambda-insights"
}

resource "aws_lambda_function" "my_function" {
  # ...
  layers = [aws_lambda_layer_version.lambda_insights.arn]
}

Database Insights

Database Insights は、RDS・Aurora・DynamoDB のパフォーマンスメトリクスを深層的に分析します。

RDS Database Insights の分析範囲

CloudWatch Internet Monitor

Internet Monitor は、CloudFront・ALB・NLB のトラフィックをユーザーの地理的位置ごとに分析します。

Internet Monitor が測定する指標

EventBridge との関係

CloudWatch アラームと EventBridge は密接に統合されています。

アラーム発火時の自動化フロー

CloudWatch Alarm (ALARM状態)
    ↓
EventBridge Rule マッチ
    ↓
複数のターゲット実行可能：
    - Lambda 関数（自動修復スクリプト）
    - SNS トピック（通知）
    - SQS キュー（非同期処理）
    - Step Functions（複雑なワークフロー）
    - Systems Manager Automation（OpsCenter インシデント作成）

EventBridge ルール例（自動修復）

{
  "Name": "AutoScaleOnHighCPU",
  "EventPattern": {
    "source": ["aws.cloudwatch"],
    "detail-type": ["CloudWatch Alarm State Change"],
    "detail": {
      "alarmName": ["High CPU Alert"],
      "state": {
        "value": ["ALARM"]
      }
    }
  },
  "Targets": [
    {
      "Arn": "arn:aws:lambda:ap-northeast-1:123456789:function:AutoScale",
      "RoleArn": "arn:aws:iam::123456789:role/EventBridgeRole"
    }
  ]
}

主要ユースケース

1. インフラ監視（Infrastructure Monitoring）

EC2・RDS・ALB の健全性をダッシュボードで一元監視。

✅ CloudWatch で実装可能

EC2 CPU/Memory/Disk → CloudWatch Metrics
   ↓
メトリクス集計・アラーム設定
   ↓
ダッシュボード表示 + SNS 通知

2. ログ分析（Log Analysis）

アプリケーションログから ERROR・WARN を抽出し、根本原因を追跡。

Application Logs → CloudWatch Logs
   ↓
Logs Insights クエリ
   ↓
エラーレート・トップエラーメッセージ抽出

3. Lambda 監視

Lambda 関数のエラー率・Duration・同時実行数をリアルタイム監視。

Lambda Invocations → CloudWatch Metrics
   ↓
カスタムメトリクス（ビジネスメトリクス）送信
   ↓
Composite Alarms で複数条件を組み合わせ

4. コンテナ監視（ECS/EKS）

Pod・タスク・サービス単位の CPU・メモリ・ネットワークを監視。

ECS/EKS → Container Insights
   ↓
クラスタ・ノード・Pod ごとのメトリクス
   ↓
Application Signals で APM（トレース・SLO）

5. APM（Application Performance Monitoring）

マイクロサービス間の遅延・エラー・サービス依存関係を分析。

EKS/EC2 App → OpenTelemetry
   ↓
Application Signals (トレース・スパン)
   ↓
サービス依存関係マップ・SLO 監視

6. SLO（Service Level Objective）監視

可用性目標・レイテンシ目標を定義し、エラーバジェット消費速度を監視。

Application Signals SLO Definition
   ↓
リアルタイムで目標達成率・バジェット消費速度を計算
   ↓
バジェット枯渇前にアラート

7. ダッシュボード・可視化

複数サービス・複数リージョンのメトリクスを統一ダッシュボードで表示。

クロスアカウント CloudWatch Dashboards
   ↓
Metric Math で KPI 計算（成約率・売上・ユーザー数）
   ↓
経営層・開発チームで共有

8. 自動修復（Auto-Healing）

アラーム発火時に Lambda が自動的に修復アクション（再起動・Auto Scaling）を実行。

CloudWatch Alarm (threshold exceeded)
   ↓
EventBridge Rule
   ↓
Lambda 修復スクリプト実行
   ↓
リソース自動修復 or スケーリング

9. コスト監視

AWS リソースの利用量・コストをカスタムメトリクスで追跡。

API Gateway 呼び出し数・Lambda 実行時間 → カスタムメトリクス
   ↓
コスト計算（呼び出し数 × $0.0000002）
   ↓
しきい値超過時にアラート

10. 機械学習・異常検知

トレンド外れ値を自動検出し、予測的に対応。

過去 2 週間のメトリクス履歴
   ↓
CloudWatch Anomaly Detection
   ↓
ベースライン ± 2σ の範囲外を検出

他の類似ツールとの比較

CloudWatch vs Datadog

結論： AWS メインなら CloudWatch、マルチクラウド・高度な分析なら Datadog。

CloudWatch vs Grafana + Prometheus + Loki

結論： AWS ワークロード + 簡単セットアップなら CloudWatch。OSS・カスタマイズ重視なら Grafana Stack。

CloudWatch vs New Relic

クライアントとエコシステム

AWS CLI

# メトリクス取得
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-1234567 \
  --start-time 2026-04-20T00:00:00Z \
  --end-time 2026-04-26T23:59:59Z \
  --period 3600 \
  --statistics Average

boto3（Python SDK）

import boto3

cw = boto3.client('cloudwatch')

# カスタムメトリクス送信
cw.put_metric_data(
    Namespace='MyApp',
    MetricData=[
        {
            'MetricName': 'OrderCount',
            'Value': 42,
            'Unit': 'Count',
            'Dimensions': [{'Name': 'Service', 'Value': 'OrderAPI'}]
        }
    ]
)

# ダッシュボード作成
cw.put_dashboard(
    DashboardName='MyDashboard',
    DashboardBody='{"widgets": [...]}' # JSON 形式
)

AWS CDK（Infrastructure as Code）

from aws_cdk import (
    aws_cloudwatch as cw,
    aws_ec2 as ec2,
    core
)

class CloudWatchStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)

        # CloudWatch ダッシュボード作成
        dashboard = cw.Dashboard(self, "Dashboard",
            dashboard_name="MyMonitoring"
        )

        # メトリクスウィジェット追加
        dashboard.add_widgets(
            cw.GraphWidget(
                title="EC2 CPU",
                left=[
                    cw.Metric(
                        namespace="AWS/EC2",
                        metric_name="CPUUtilization",
                        statistic="Average"
                    )
                ]
            )
        )

Terraform

resource "aws_cloudwatch_metric_alarm" "cpu_alarm" {
  alarm_name          = "high-cpu-alert"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name         = "CPUUtilization"
  namespace           = "AWS/EC2"
  period              = 300
  statistic           = "Average"
  threshold           = 80
  alarm_actions       = [aws_sns_topic.alerts.arn]

  dimensions = {
    InstanceId = "i-1234567"
  }
}

ADOT（AWS Distro for OpenTelemetry）

CloudWatch と OpenTelemetry の統合。

# otel-collector-config.yaml
receivers:
  prometheus:
    config:
      scrape_configs:
        - job_name: 'prometheus'
          scrape_interval: 15s
          static_configs:
            - targets: ['localhost:9090']

exporters:
  awscloudwatch:
    namespace: "MyApp"
    region: "ap-northeast-1"

service:
  pipelines:
    metrics:
      receivers: [prometheus]
      exporters: [awscloudwatch]

ベストプラクティス

1. メトリクス戦略（What to Monitor）

✅ 監視すべき指標

• ビジネス KPI：注文数・売上・ユーザー数（カスタムメトリクス）
• SLO 関連：エラー率・レイテンシ・可用性
• リソース健全性：CPU・メモリ・ディスク・ネットワーク
• 依存関係健全性：DB 接続・キュー深さ・外部 API 応答

❌ 避けるべき過度な監視

• 過多なディメンション：カーディナリティ爆発でコスト増加
• すべてのアプリケーション変数：重要度の低い詳細ログは Logs へ
• 超短時間粒度：1 秒間隔は必要性を明確にしてから

2. アラーム設計

✅ 実践的なアラーム

# 誤検知を減らす Composite Alarm
(CPU > 80% AND Memory > 85% AND for 5 minutes) → Alert

❌ アンチパターン

# 単一条件のみ → 誤検知が多い
CPU > 50% → Alert（本番環境では頻繁に超える）

3. ログ設計

✅ 実践的なログ構造

{
  "timestamp": "2026-04-26T10:30:00Z",
  "level": "ERROR",
  "service": "OrderAPI",
  "request_id": "req-12345",
  "error_code": "PAYMENT_FAILED",
  "user_id": "user-789",
  "duration_ms": 1234,
  "error_message": "Payment gateway timeout"
}

❌ アンチパターン

• plain text log: “Something went wrong” ← 検索・分析が困難

4. ダッシュボード設計

✅ 効果的なダッシュボード

【トップレベルダッシュボード】
├─ System Health（全体像）
│  ├─ Availability (%)
│  ├─ Error Rate (%)
│  └─ P99 Latency (ms)
├─ Business KPI
│  ├─ Orders/min
│  ├─ Revenue/hour
│  └─ User Activity
└─ Resource Utilization
   ├─ CPU / Memory / Disk
   └─ Network I/O

❌ アンチパターン

• 【雑然としたダッシュボード】
• → 100+ メトリクスが無秩序に並ぶ → 使い物にならない

5. コスト最適化

✅ コスト削減テクニック

6. セキュリティ

✅ セキュリティベストプラクティス

• CloudWatch Logs への IAM ポリシー制限
• 機密データ（パスワード・トークン）をログに含めない
• KMS 暗号化でログを保護
• CloudTrail で API アクセスを監査

トラブルシューティング

ログが見えない

メトリクスが報告されない

アラームが発火しない

コスト最適化

CloudWatch 料金体系

コスト削減例

【変更前】
- カスタムメトリクス 100 個 × $0.30 = $30/月
- ログ保持期間：無期限で月 5GB 増加 = $0.03 × 60GB = $1.80/月
- 合計：約 $50/月

【変更後】
- カスタムメトリクス 30 個（重要度の高いもののみ）× $0.30 = $9/月
- ログ保持期間：30 日に短縮。月 5GB × 0.3 倍 = 1.5GB = $0.045/月
- 合計：約 $10/月

削減効果：80%

学習リソース

公式ドキュメント

1. AWS CloudWatch User Guide
2. CloudWatch Logs Insights Query Syntax
3. CloudWatch Application Signals
4. AWS Observability Best Practices

学習順序

1. Week 1-2：基礎

   • CloudWatch Metrics・Logs・Alarms の概念
   • EC2・Lambda メトリクス自動収集を体験

2. Week 3-4：実装

   • カスタムメトリクス送信（boto3）
   • Logs Insights クエリ構築
   • ダッシュボード作成

3. Week 5-6：発展

   • Application Signals で APM 構築
   • Composite Alarms で複合監視
   • CloudFormation / Terraform で IaC 化

4. Week 7+：運用

   • コスト最適化
   • セキュリティ強化
   • 他ツール（Grafana・Datadog）統合

実装チェックリスト

Phase 1：基本セットアップ

• [ ] CloudWatch コンソールアクセス確認
• [ ] EC2 インスタンス詳細監視有効化
• [ ] Lambda Insights Lambda レイヤー追加
• [ ] RDS 拡張監視有効化

Phase 2：ログ・アラーム

• [ ] CloudWatch Logs エージェント EC2 へ導入
• [ ] Lambda 関数から logs:PutLogEvents 実行確認
• [ ] 最初のアラーム（高 CPU）作成
• [ ] SNS トピック・メール通知設定

Phase 3：カスタムメトリクス

• [ ] ビジネス KPI（注文数・売上）カスタムメトリクス定義
• [ ] SDK / API でカスタムメトリクス送信実装
• [ ] カスタムメトリクスアラーム作成

Phase 4：ダッシュボード・可視化

• [ ] Metric Math を使用した KPI 計算
• [ ] カスタムダッシュボード作成（JSON 編集）
• [ ] テンプレート変数（環境・リージョン）設定

Phase 5：発展機能

• [ ] Application Signals セットアップ（EKS/EC2）
• [ ] RUM JavaScript SDK Web アプリに統合
• [ ] Synthetics Canary で可用性監視
• [ ] Internet Monitor 設定

Phase 6：統合・自動化

• [ ] EventBridge ルール作成（アラーム→Lambda 修復）
• [ ] Terraform / CloudFormation で インフラ as Code 化
• [ ] Grafana 統合（CloudWatch データソース設定）

Phase 7：運用・最適化

• [ ] ログ保持期間最適化（コスト削減）
• [ ] アラーム誤検知削減（Composite Alarms 活用）
• [ ] IAM ポリシー最小権限化
• [ ] 定期的なダッシュボードレビュー・改善

まとめ

初心者向けメモ： CloudWatch は「AWS の標準オブザーバビリティプラットフォーム」です。メトリクス・ログ・アラーム・ダッシュボード・APM（Application Signals）・RUM・Synthetics を統合し、AWS リソースとアプリケーションの健全性を包括的に監視できます。

CloudWatch を使うべき 3 つの理由

1. AWS ネイティブ統合：EC2・Lambda・RDS など 200+ サービスのメトリクスを自動収集。追加エージェント・設定なし。
2. 段階的な導入：基本的なメトリクス・ダッシュボードからスタートして、Application Signals・Synthetics などの発展機能へ進化可能。
3. AWS サービスとの深い連携：EventBridge・Lambda・SNS・Systems Manager と統合し、自動修復・ワークフロー自動化が実現可能。

学習ロードマップ

Week 1-2     Week 3-4     Week 5-6      Week 7+
┌─────────┬──────────┬─────────────┬──────────────┐
│ 基礎    │ 実装     │ 発展機能    │ 運用・最適化 │
│ ・概念  │ ・メト   │ ・Composite │ ・コスト     │
│ ・初期  │ クス     │ Alarms      │ ・セキュ    │
│ セット  │ ・Logs   │ ・App Sig   │ リティ      │
│ アップ  │ Insights │ ・Synthetics│ ・統合       │
└─────────┴──────────┴─────────────┴──────────────┘

次のステップ

• 単一 AWS リソース監視→ CloudWatch Metrics・Logs で開始
• 複数リージョン・アカウント→ CloudWatch クロスアカウントダッシュボード
• マイクロサービス・EKS→ Application Signals + Container Insights
• 外部ツール統合→ Grafana・Datadog CloudWatch データソース設定

参考文献

公式リソース

1. AWS CloudWatch Documentation
2. CloudWatch Metrics
3. CloudWatch Logs Insights Query Syntax
4. CloudWatch Application Signals
5. CloudWatch Application Signals - SLO Capabilities（2026年3月）
6. CloudWatch RUM
7. CloudWatch Synthetics
8. CloudWatch Container Insights
9. CloudWatch Internet Monitor
10. AWS Observability Best Practices
11. AWS Well-Architected Framework - Operational Excellence Pillar

標準化・オブザーバビリティ

• OpenTelemetry Documentation（ベンダー中立的なトレース・メトリクス・ログ標準）
• AWS Distro for OpenTelemetry (ADOT)（AWS による OpenTelemetry 実装）
• Prometheus Documentation（メトリクス集約・時系列 DB）

可視化・ダッシュボード

• Grafana Documentation - CloudWatch Plugin
• AWS CloudWatch Grafana Integration
• AWS Managed Grafana CloudWatch Integration

関連トピック

• AWS X-Ray（分散トレース）
• EventBridge（イベント駆動自動化）
• Systems Manager（インシデント管理・自動化）

最終更新：2026-04-26 バージョン：2.1（2026年3月SLO機能、Grafana統合追加）