CloudWatch Application Signals 完全ガイド v2.0

ゼロコード自動計装による APM と SLO 一元管理

Amazon CloudWatch Application Signals は、EKS・EC2・ECS 上のマイクロサービスアプリケーションの APM（Application Performance Monitoring）を コード変更なし で実現するサービスです。ADOT（AWS Distro for OpenTelemetry）による自動計装でトレース・メトリクスを収集し、サービスマップ・SLO 定義・Error Budget 管理を提供します。2023 年 GA 以来、X-Ray との統合・SLO 機能拡張が進み、2026 年には Recommendations 機能で最適 SLO 値を自動提案します。本ドキュメントはApplication Signals の本質・セットアップ・SLO 運用・2026 年最新動向を体系的に解説します。

ドキュメントの目的

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

• 初心者向け： Application Signals とは何か、なぜ必須かを学びたい方
• 開発者向け： EKS/EC2 アプリケーションの自動計装・トレース取得を実装したい方
• SRE / 運用向け： SLO 定義・Error Budget 追跡・アラート運用を実現したい方
• 意思決定者向け： Datadog APM・New Relic との比較検討

2025-2026年のApplication Signals最新動向

• SLO Recommendations（2026年3月）：30日の自動分析で推奨SLO値を自動提案
• Service-Level SLOs（2026年2月）：複数エンドポイント統合のサービス全体SLO
• SLO Performance Report（2026年1月）：カレンダーベースの達成率分析
• Transaction Search（CloudWatch Logs統合）：トレーススパン単位でLogs Insightsで全文検索
• CloudWatch Application Signals EKS デフォルト有効化（2026年2月）：新EKSクラスタで自動有効化
• Lambda統合強化：ゼロコード計装でLambda関数間の依存関係を自動検出
• AI Operations（Kiro IDE）：AI アシスタントによる自動トラブルシューティング

目次

1. 概要
2. Application Signalsが解決する課題
3. 主な特徴
4. アーキテクチャ
5. EKS セットアップ
6. EC2/ECS セットアップ
7. SLO 定義と管理
8. サービスマップ
9. トレース・メトリクス収集
10. 主要ユースケース
11. 設定・操作の具体例
12. 類似サービス比較
13. ベストプラクティス
14. トラブルシューティング
15. 2025-2026最新動向
16. 学習リソース
17. 導入ロードマップ
18. 実装チェックリスト
19. まとめ
20. 参考文献

概要

初心者向けメモ： Application Signals は「マイクロサービスの自動監視」です。通常、Datadog・New Relic は Agent をインストール・SDK を組み込む必要がありますが、Application Signals は EKS Pod にアノテーション 1 行追加するだけで、自動的に Java・Python・Node.js のトレース・メトリクスを取得します。

Application Signals は EKS・EC2・ECS 上のアプリケーション（Java・Python・Node.js・.NET・Go）をゼロコード自動計装し、HTTP リクエスト・AWS SDK 呼び出し・データベースクライアント動作を自動トレース。サービスマップでマイクロサービス間の依存関係を可視化し、SLO（Service Level Objective）を定義して Error Budget を追跡します。X-Ray との深い統合でトレース詳細を参照可能。AWS ネイティブで低コストな APM として Datadog・New Relic の代替選択肢となります。

対応言語・フレームワーク

Java:     Spring Boot / Tomcat / Jersey / Quarkus
Python:   Django / Flask / FastAPI / asyncio
Node.js:  Express / Next.js / Fastify
.NET:     ASP.NET Core
Go:       Gin / HTTP / gRPC

Application Signalsが解決する課題

Application Signals は、マイクロサービス運用における次の問いに答えるための基盤です。

主な特徴

アーキテクチャ

【図1】Application Signals データフロー：

graph TD
    subgraph EKS[EKS Cluster]
        Pod1["Pod: Java App<br/>アノテーション:<br/>instrumentation.opentelemetry.io/inject-java"]
        Pod2["Pod: Python App<br/>アノテーション:<br/>instrumentation.opentelemetry.io/inject-python"]
    end

    subgraph ADOT[ADOT Operator]
        JAVA_INSTRUMENTATION["Java Agent<br/>aws-opentelemetry-agent.jar"]
        PYTHON_INSTRUMENTATION["Python SDK<br/>opentelemetry-instrumentation"]
    end

    subgraph Collection[データ収集]
        OTEL_COLLECTOR["OpenTelemetry Collector<br/>OTLP Receiver"]
    end

    subgraph Processing[処理・分析]
        CW_SIGNALS["CloudWatch<br/>Application Signals"]
        SERVICEMAP["Service Map<br/>Dependency Graph"]
        SLO_DASHBOARD["SLO Dashboard<br/>Error Budget"]
    end

    subgraph Integration[統合・監視]
        XRAY["X-Ray<br/>Trace Details"]
        CWLOGS["CloudWatch Logs<br/>Log Query"]
        ALARMS["CloudWatch Alarms<br/>SLO Violations"]
    end

    Pod1 -->|Auto Instrumented| JAVA_INSTRUMENTATION
    Pod2 -->|Auto Instrumented| PYTHON_INSTRUMENTATION
    JAVA_INSTRUMENTATION -->|OTLP| OTEL_COLLECTOR
    PYTHON_INSTRUMENTATION -->|OTLP| OTEL_COLLECTOR
    OTEL_COLLECTOR -->|Metrics + Traces| CW_SIGNALS
    CW_SIGNALS -->|Generate| SERVICEMAP
    CW_SIGNALS -->|Generate| SLO_DASHBOARD
    SLO_DASHBOARD -->|Detail Lookup| XRAY
    SLO_DASHBOARD -->|Log Search| CWLOGS
    SLO_DASHBOARD -->|Violation| ALARMS

EKS セットアップ

1. CloudWatch Observability Addon インストール

# Addon を EKS に追加
aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name amazon-cloudwatch-observability \
  --addon-version v1.x.x \
  --service-account-role-arn arn:aws:iam::123456789012:role/CWObservabilityRole

# または eksctl で一括設定
eksctl create addon \
  --name amazon-cloudwatch-observability \
  --cluster my-cluster

2. IAM ロール作成

# CloudWatch Observability 用 IAM ロール
aws iam create-role \
  --role-name CWObservabilityRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.ap-northeast-1.amazonaws.com/id/EXAMPLEID"},
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {"StringEquals": {"oidc.eks.ap-northeast-1.amazonaws.com/id/EXAMPLEID:sub": "system:serviceaccount:amazon-cloudwatch:cloudwatch-observability"}}
    }]
  }'

# ポリシーをアタッチ
aws iam attach-role-policy \
  --role-name CWObservabilityRole \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

3. Pod にアノテーション追加

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-api
spec:
  replicas: 3
  template:
    metadata:
      annotations:
        # Java アプリケーションの自動計装
        instrumentation.opentelemetry.io/inject-java: "true"
        # または Python
        # instrumentation.opentelemetry.io/inject-python: "true"
    spec:
      containers:
      - name: order-api
        image: myapp:1.0
        ports:
        - containerPort: 8080
        env:
        - name: OTEL_SERVICE_NAME
          value: "order-api"
        - name: OTEL_EXPORTER_OTLP_ENDPOINT
          value: "http://localhost:4317"

または Namespace 全体に適用：

# Namespace レベルでアノテーション設定
kubectl annotate namespace production \
  instrumentation.opentelemetry.io/inject-java=true \
  --overwrite

4. 設定ファイル（OpenTelemetry Collector）

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-config
  namespace: amazon-cloudwatch
data:
  collector.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
    
    exporters:
      awscloudwatch:
        namespace: "AWS/ApplicationSignals"
        region: "ap-northeast-1"
      awsxray:
        region: "ap-northeast-1"
    
    service:
      pipelines:
        traces:
          receivers: [otlp]
          exporters: [awsxray, awscloudwatch]
        metrics:
          receivers: [otlp]
          exporters: [awscloudwatch]

EC2/ECS セットアップ

EC2（CloudWatch Agent経由）

{
  "agent": {
    "region": "ap-northeast-1",
    "metrics_collection_interval": 60
  },
  "application_signals": {
    "enabled": true
  },
  "traces": {
    "traces_collected": {
      "application_signals": {}
    }
  }
}

ECS（CloudWatch Agent コンテナ）

{
  "containerDefinitions": [
    {
      "name": "cloudwatch-agent",
      "image": "public.ecr.aws/cloudwatch-agent/cloudwatch-agent:latest",
      "environment": [
        {"name": "OTEL_SERVICE_NAME", "value": "my-service"},
        {"name": "OTEL_EXPORTER_OTLP_ENDPOINT", "value": "http://localhost:4317"}
      ],
      "portMappings": [{"containerPort": 4317, "protocol": "tcp"}]
    },
    {
      "name": "my-app",
      "image": "my-app:latest",
      "environment": [
        {"name": "OTEL_EXPORTER_OTLP_ENDPOINT", "value": "http://localhost:4317"}
      ],
      "links": ["cloudwatch-agent:localhost"]
    }
  ]
}

SLO 定義と管理

SLO 作成（CLI）

# API P99 レイテンシ < 200ms を目標
aws cloudwatch create-service-level-objective \
  --name "OrderAPI-P99-Latency" \
  --service-name "order-api" \
  --operation "GET /api/v1/orders" \
  --sli '{
    "RequestBasedSli": {
      "RequestBasedSliMetric": {
        "MetricType": "LATENCY",
        "OperationName": "GET /api/v1/orders",
        "MetricThreshold": 200000  # 200ms in microseconds
      }
    }
  }' \
  --goal '{
    "Interval": {
      "RollingInterval": {
        "DurationUnit": "DAY",
        "Duration": 28
      }
    },
    "AttainmentGoal": 99.5,
    "WarningThreshold": 99.8
  }'

# 可用性 99.9% を目標（エラー率 < 0.1%）
aws cloudwatch create-service-level-objective \
  --name "OrderAPI-Availability" \
  --service-name "order-api" \
  --operation "GET /api/v1/orders" \
  --sli '{
    "RequestBasedSli": {
      "RequestBasedSliMetric": {
        "MetricType": "AVAILABILITY"
      }
    }
  }' \
  --goal '{
    "Interval": {"RollingInterval": {"Duration": 28, "DurationUnit": "DAY"}},
    "AttainmentGoal": 99.9
  }'

SLO ダッシュボード表示

Service: order-api / GET /api/v1/orders

SLO 1: P99 Latency < 200ms
  目標: 99.5% （28日ローリング）
  現在達成率: 99.45% ⚠️ WARNING（99.8%未満）
  Error Budget 残: 12.6 分（28日中）
  
  期間別:
    過去 1時間: 100% ✅
    過去 24時間: 99.5% ✅
    過去 7日: 99.4% ⚠️
    過去 28日: 99.45% ⚠️

SLO 2: Availability 99.9%
  目標: 99.9% （28日ローリング）
  現在達成率: 99.92% ✅
  Error Budget 残: 28.8 秒

Total Error Budget 消費速度:
  平均: 5 分/日 → 目標達成 OK
  過去 7日トレンド: 上昇傾向（注意）

Terraform による SLO 管理

resource "aws_cloudwatch_service_level_objective" "order_api_latency" {
  name              = "OrderAPI-P99-Latency"
  service_name      = "order-api"
  operation_name    = "GET /api/v1/orders"
  
  sli {
    request_based {
      metric_type        = "LATENCY"
      metric_threshold   = 200  # ms
    }
  }

  goal {
    interval {
      rolling_interval {
        duration      = 28
        duration_unit = "DAY"
      }
    }
    attainment_goal   = 99.5
    warning_threshold = 99.8
  }

  tags = {
    Service     = "OrderAPI"
    Team        = "Platform"
  }
}

サービスマップ

自動生成される情報

┌─────────────────┐
│   API Gateway   │
└────────┬────────┘
         │ 50ms avg
         ↓
┌──────────────────┐
│ Order API (Java) │  ← エラー率: 0.5% / P99: 150ms
└────────┬─────────┘
         │ 80ms avg
         ├──────────→ [DynamoDB] (10ms, 99% success)
         │
         ├──────────→ [RDS MySQL] (200ms, 95% success) ⚠️
         │
         └──────────→ [Lambda ProcessOrder] (500ms, 98% success)
                     │
                     └──→ [SQS Queue]

表示情報：

• ノードサイズ：トラフィック量
• ノード色：エラー率（赤=高）
• エッジ：各接続のレイテンシ・スループット・エラー率

トレース・メトリクス収集

自動計装される操作

HTTP Request:
  ✅ Incoming HTTP リクエスト
  ✅ Outgoing HTTP リクエスト

AWS SDK:
  ✅ S3 GetObject, PutObject
  ✅ DynamoDB Query, PutItem
  ✅ SQS SendMessage, ReceiveMessage
  ✅ Lambda Invoke
  ✅ RDS Database Queries

Database:
  ✅ JDBC Queries（MySQL, PostgreSQL）
  ✅ psycopg2（Python）
  ✅ node-postgres（Node.js）

RPC:
  ✅ gRPC Calls

自動収集メトリクス

Vended Metrics（Application Signals固有）:
  - Service Call Count (by operation)
  - Service Call Duration (P50, P90, P99)
  - Service Error Rate
  - Dependency Latency
  - Dependency Error Rate

CloudWatch Metrics:
  - Availability % (from SLO)
  - Error Budget Remaining
  - Error Budget Burn Rate

主要ユースケース

1. マイクロサービスの性能分析

EKS Pod アノテーション追加 →
→ Application Signals が自動計装 →
→ サービスマップで全サービス可視化 →
→ ボトルネック（RDSが200ms）特定 →
→ インデックス追加で改善

2. SLO ベース運用

SLO 定義: P99 < 200ms, 99.5% 達成率
→ リアルタイムダッシュボードで監視
→ Error Budget 消費速度が 10分/日 超えた
→ 特定エンドポイント（/api/expensive）を特定
→ キャッシュ追加で解決

3. デプロイの影響分析

• 新バージョンデプロイ →
• → SLO パフォーマンスレポートで差分表示
• → P99が 150ms → 300ms に悪化（検出）
• → デプロイロールバック or コード修正

4. コスト分析

• API エンドポイントごとの SLO 監視 →
• → 重い操作（/api/search）が 80% のエラーバジェット消費
• → 非同期化・キャッシング実装
• → 目標達成 + コスト最適化

設定・操作の具体例

kubectl でアノテーション一括適用

# 既存 Deployment に追加
kubectl patch deployment order-api \
  -p '{"spec":{"template":{"metadata":{"annotations":{"instrumentation.opentelemetry.io/inject-java":"true"}}}}}'

# 全 Namespace に適用
kubectl annotate namespace --all \
  instrumentation.opentelemetry.io/inject-java=true --overwrite

Terraform で Application Signals 設定

# EKS Addon
resource "aws_eks_addon" "cloudwatch_observability" {
  cluster_name             = aws_eks_cluster.main.name
  addon_name               = "amazon-cloudwatch-observability"
  addon_version            = "v1.x.x"
  service_account_role_arn = aws_iam_role.cloudwatch_observability.arn
}

# SLO 複数定義
resource "aws_cloudwatch_service_level_objective" "apis" {
  for_each = {
    "list_orders"   = {operation = "GET /api/v1/orders", latency = 200}
    "create_order"  = {operation = "POST /api/v1/orders", latency = 500}
    "get_order"     = {operation = "GET /api/v1/orders/{id}", latency = 150}
  }

  name              = "OrderAPI-${each.key}"
  service_name      = "order-api"
  operation_name    = each.value.operation
  
  sli {
    request_based {
      metric_type      = "LATENCY"
      metric_threshold = each.value.latency
    }
  }

  goal {
    interval {
      rolling_interval {
        duration      = 28
        duration_unit = "DAY"
      }
    }
    attainment_goal = 99.5
  }
}

類似サービス比較

Application Signals vs Datadog APM

選択： AWS 専用・低コスト → Application Signals、豊富機能・マルチクラウド → Datadog。

Application Signals vs New Relic

ベストプラクティス

✅ 推奨：

• SLO を段階的に設定（P50 → P90 → P99）
• エンドポイント単位で SLO 定義
• Error Budget 消費速度を weekly review
• Namespace ごとにアノテーション管理

❌ 避けるべき：

• SLO なしで Application Signals のみ運用
• Error Budget 無視してリリース
• 全エンドポイント 99.99% 目標（不切実）

トラブルシューティング

トレースが送信されない

SLO が表示されない

2025-2026最新動向

1. SLO Recommendations（2026年3月）

30 日のデータから最適 SLO 値を自動提案

• CloudWatch Console の “SLO Recommendations” に:
• 推奨 P99 目標: 180ms（実績の平均）
• 推奨達成率: 99.5% → 99.2% に緩和提案

2. Service-Level SLOs（2026年2月）

複数エンドポイントの統合 SLO

Service: order-api（全体）
  - GET /orders（P99: 150ms）
  - POST /orders（P99: 500ms）
  - DELETE /orders/{id}（P99: 100ms）
  
合計達成率: 98.5%

3. Lambda 自動計装強化

Lambda → Lambda 関数呼び出しの自動トレース

4. Kiro IDE（AI Operations）

異常検知時に AI アシスタントが自動提案

学習リソース

1. AWS CloudWatch Application Signals
2. Application Signals SLO Management
3. AWS Observability Workshop
4. OpenTelemetry Documentation

導入ロードマップ

• Week 1-2: CloudWatch Observability Addon インストール
• Week 3-4: Pod アノテーション設定・トレース確認
• Week 5-6: SLO 定義・ダッシュボード設定
• Week 7+: 運用・最適化

実装チェックリスト

• [ ] CloudWatch Observability Addon インストール
• [ ] IAM ロール作成・付与
• [ ] Pod にアノテーション追加
• [ ] トレース送信を CloudWatch Console で確認
• [ ] SLO 定義（3〜5個のエンドポイント）
• [ ] SLO ダッシュボード確認
• [ ] X-Ray で個別トレース検証
• [ ] CloudWatch Alarms で SLO 違反アラート設定

まとめ

Application Signals は 「マイクロサービスの自動 APM」 です。Datadog・New Relic と異なり、EKS Pod アノテーション 1 行追加するだけで、コード変更なしに Java・Python・Node.js のトレース・メトリクスが自動的に取得されます。

SLO 定義で「API P99 < 200ms」「可用性 99.5%」などの目標を設定し、Error Budget 消費速度をリアルタイムで監視。AWS ネイティブで低コストな APM として、Datadog（月 $31+/ホスト）比で 80% 以上のコスト削減が実現可能です。

2026 年以降は SLO Recommendations・Service-Level SLO・Kiro IDE による AI アシスタント機能で、運用がさらに簡素化されます。

参考文献

1. CloudWatch Application Signals Developer Guide
2. OpenTelemetry Documentation
3. AWS Observability Best Practices
4. OpenSLO Standard
5. AWS CloudWatch Pricing

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