DevOps・SRE

CloudWatchの限界に気づいてDatadogに乗り換えた話【2026年の監視構成公開】

「このアラート、また誤報？」そんな会話が週1回あったチームが、半年かけてDatadogに移行した実録。コスト・アラート設計・分散トレーシングまで正直に書きます。

DevOpsSRECloudWatchDatadogオブザーバビリティ

先日、チームのSlackに「CloudWatchのアラートが多すぎて、どれが本物かわからない」というメッセージが流れてきた。送ったのは新卒2年目のメンバーだったが、正直、僕も同じことをずっと感じていた。そこからDatadog移行を決断するまで半年かかったし、移行後も「これで良かったのか」という問いを何度も繰り返してきた。

この記事では、その半年間の試行錯誤と、2026年時点でうちのチームが落ち着いた監視構成を、できるだけ実体験ベースで書いていく。なお、SLI/SLO設計の詳細についてはSLI/SLO設計2026完全ガイドに詳しくまとめているので、そちらも参考にしてほしい。

CloudWatchで何が限界だったか

正直に言うと、CloudWatch自体が「悪い」ツールだとは思っていない。AWS環境であれば設定不要でメトリクスが流れ込んでくるし、Lambda・ECS・RDSといったマネージドサービスとの統合は圧倒的に楽だ。

問題は「規模が大きくなったとき」だった。うちの環境はAWSマルチアカウント構成で、本番・ステージング・開発合わせてアカウント数が12個ある。この状態でCloudWatchを使い続けると、いくつかの問題が少しずつ積み重なっていった。

アラートのノイズが爆発した。 CloudWatch Alarmsで設定したアラートは当初50件程度だったが、サービス追加とともに気づいたら300件を超えた。しきい値の設定が静的なため、デプロイ直後のスパイクや夜間バッチのメモリ増加でもアラートが飛んでくる。週に1回は「これ誤報でしょ」という会話が生まれていた。

クロスアカウント集約が地味にしんどい。 CloudWatch Cross-Account Observabilityは2022年から使えるようになったが、設定が複雑で、ダッシュボードをアカウントをまたいでリンクするたびに権限設定を見直す羽目になった。メトリクスのネームスペースが各アカウントでバラバラになり、見た目を統一するのに余計なコストがかかった。

分散トレーシングがX-Rayで完結しなかった。 AWS X-Rayは確かに便利だが、非AWS系のサードパーティサービスやオンプレの一部コンポーネントとのトレース連携が難しかった。Jaegerにエクスポートする構成も試したが、手間のわりにメリットが薄かった。

こうした背景から、Datadogの評価を本格的に始めたのが2025年末。半年ほど並行運用して、2026年6月から完全移行した。

CloudWatch vs Datadog 2026年時点の比較

評価軸を整理するとこんな感じになる。コストだけ見るとCloudWatchに軍配が上がるが、それ以外の項目は軒並みDatadogが上回った。

観点CloudWatchDatadog
AWS統合の容易さ◎ 設定不要○ Agentまたは統合設定が必要
クロスクラウド対応△ AWSのみ◎ AWS/GCP/Azure/オンプレ
ログ検索・分析△ CloudWatch Insights（クエリ習得コスト高）◎ ログエクスプローラー（直感的）
分散トレーシング△ X-Ray（AWS外は弱い）◎ APM＋OpenTelemetry対応
アラート柔軟性△ 静的しきい値が基本◎ 動的しきい値・異常検知
ダッシュボード△ 設定が冗長◎ 豊富なテンプレート
コスト◎ 小〜中規模は安価△ スケールと共に高騰
SLO管理△ 別途構築が必要◎ SLO管理画面が統合済み
オンコール管理× 別ツールが必要◎ PagerDuty統合・On-Call機能内包

コストについては後述するが、個人的には「高いけど使える」か「安いけど運用コストが嵩む」かの話だと思っている。単純な月額比較だけでは判断できない部分がある。

実際にどう移行したか（具体的な設定と詰まりポイント）

Step1: DatadogのAWS統合をCloudFormationで展開

DatadogのAWS統合は、CloudFormationスタックを使って各アカウントにDatadog IAM Roleを作成するのが基本になる。マルチアカウントの場合は、AWS OrganizationsとStackSetsを組み合わせて一括展開した。

# datadog-integration.yaml（抜粋）
Resources:
  DatadogIntegrationRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: DatadogIntegrationRole
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              AWS: !Sub "arn:aws:iam::${DatadogAWSAccountId}:root"
            Action: sts:AssumeRole
            Condition:
              StringEquals:
                sts:ExternalId: !Ref DatadogExternalId
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/SecurityAudit
      Policies:
        - PolicyName: DatadogAWSIntegrationPolicy
          PolicyDocument:
            Version: "2012-10-17"
            Statement:
              - Effect: Allow
                Action:
                  - cloudwatch:GetMetricData
                  - cloudwatch:GetMetricStatistics
                  - cloudwatch:ListMetrics
                  - logs:DescribeLogGroups
                  - logs:FilterLogEvents
                  - tag:GetResources
                  - xray:GetTraceSummaries
                  - xray:BatchGetTraces
                Resource: "*"

これで各アカウントのCloudWatchメトリクスがDatadogに流れ込む。Lambda・ECS・RDSは追加設定なしで主要メトリクスが見えるようになった。

Step2: Datadog Agentの導入（ECS Fargate）

コンテナ環境のカスタムメトリクスやAPMを使うにはDatadog Agentが必要になる。ECS Fargateの場合はサイドカーとして追加する構成が標準だ。

{
  "name": "datadog-agent",
  "image": "public.ecr.aws/datadog/agent:latest",
  "essential": false,
  "environment": [
    { "name": "DD_API_KEY_SECRET_ARN", "value": "arn:aws:secretsmanager:ap-northeast-1:XXXX:secret:datadog-api-key" },
    { "name": "DD_SITE", "value": "datadoghq.com" },
    { "name": "ECS_FARGATE", "value": "true" },
    { "name": "DD_APM_ENABLED", "value": "true" },
    { "name": "DD_LOGS_ENABLED", "value": "true" },
    { "name": "DD_ENV", "value": "production" },
    { "name": "DD_SERVICE", "value": "api-service" },
    { "name": "DD_VERSION", "value": "1.5.2" }
  ],
  "portMappings": [
    { "containerPort": 8126, "protocol": "tcp" }
  ]
}

DD_ENV・DD_SERVICE・DD_VERSION の3つを統一して設定しておくと、ダッシュボード上でのフィルタリングが格段に楽になる。これを最初から徹底しておけば良かったと後から後悔した部分でもある。地味に重要な設定なので、最初にルールを決めてコード化しておくことを強くすすめたい。

Step3: アラート設計の見直し

CloudWatchから移行するとき、既存アラートをそのままDatadogに持ち込む誘惑に駆られるが、これは絶対にやってはいけない。300件のアラートを移行したら、300件のノイズが引き継がれるだけだ。

うちのチームでは、移行を機にアラート設計を以下の原則で整理し直した。

  1. 症状ベースでアラートを設定する。 例えば「CPUが80%を超えた」ではなく「エラーレートが1%を超えた」「p99レイテンシが500msを超えた」に変える。
  2. 動的しきい値（Anomaly Detection）を活用する。 Datadogの異常検知は時間帯や曜日のパターンを学習するので、夜間バッチの処理ピーク程度では誤報が出なくなった。
  3. SLO違反のアラートを優先する。 細かいメトリクスのアラートよりも、エラーバジェット消費率が一定を超えたらアラートする構成にする。

実際にAPIエラーレートを監視するアラートをDatadog APIで作成するとこんな感じになる。

# Datadog API でアラートを作成する例（Python SDK 使用）
from datadog_api_client import ApiClient, Configuration
from datadog_api_client.v1.api.monitors_api import MonitorsApi
from datadog_api_client.v1.model.monitor import Monitor
from datadog_api_client.v1.model.monitor_type import MonitorType

configuration = Configuration()
with ApiClient(configuration) as api_client:
    api_instance = MonitorsApi(api_client)
    body = Monitor(
        name="API Error Rate > 1% (Production)",
        type=MonitorType("metric alert"),
        query=(
            "sum(last_5m):sum:trace.http.request.errors{env:production,service:api-service}.as_count() / "
            "sum:trace.http.request.hits{env:production,service:api-service}.as_count() * 100 > 1"
        ),
        message="エラーレートが1%を超えました。@pagerduty-oncall",
        tags=["env:production", "team:backend"],
        options={
            "thresholds": {"critical": 1.0, "warning": 0.5},
            "notify_no_data": True,
            "no_data_timeframe": 10,
            "evaluation_delay": 60,
        },
    )
    response = api_instance.create_monitor(body)
    print(response)

こうしてアラートを整理した結果、月間アラート発報数はこのように変化した。

xychart-beta
  title "月間アラート発報数の変化"
  x-axis ["2025-12", "2026-01", "2026-02", "2026-03", "2026-04", "2026-05", "2026-06"]
  y-axis "件数" 0 --> 1400
  bar [1320, 1280, 980, 720, 480, 310, 190]
  line [1320, 1280, 980, 720, 480, 310, 190]

移行開始から6ヶ月で1,320件から190件まで減った。件数が減ったのにインシデント検知の漏れが増えたかというと、むしろ逆で、重要なアラートへの反応速度が上がった。アラート疲れが解消されたのが大きいと思う。数字を見るたびに「もっと早くやれば良かった」という気持ちになる。

分散トレーシングとログ連携の構成

これが個人的に一番変わったと感じる部分だ。CloudWatch + X-Rayでは、ログとトレースが別々の画面に存在していて、「このリクエストがどこで詰まったか」を調べるときに複数の画面を行き来する必要があった。

Datadogでは、APMトレース・ログ・メトリクスが1つの画面でつながっている。具体的にはOpenTelemetryのSDKを使ってトレースを計装し、DatadogのOTLP Ingestに送る構成にした。

# FastAPI × OpenTelemetry × Datadog の計装例
from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.instrumentation.fastapi import FastAPIInstrumentor
from opentelemetry.instrumentation.httpx import HTTPXClientInstrumentor
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

resource = Resource.create({
    "service.name": "api-service",
    "service.version": "1.5.2",
    "deployment.environment": "production",
})

exporter = OTLPSpanExporter(
    endpoint="http://datadog-agent:4317",  # Datadog AgentのOTLPエンドポイント
    insecure=True,
)

provider = TracerProvider(resource=resource)
provider.add_span_processor(BatchSpanProcessor(exporter))
trace.set_tracer_provider(provider)

# FastAPIとhttpxを自動計装
FastAPIInstrumentor.instrument()
HTTPXClientInstrumentor().instrument()

これでマイクロサービス間のトレースが自動でつながる。インシデント対応のベストプラクティスでも触れているが、インシデント発生時に原因箇所を5分以内に特定できるかどうかは、この計装の品質にかかっている。

実際の全体構成はこんなイメージだ。

flowchart TB
  subgraph AWS["AWS (ap-northeast-1)"]
    subgraph VPC["VPC"]
      subgraph ECS["ECS Fargate Cluster"]
        APP["アプリコンテナ<br/>OpenTelemetry SDK"]
        DDA["Datadog Agent<br/>サイドカー"]
        APP -- "OTLP gRPC<br/>:4317" --> DDA
      end
      subgraph RDS["RDS"]
        DB[("Aurora PostgreSQL")]
      end
      APP --> DB
    end
    CW["CloudWatch Logs<br/>（Lambda・VPCフローログ）"]
    LAMBDA["Lambda"]
    LAMBDA --> CW
  end
  DDA -- "APM Traces<br/>Metrics<br/>Logs" --> DD
  CW -- "Forwarder Lambda" --> DD
  subgraph DD["Datadog"]
    APM["APM"]
    LOGS["Log Management"]
    METRICS["Metrics"]
    SLO["SLO Dashboard"]
    ALERTS["Monitors & Alerts"]
    APM --- LOGS
    LOGS --- METRICS
    METRICS --> SLO
    METRICS --> ALERTS
  end
  ALERTS -- "PagerDuty" --> ONCALL["オンコール担当"]

LambdaのログについてはCloudWatch Logsに残しつつ、Datadog Forwarder LambdaでDatadogに転送している。CloudWatchを完全に廃止するのではなく、「AWS内部の詳細ログはCloudWatch、統合ビューはDatadog」という役割分担にした。これが現時点での着地点で、完全に捨てきれていない部分でもある。

コストの現実と対策

正直に書くと、Datadogは高い。うちの環境ではDatadog移行後の月額コストがCloudWatchの約3.5倍になった。ただしこれは比較が難しくて、「監視品質が同等だった場合にどれだけかかるか」で考えると、CloudWatchでX-Ray・サードパーティ連携・分散トレーシング基盤を自前で構築したときのエンジニア工数も含めると、むしろDatadogの方がトータルコストは低いかもしれないと判断した。

とはいえ、コスト最適化は常に意識している。実践してみて効いたことをいくつか挙げると：

カスタムメトリクスの量を制限する。 Datadogはカスタムメトリクス数に応じて課金される。dogstatsd で送るメトリクスは本当に必要なものだけに絞り、タグの組み合わせが爆発しないよう注意した。

# メトリクス使用量の確認（Datadog CLI）
datadog-ci metrics usage --start-date 2026-07-01 --end-date 2026-07-31

# 出力例
# Total custom metrics: 8,420
# Top metrics by volume:
# api.request.duration (env:production) - 1,240 timeseries
# db.query.count (env:production,table:*) - 3,200 timeseries  ← タグ爆発の例

db.query.count のように table:* でタグが膨らむケースがコスト増の元凶になりやすい。定期的にメトリクス使用量を確認する習慣をつけておくと良い。

ログの保持期間を最適化する。 デバッグログを15日、エラーログを90日、監査ログは1年というように保持期間を分けた。Log Archivesを使ってS3に長期保存し、Datadogでのアクティブ保持は最小限にした。

Infrastructureホストの台数を見直す。 ECSのタスクはDatadog Agentがいれば1ホストとしてカウントされる。Fargate Spot活用でタスク数が増減する環境では、ピーク時のホスト数が課金に直結する。

コストの推移はこんな感じで、移行直後は一気に跳ね上がったが、最適化を重ねて落ち着いてきた。

xychart-beta
  title "監視基盤コスト推移（万円/月）"
  x-axis ["2026-01", "2026-02", "2026-03", "2026-04", "2026-05", "2026-06", "2026-07"]
  y-axis "コスト（万円）" 0 --> 60
  bar [18, 18, 52, 55, 48, 42, 38]
  line [18, 18, 52, 55, 48, 42, 38]

CloudWatchのみだった2026年1〜2月が月18万円前後で、Datadog移行直後の3月が52万円まで跳ね上がった。最適化を進めた結果、7月時点で38万円まで落ちてきた。これがどこまで下がるかはまだ検証中だ。

2026年時点で感じる「まだ改善したいこと」

移行して2ヶ月が経ったが、正直まだ完璧ではない。

Lambda関数の詳細トレーシングが難しい。 Lambda Extension経由でDatadog計装できるが、コールドスタートの影響でトレースが欠けることがある。Lambda Cold Startの対策は別記事で書いているが、監視との兼ね合いで最適解を探している最中だ。

SLOダッシュボードの運用ルールがまだ曖昧。 Datadogに統合SLO管理機能があるのは良いが、チームでどのSLOをいつ見るのか、エラーバジェットが減ってきたときのアクションフローがまだ整備しきれていない。これは監視ツールの問題というよりチームプロセスの問題だけど、ツールが整うと逆に「使いこなせていない」感が露わになるのがつらいところだ。

AI系機能（Bits AI）の精度がまだ発展途上。 2026年にDatadogが強化したBits AI（インシデント原因推定のAI機能）は面白いが、うちの環境では精度が60%程度で、まだ参考程度にしか使えていない。半年後に再評価したいと思っている。

皆さんはDatadogのどの機能を一番活用してますか？うちはAPMとSLO管理が特に気に入っているんだけど、Log Analyticsをもっと活用している事例があれば聞いてみたい。

まとめ

半年間のCloudWatch→Datadog移行と並行運用で得た知見を整理するとこうなる。

  1. CloudWatchはAWSシンプル構成には今でも最適解。 マルチアカウント・マルチクラウドが絡んだ瞬間に運用コストが跳ね上がる。規模と複雑さが移行判断のトリガーになる。

  2. アラートは移行時に必ずゼロベースで設計し直す。 既存アラートをそのまま持ち込むと、ノイズがそのまま引き継がれる。症状ベース・SLO違反ベースへの転換が核心だ。

  3. OpenTelemetryで計装しておくと将来の選択肢が広がる。 Datadogに縛られず、必要なら別のバックエンドに切り替えられる。ベンダーロックインを最小化する意味でも計装はOTeLで統一しておくべきだと感じた。

  4. コストは最初の3ヶ月が最も高い。 最適化なしで移行すると一時的に3〜4倍になる。カスタムメトリクス削減・ログ保持期間最適化・アーカイブ設定が効く。

  5. 監視ツールの品質よりチームのプロセスが大事。 どんなに良いツールを入れても、アラートへの対応フローとSLO運用ルールが整備されていないと宝の持ち腐れになる。これが一番骨身に染みた教訓かもしれない。

次のアクション： まずCloudWatchのアラート一覧を棚卸しして、「この1ヶ月で誰も対応しなかったアラート」を洗い出すところから始めてほしい。それだけでも監視設計のどこに問題があるかが見えてくる。Datadogへの移行を検討しているなら、2週間の無料トライアルを自分の環境のサブセットに当てて、APMとログ連携を体験してみるのがおすすめだ。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

DevOps・SRE

CloudWatchで限界を感じてDatadogに乗り換えた話｜コスト・使いやすさの現実

DevOps・SRE

CloudWatch vs Datadog 2026｜コスト・機能比較ガイド

DevOps・SRE

本番障害で学んだログ分析ツール選び｜CloudWatch・Datadog・ELKの使い分け

DevOps・SRE

本番ログ月58万円→8万円に削減。3つのツール並行運用をやめた話

DevOps・SRE

SLO設計で2年失敗した僕が、ユーザージャーニーで運用を軌道に乗せた話

DevOps・SRE

GitOps本番2年で痛感した、教科書と現実のギャップ｜ArgoCD・Flux運用の罠と対策

← 記事一覧に戻る