CloudWatch Logs 完全ガイド v2.0

ログ一元管理・検索・分析・保存の統合プラットフォーム

Amazon CloudWatch Logs は、AWS サービス・アプリケーション・オンプレミスサーバーのログを一元収集・検索・分析・保存するマネージドログサービスです。Log Groups・Log Streamsの階層構造、Logs Insights のSQLライククエリ、Live Tail によるリアルタイム監視、Anomaly Detection による自動異常検知、複数バックエンド への自動転送（Firehose・Lambda・OpenSearch）を提供します。本ドキュメントはCloudWatch Logsの本質・運用パターン・コスト最適化・2026年の最新機能を体系的に解説します。

ドキュメントの目的

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

• 初心者向け： CloudWatch Logsとは何か、どう使うかを学びたい方
• 開発者向け： アプリケーションログの送信・Logs Insights クエリを実装したい方
• 運用・SRE向け： ログベースのアラーム・異常検知・コスト最適化を実現したい方
• 意思決定者向け： Datadog・Splunk・Loki との比較検討

2025-2026年のCloudWatch Logs最新動向

• Logs Anomaly Detection拡張（2026年1月）：パターン認識・トークン変異検出・周期性異常の ML 精度向上
• Log Classes 最適化（2026年2月）：Infrequent Access クラスで 50% コスト削減
• VPC Endpoint サポート（2026年4月1日）：Live Tail・API が VPC 内でルーティング可能に
• Unified Query across Regions（2026年3月GA）：複数リージョンのログを単一クエリで検索
• Data Protection Policy 拡張：マスキングルール追加・監査ログ生成
• Integration with Data Firehose：リアルタイムで S3・Redshift・Splunk 連携強化
• CloudWatch Logs Insights Performance：クエリ実行速度 40% 高速化

目次

1. 概要
2. CloudWatch Logsが解決する課題
3. 主な特徴
4. アーキテクチャ
5. ログの階層構造
6. ログ送信の方法
7. CloudWatch Logs Insights クエリ
8. メトリクスフィルター
9. サブスクリプションフィルター
10. Live Tail
11. Anomaly Detection
12. Log Classes・保持期間・暗号化
13. 主要ユースケース
14. 設定・操作の具体例
15. 類似サービス比較
16. ベストプラクティス
17. トラブルシューティング
18. 2025-2026最新動向
19. 学習リソース
20. 導入ロードマップ
21. 実装チェックリスト
22. まとめ
23. 参考文献

概要

初心者向けメモ： CloudWatch Logs は「AWS の標準ログ管理サービス」です。SSH で EC2 にログイン して tail -f /var/log/app.log する時代から卒業し、すべてのログを CloudWatch Logs に集約。ブラウザから検索・分析・アラーム設定ができます。

CloudWatch Logs は Lambda・EC2・ECS・API Gateway・RDS・CloudTrail などの AWS サービスが自動送信するログを一元管理するマネージドサービスです。Log Groups（名前空間）→ Log Streams（ソース）→ Log Events（タイムスタンプ+メッセージ）の 3 層構造で整理され、Logs Insights でのアドホック分析、メトリクスフィルターでのアラーム自動化、サブスクリプションフィルターでの外部システム連携（S3・Firehose・Lambda・OpenSearch）を提供します。

CloudWatch Logsの位置づけ

ロギング・ログ管理プラットフォームの役割：

• ログ一元化：Lambda・EC2・ECS・RDS などのログを CloudWatch Logs に統一
• リアルタイム検索・分析：Logs Insights でアドホック分析が可能
• アラーム自動化：メトリクスフィルターでログパターン → メトリクス → アラーム
• 外部連携：サブスクリプションフィルターで Firehose・Lambda・OpenSearch に転送
• コスト最適化：Log Classes（Standard vs Infrequent Access）でコスト削減

CloudWatch Logsが解決する課題

CloudWatch Logs は、ログ管理における次の問いに答えるための基盤です。

主な特徴

アーキテクチャ

【図1】CloudWatch Logsのエコシステム：

graph TD
    subgraph Sources[ログソース]
        Lambda["Lambda<br/>自動送信"]
        EC2["EC2<br/>CloudWatch Agent"]
        ECS["ECS<br/>awslogs Driver"]
        RDS["RDS<br/>自動送信"]
        APIGW["API Gateway<br/>自動送信"]
        VPC["VPC Flow Logs<br/>自動送信"]
    end

    subgraph CWLogs[CloudWatch Logs Service]
        LG["Log Groups<br/>Namespace"]
        LS["Log Streams<br/>Source"]
        LE["Log Events<br/>Timestamp + Message"]
    end

    subgraph Analysis[分析・検索層]
        INSIGHTS["Logs Insights<br/>SQL-like Query"]
        LIVETAIL["Live Tail<br/>Streaming"]
        ANOMALY["Anomaly Detection<br/>ML-based"]
    end

    subgraph Automation[自動化・通知層]
        METRICFILTER["Metric Filters<br/>Log → Metric"]
        SUBFILT["Subscription Filters<br/>Real-time Forward"]
        DATAPROTECT["Data Protection<br/>PII Masking"]
    end

    subgraph Integration[統合・転送先]
        S3["S3<br/>Long-term Storage"]
        FIREHOSE["Firehose<br/>Buffering + Transform"]
        LAMBDA["Lambda<br/>Custom Processing"]
        OPENSEARCH["OpenSearch<br/>Full-text Search"]
        SPLUNK["Splunk<br/>SIEM"]
        DATADOG["Datadog<br/>Monitoring"]
    end

    Sources -->|Log Ingestion| CWLogs
    CWLogs -->|Query| INSIGHTS
    CWLogs -->|Stream| LIVETAIL
    CWLogs -->|Pattern Detection| ANOMALY
    ANOMALY -->|Alert| METRICFILTER
    CWLogs -->|Pattern Extraction| METRICFILTER
    METRICFILTER -->|CloudWatch Alarm| Automation
    CWLogs -->|Forward| SUBFILT
    SUBFILT -->|Route| FIREHOSE
    SUBFILT -->|Invoke| LAMBDA
    FIREHOSE -->|Deliver| S3
    FIREHOSE -->|Stream| OPENSEARCH
    LAMBDA -->|Send| SPLUNK
    LAMBDA -->|Send| DATADOG

ログの階層構造

CloudWatch Logs
├── Log Group（ロググループ）: /aws/lambda/OrderProcessing
│   ├── 属性: 保持期間、暗号化（KMS）、サブスクリプションフィルター
│   ├── 料金課金単位
│   │
│   └── Log Stream（ロググストリーム）: 2024/01/15/[$LATEST]abc123def456
│       ├── 属性: ソース（Lambda 版、EC2 インスタンス ID等）
│       │
│       └── Log Event（ログイベント）
│           ├── Timestamp: 2026-04-26T10:30:45.123Z
│           ├── Message: "[ERROR] Payment failed: timeout after 30s"
│           └── Size: 256 bytes (max)

命名規則（ベストプラクティス）

/aws/lambda/{function-name}         # Lambda関数
/aws/ecs/{cluster}/{service}         # ECS サービス
/aws/rds/instance/{db-instance-name} # RDS
/aws/apigateway/{api-name}           # API Gateway
/aws/vpc/{flow-logs}                 # VPC Flow Logs
/app/{environment}/{service}         # カスタムアプリケーション

ログ送信の方法

1. AWS サービスの自動送信

Lambda： IAM ロールに logs:CreateLogGroup 権限があれば自動送信

import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    logger.info(f"Processing order: {event['order_id']}")
    # 自動的に /aws/lambda/{function-name} に送信

ECS： タスク定義で awslogs ドライバー指定

{
  "containerDefinitions": [
    {
      "name": "my-app",
      "image": "my-app:latest",
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-service",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

RDS： DB パラメータグループで log_exports 設定

aws rds modify-db-instance \
  --db-instance-identifier my-database \
  --cloudwatch-logs-export-configuration LogTypesToEnable=error,general,slowquery

2. CloudWatch Agent（EC2 / オンプレ）

{
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "/var/log/nginx/access.log",
            "log_group_name": "/app/nginx/access",
            "log_stream_name": "{instance_id}",
            "timestamp_format": "%d/%b/%Y:%H:%M:%S %z",
            "retention_in_days": 90
          },
          {
            "file_path": "/var/log/app/application.log",
            "log_group_name": "/app/service",
            "log_stream_name": "{hostname}",
            "retention_in_days": 30
          }
        ]
      }
    }
  }
}

3. SDK / API 直接送信

import boto3

logs_client = boto3.client('logs')

# ロググループ作成
logs_client.create_log_group(logGroupName='/myapp/events')

# ログストリーム作成
logs_client.create_log_stream(
    logGroupName='/myapp/events',
    logStreamName='stream-001'
)

# ログイベント送信
logs_client.put_log_events(
    logGroupName='/myapp/events',
    logStreamName='stream-001',
    logEvents=[
        {
            'timestamp': int(time.time() * 1000),
            'message': '{"user_id": "user-123", "action": "login", "status": "success"}'
        }
    ]
)

4. 構造化ログ（JSON形式）

import json
import logging

logger = logging.getLogger()

def log_event(level, event_type, details):
    log_entry = {
        'timestamp': datetime.utcnow().isoformat(),
        'level': level,
        'event_type': event_type,
        'details': details
    }
    logger.info(json.dumps(log_entry))

# 使用例
log_event('INFO', 'ORDER_CREATED', {
    'order_id': 'ord-12345',
    'customer_id': 'cust-67890',
    'amount': 9999,
    'currency': 'JPY'
})

CloudWatch Logs Insights クエリ

基本構文

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

クエリ例

1. エラーログの集計

fields @timestamp, @message, @logStream
| filter @message like /ERROR/ or @message like /Exception/
| stats count() as error_count, count_distinct(@logStream) as affected_streams by bin(1m)
| sort error_count desc

2. レスポンスタイム分析（Lambda）

fields @timestamp, @duration, @billedDuration, @memorySize, @maxMemoryUsed
| filter @type = "REPORT"
| stats
    count() as invocations,
    avg(@duration) as avg_duration,
    pct(@duration, 50) as p50,
    pct(@duration, 90) as p90,
    pct(@duration, 99) as p99,
    max(@memoryUsed) as peak_memory

3. HTTP ステータスコード別集計（API Gateway）

fields @timestamp, @message
| filter ispresent(status)
| stats count() as request_count by status
| sort status

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

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

5. VPC フローログ（拒否された通信）

fields @timestamp, srcaddr, srcport, dstaddr, dstport, action, protocol
| filter action = "REJECT"
| stats count() as reject_count by srcaddr, dstaddr, dstport
| sort reject_count desc

6. ユーザーセッション追跡

fields @timestamp, @message, user_id, session_id, action
| filter ispresent(user_id)
| filter user_id = "user-12345"
| sort @timestamp asc

7. パフォーマンス異常検出

fields @timestamp, @duration, request_id, endpoint
| filter ispresent(@duration)
| stats
    avg(@duration) as avg_duration,
    pct(@duration, 99) as p99
  by endpoint
| filter p99 > 1000  # 1秒超のエンドポイント抽出

8. コスト分析（API Gateway + Lambda）

fields @timestamp, httpMethod, resourcePath, @duration
| filter ispresent(httpMethod) and ispresent(resourcePath)
| stats
    count() as api_calls,
    sum(@duration) / 1000 as total_seconds  # 料金計算用
  by httpMethod, resourcePath
| sort api_calls desc

クエリ関数リファレンス

メトリクスフィルター

設定例

# ERROR ログをカウント
aws logs put-metric-filter \
  --log-group-name "/aws/lambda/OrderProcessing" \
  --filter-name "ErrorCount" \
  --filter-pattern "[level=ERROR*]" \
  --metric-transformations \
    metricName=ErrorCount,metricNamespace=MyApp,metricValue=1,defaultValue=0

# HTTP 4xx エラーをカウント
aws logs put-metric-filter \
  --log-group-name "/aws/api-gateway/prod-api" \
  --filter-name "HTTP4xxCount" \
  --filter-pattern "[..., status=4*, ...]" \
  --metric-transformations \
    metricName=ClientErrorCount,metricValue=1

フィルターパターン構文

[ERROR]                          # "ERROR" 文字列を含む
[level=ERROR]                    # level フィールドが ERROR
[ip, id, status=4*, ...]        # 4 番目フィールドが 4xx（ワイルドカード）
"ERROR" || "Exception"           # OR 条件
{ $.level = "ERROR" }            # JSON フィールド条件（$.記法）
{ $.timestamp > 1000000 }        # 数値比較

アラーム作成

# メトリクスフィルターから生成されたメトリクスにアラームを設定
aws cloudwatch put-metric-alarm \
  --alarm-name "High-Error-Rate" \
  --metric-name ErrorCount \
  --namespace MyApp \
  --statistic Sum \
  --period 300 \
  --threshold 10 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789:alerts

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

1. Lambda への転送

# Lambda 関数にリアルタイム転送
aws logs put-subscription-filter \
  --log-group-name "/aws/lambda/OrderProcessing" \
  --filter-name "error-alert" \
  --filter-pattern "ERROR" \
  --destination-arn arn:aws:lambda:ap-northeast-1:123456789:function:HandleLogError

# Lambda 関数側で処理
import base64
import json

def lambda_handler(event, context):
    # CloudWatch Logs が圧縮して Base64 エンコード
    payload = base64.b64decode(event['awslogs']['data'])
    log_data = json.loads(payload)
    
    for log_event in log_data['logEvents']:
        message = log_event['message']
        timestamp = log_event['timestamp']
        # Slack 通知など処理

2. Kinesis Data Firehose への転送

# S3 に日次エクスポート
aws logs put-subscription-filter \
  --log-group-name "/aws/lambda/OrderProcessing" \
  --filter-name "s3-export" \
  --filter-pattern "" \
  --destination-arn arn:aws:firehose:ap-northeast-1:123456789:deliverystream/logs-to-s3

# Firehose で変換
aws firehose update-delivery-stream \
  --delivery-stream-name logs-to-s3 \
  --s3-destination-update-configuration \
    S3DestinationConfiguration='{
      "RoleARN": "arn:aws:iam::123456789:role/FirehoseRole",
      "BucketARN": "arn:aws:s3:::my-logs-bucket",
      "Prefix": "logs/year=YYYY/month=MM/day=DD/",
      "ErrorOutputPrefix": "errors/!{firehose:error-output-type}/year=YYYY/month=MM/day=DD/",
      "CloudWatchLoggingOptions": {"Enabled": true, "LogGroupName": "/aws/kinesisfirehose"}
    }'

3. OpenSearch Service への転送

# Lambda function: CloudWatch Logs → OpenSearch
import json
import base64
import boto3
from opensearchpy import OpenSearch

client = OpenSearch(hosts=['domain.ap-northeast-1.es.amazonaws.com'])

def lambda_handler(event, context):
    # ログデータをデコード
    payload = base64.b64decode(event['awslogs']['data'])
    log_data = json.loads(payload)
    
    # OpenSearch にインデックス化
    for log_event in log_data['logEvents']:
        doc = {
            'timestamp': log_event['timestamp'],
            'message': log_event['message'],
            'logGroup': log_data['logGroup'],
            'logStream': log_data['logStream']
        }
        client.index(
            index=f"logs-{log_data['logGroup']}",
            body=doc
        )

Live Tail

リアルタイムストリーミング監視

# 特定のロググループを Live Tail で監視
aws logs tail /aws/lambda/OrderProcessing --follow

# フィルター適用
aws logs tail /aws/lambda/OrderProcessing \
  --filter-pattern "ERROR" \
  --follow

# 複数ロググループを監視
aws logs tail /aws/lambda --follow

# テキストハイライト
aws logs tail /aws/lambda/OrderProcessing \
  --follow \
  --format json \
  --log-stream-names '[$LATEST]'

Console での使用

CloudWatch Console
→ Logs
→ Log groups
→ /aws/lambda/OrderProcessing
→ Live Tail（右上のアイコン）
→ フィルター入力: "ERROR", "timeout" など

セッション時間： 最大 3 時間

Anomaly Detection

ML ベース異常検知

# 異常検出器を作成
aws logs put-log-anomaly-detector \
  --log-group-arn arn:aws:logs:ap-northeast-1:123456789:log-group:/aws/lambda/OrderProcessing \
  --anomaly-visibility-time 7 \
  --evaluation-frequency FIVE_MIN

検出対象

1. パターン頻度変化：エラーパターン急増
2. 新しいパターン：未知のエラータイプ出現
3. トークン変異：既知パターンの異常値
4. 周期性異常：通常周期の逸脱
5. ボリューム異常：ログ量の急増・急減

Logs Insights で異常検出

fields @timestamp, @message
| anomaly @timestamp, @message

Log Classes と保持期間と暗号化

Log Classes

Standard Class（デフォルト）

料金：$0.76/GB（取り込み）+ $0.033/GB/月（保存）
機能：
  - Logs Insights クエリ
  - Live Tail
  - Anomaly Detection
  - メトリクスフィルター
  - サブスクリプションフィルター
  - データ保護ポリシー

Infrequent Access Class（2026年2月GA）

料金：$0.38/GB（取り込み）+ $0.011/GB/月（保存）  # 50% 削減
機能：
  - Logs Insights クエリ
  - Live Tail
  - メトリクスフィルター
  - ❌ Anomaly Detection（未対応）
  - ❌ データ保護ポリシー（2026年Q2対応予定）

推奨用途：
  - 監査ログ（低頻度アクセス）
  - アーカイブログ
  - コンプライアンス保持期間中のログ

保持期間設定

# ロググループ保持期間設定
aws logs put-retention-policy \
  --log-group-name "/aws/lambda/OrderProcessing" \
  --retention-in-days 30

# 設定値
1, 3, 5, 7, 14, 30, 60, 90, 120, 150, 180, 365, 400, 545, 731, 1827, 3653
# 無期限の場合は指定しない

KMS 暗号化

# ロググループを KMS で暗号化
aws logs associate-kms-key \
  --log-group-name "/aws/lambda/OrderProcessing" \
  --kms-key-id arn:aws:kms:ap-northeast-1:123456789:key/12345678-1234-1234-1234-123456789012

主要ユースケース

1. Lambda エラー監視

• Lambda 関数出力 → CloudWatch Logs
• → Logs Insights で ERROR フィルタ
• → メトリクスフィルター → アラーム

2. マイクロサービスログ一元化

• 複数マイクロサービス → CloudWatch Logs
• → Logs Insights で統合検索
• → トレース ID でリクエスト追跡

3. VPC フローログ監視

• VPC Flow Logs → CloudWatch Logs
• → Logs Insights で REJECT / DROP フィルタ
• → 不正アクセス検出

4. コスト監視・最適化

• API Gateway ログ → CloudWatch Logs
• → Logs Insights で呼び出し数集計
• → メトリクスフィルター → 利用料予測

5. セキュリティ・コンプライアンス監査

• CloudTrail → CloudWatch Logs
• → Data Protection Policy で PII マスク
• → Logs Insights で監査クエリ
• → S3 Glacier で長期保存

6. リアルタイムアラート

• アプリケーションログ → CloudWatch Logs
• → Live Tail でリアルタイム監視
• → メトリクスフィルター → SNS/EventBridge 通知

7. ログ分析・ビジネスインサイト

• アプリケーションログ → 構造化 JSON
• → Logs Insights で集計・分析
• → ダッシュボード化
• → ビジネス指標可視化（アクティブユーザー数・売上等）

8. CI/CD パイプライン監視

• CodeBuild ビルドログ → CloudWatch Logs
• → Logs Insights でビルド失敗検出
• → EventBridge → 自動修復 Lambda

9. 複数 AWS アカウント・リージョン統合

Account A Region A → 中央アカウント Region A
Account A Region B ↗
Account B Region A → CloudWatch Logs Centralization
Account B Region B ↗
  → 統一分析

10. OpenSearch / Splunk 連携

• CloudWatch Logs → Firehose / Lambda
• → Splunk / OpenSearch
• → 高度な分析・ダッシュボード

設定・操作の具体例

AWS CLI

# ロググループ作成
aws logs create-log-group \
  --log-group-name /app/myservice

# ロググループ一覧
aws logs describe-log-groups --query 'logGroups[*].logGroupName'

# ロググループ削除
aws logs delete-log-group --log-group-name /app/myservice

# ロググストリーム作成
aws logs create-log-stream \
  --log-group-name /app/myservice \
  --log-stream-name instance-001

# ログイベント取得
aws logs get-log-events \
  --log-group-name /aws/lambda/OrderProcessing \
  --log-stream-name '2024/01/15/[$LATEST]abc123' \
  --limit 100

Terraform

resource "aws_cloudwatch_log_group" "app_logs" {
  name              = "/app/myservice"
  retention_in_days = 30
  kms_key_id        = aws_kms_key.cloudwatch.arn

  tags = {
    Environment = "production"
    Managed     = "terraform"
  }
}

resource "aws_cloudwatch_log_stream" "app_stream" {
  name           = "instance-001"
  log_group_name = aws_cloudwatch_log_group.app_logs.name
}

resource "aws_cloudwatch_log_metric_filter" "error_count" {
  name           = "ErrorCount"
  log_group_name = aws_cloudwatch_log_group.app_logs.name
  filter_pattern = "[level=ERROR*]"

  metric_transformation {
    name      = "ErrorCount"
    namespace = "MyApp"
    value     = "1"
  }
}

boto3

import boto3

logs = boto3.client('logs')

# ロググループ作成
logs.create_log_group(logGroupName='/app/myservice')

# メトリクスフィルター設定
logs.put_metric_filter(
    logGroupName='/app/myservice',
    filterName='ErrorCount',
    filterPattern='[level=ERROR*]',
    metricTransformations=[
        {
            'metricName': 'ErrorCount',
            'metricNamespace': 'MyApp',
            'metricValue': '1',
            'defaultValue': 0
        }
    ]
)

# ログイベント送信
logs.put_log_events(
    logGroupName='/app/myservice',
    logStreamName='stream-001',
    logEvents=[
        {
            'timestamp': int(time.time() * 1000),
            'message': '{"level": "ERROR", "message": "Database timeout"}'
        }
    ]
)

類似サービス比較

CloudWatch Logs vs Datadog Logs

選択： AWS専用なら CloudWatch Logs、マルチクラウド・高度な分析なら Datadog。

CloudWatch Logs vs Loki（OSS）

選択： AWS環境ならCloudWatch Logs、Kubernetes・OSS重視ならLoki。

CloudWatch Logs vs Splunk

ベストプラクティス

1. ロググループ命名規則

✅ 推奨： 階層的・明確な名前

/aws/lambda/{function-name}
/aws/ecs/{cluster}/{service}
/app/{environment}/{service}/{component}

❌ 避ける： 曖昧な名前

• /logs
• /app-logs
• /my-logs-123

2. 保持期間最適化

✅ 推奨： 用途に応じた設定

• Lambda ログ: 30 日
• API Gateway ログ: 14 日
• 監査ログ: 1 年 or 無期限

❌ 避ける： すべて無期限（コスト爆発）

3. ログフォーマット統一

✅ 推奨： 構造化ログ（JSON）

import json
logger.info(json.dumps({
    'timestamp': datetime.utcnow().isoformat(),
    'level': 'INFO',
    'service': 'OrderAPI',
    'user_id': user_id,
    'action': 'order_created',
    'order_id': order_id,
    'amount': amount
}))

❌ 避ける： 非構造化テキスト

• 2026-04-26 10:30:45 Order created for user 123

4. Log Classes の活用（2026年2月GA）

✅ 推奨： 低頻度アクセスログは Infrequent Access

• Standard: Lambda・API Gateway ログ（頻繁にアクセス）
• Infrequent: 監査ログ・アーカイブ（低頻度）

5. Data Protection Policy でマスキング

✅ 推奨： PII を自動マスク

aws logs put-data-protection-policy \
  --log-group-name /app/myservice \
  --policy-document '{
    "Name": "MaskCreditCards",
    "Version": "21.06",
    "Statement": [
      {
        "Sid": "Mask",
        "DataIdentifier": ["arn:aws:dataprotection::aws:data-identifier/CreditCardNumber"],
        "Operation": {"Mask": {}}
      }
    ]
  }'

6. メトリクスフィルター精度

✅ 推奨： 正確なフィルターパターン

[level=ERROR*]
[..., status=5*, ...]
{ $.error_code = "TIMEOUT" }

❌ 避ける： 過度に広いパターン

• [ERROR] # これだけだと誤検知が多い

トラブルシューティング

ログが表示されない

Logs Insights クエリが遅い

メトリクスフィルターが機能しない

2025-2026最新動向

1. Log Classes 最適化

2026年2月GA： Infrequent Access クラスで 50% 以上コスト削減

• Standard: $0.76/GB 取込 + $0.033/GB/月
• Infrequent: $0.38/GB 取込 + $0.011/GB/月 # 50% 削減

2. Logs Insights パフォーマンス向上

2026年3月： クエリ実行速度 40% 高速化

3. VPC Endpoint サポート

2026年4月1日： Live Tail・Logs Insights が VPC 内で実行可能に

• stream-logs.ap-northeast-1.amazonaws.com # 新エンドポイント

4. Unified Query across Regions

2026年3月GA： 複数リージョンのログを単一クエリで検索

fields @timestamp, @message, @logGroup
| filter region = "ap-northeast-1" or region = "ap-southeast-1"
| stats count() as total_errors by region

5. Data Protection Policy 拡張

2026年Q2： Infrequent Access クラスでも PII マスキング対応予定

学習リソース

公式ドキュメント

1. Amazon CloudWatch Logs User Guide
2. CloudWatch Logs Insights Query Syntax
3. Logs Anomaly Detection
4. CloudWatch Logs Centralization

OSS・比較

• Grafana Loki Documentation
• ELK Stack（Elasticsearch・Logstash・Kibana）
• Datadog Logs
• Splunk Cloud

導入ロードマップ

Week 1-2     Week 3-4     Week 5-6      Week 7+
┌──────────┬──────────┬──────────┬──────────────┐
│基礎・基本│ 実装展開 │ 発展機能│ 運用・最適化 │
│セットアップ│         │         │              │
│・概念理解│・Lambda │・Logs  │・コスト最適化│
│・ロググ │・EC2 計装│Insights│・ADOT 移行 │
│ループ作成│・アラーム│複雑ク │・複数リージ│
│         │設定      │エリ     │ョン統合    │
└──────────┴──────────┴──────────┴──────────────┘

実装チェックリスト

Phase 1：基本セットアップ

• [ ] CloudWatch Logs コンソールアクセス確認
• [ ] Lambda 関数の自動ログ送信を確認
• [ ] ロググループを手動作成

Phase 2：ログ収集・送信

• [ ] EC2 に CloudWatch Agent インストール
• [ ] ECS タスク定義で awslogs ドライバー設定
• [ ] RDS ログを CloudWatch Logs に送信

Phase 3：分析・クエリ

• [ ] Logs Insights で基本クエリ実行（エラーフィルタ等）
• [ ] メトリクスフィルター作成（ERROR カウント）
• [ ] CloudWatch アラーム設定

Phase 4：自動化・連携

• [ ] サブスクリプションフィルターで Firehose 転送設定
• [ ] Lambda で Logs → Slack 通知実装
• [ ] Live Tail で リアルタイム監視確認

Phase 5：発展機能

• [ ] Anomaly Detection 有効化
• [ ] Data Protection Policy で PII マスキング設定
• [ ] Log Classes 最適化（Standard vs Infrequent Access）

Phase 6：統合・最適化

• [ ] 複数アカウント・リージョン統合（Centralization）
• [ ] ログ保持期間最適化
• [ ] S3 長期保存・Athena 分析環境構築

まとめ

初心者向けメモ： CloudWatch Logs は「AWS の標準ログ管理サービス」です。Lambda・EC2・ECS・RDS など AWS サービスのログが自動的に送信され、Logs Insights で簡単に検索・分析できます。

CloudWatch Logs を使うべき3つの理由

1. AWS ネイティブ統合：Lambda・ECS・API Gateway が自動送信。エージェント不要で開始可能。
2. Logs Insights で簡単分析：SQL ライク構文で複雑なログ分析が可能。初心者向けテンプレート提供。
3. メトリクスフィルターでアラーム自動化：ログパターン → メトリクス → アラーム で自動通知。

次のステップ

1. Lambda 関数で自動ログ送信を確認
2. Logs Insights でエラー検索
3. メトリクスフィルターでアラーム設定
4. サブスクリプションフィルターで外部連携
5. Log Classes で コスト最適化

参考文献

公式ドキュメント

1. Amazon CloudWatch Logs User Guide
2. CloudWatch Logs Insights Query Syntax
3. CloudWatch Logs Anomaly Detection
4. CloudWatch Logs Live Tail
5. CloudWatch Logs Log Classes
6. Data Protection in CloudWatch Logs
7. CloudWatch Logs Pricing
8. AWS CloudWatch Logs Centralization

ログ管理・可観測性

• AWS Observability Best Practices
• Grafana Loki Documentation
• OpenTelemetry Logging

関連ブログ・記事

• AWS Messaging and Targeting Blog
• AWS Cloud Operations Blog
• CloudWatch Logs Anomaly Detection & Pattern Analysis（Grafana Labs）

最終更新：2026-04-26 バージョン：v2.0