DevOps・SRE

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

AWS環境で1年以上CloudWatchを運用してから、Datadogに切り替えた実体験。ログ検索の遅さ、UIの使いづらさ、想像以上のコスト増から見えた本当の選び分け方を話します。

DevOpsSRECloudWatchDatadog監視オブザーバビリティAWS

CloudWatchで本当に困ったこと

先日プロジェクトで、CloudWatchを中心に監視基盤を構築してたんですけど、3ヶ月運用してから「あ、これ限界きたな」って感じたんですよね。うちのチームでは当初、AWS環境だからCloudWatchで十分だろうと思ってたんですけど、実際に本番環境で大規模ログが流れ込んでくると、いくつか地雷が見えてきたんですよ。

まず感じたのは、ログ量が増えると本当に見づらくなるということ。CloudWatch Insightsのクエリ性能は正直遅い。複雑な複合検索をやろうとすると、実行時間が数十秒かかることもあります。うちのチームの場合、マイクロサービスが15個以上あって、各サービスのログが1日数GB流れ込んでくるんですけど、その中から問題を追跡しようとするたびに「待機中…」のスピナーと睨めっこしてました。

もう一つ痛かったのがメトリクスのフィルタリング機能。CloudWatchダッシュボードは確かに作れるんですけど、複数のメトリクスをセグメンテーションして分析しようとすると、UIが結構ゴリゴリな感じで、1時間かけてもなんか求めてた形にならないことがよくあった。「これ、簡単なツールなら3分で終わるんじゃないかな」って思ったシーンが何度もありましたね。

あと地味に辛かったのがコスト。CloudWatchってログの取り込みと保存、そしてクエリ実行で課金されるじゃないですか。ログ量が多いと、月々の請求がどんどん膨れ上がるんですよ。うちの場合、月50GB程度のログで月額3万円くらいかかってたんですけど、正直「これなら他のツール検討した方がいいんじゃ」って思い始めました。

Datadogに乗り換えて気づいたこと

そこで去年の初め、Datadogの導入を検討し始めたんですよ。正直最初は懐疑的でした。「SaaS監視ツール？高いんじゃないの」って感じでしたけど、実際に本番環境で半年運用してみたら、想像以上に違う体験ができた。

まず気づいたのはUIの直感性。Datadogのダッシュボードって、ドラッグ&ドロップで簡単にウィジェットを配置できるし、メトリクス検索も圧倒的に速い。複雑な条件検索でも、UIを操作してれば自動的にクエリが構築されていく感じで、SQLを書かなくてもサクサク分析できる。これは本当に時間短縮になりました。

ログ検索の性能も別世界だった。CloudWatch Insightsで30秒かかってた複合検索が、Datadogではほぼ秒で結果が返ってくるんですよ。フィルターとファセット検索も直感的で、「あ、このサービスのエラー率が5分前から上がってる」みたいなことを素早く察知できるようになりました。それまでの「待つ」という作業がほぼ消えた感じです。

メトリクスのセグメンテーションも素晴らしい。複数のディメンションで同時にグループ化できるし、各グループのランキングも自動で算出してくれる。例えば「どのホストがCPU使用率が高いのか」「どのエンドポイントが遅いのか」みたいなことを、ノーコードで数クリックで可視化できるんですよ。

ただし、ここが大事なんですけど、Datadogのコスト構造は複雑です。ログ取り込みだけでなく、カスタムメトリクス、APM、セキュリティ監視など、機能ごとに課金されるんですよ。うちの場合、ログ+APM+セキュリティモニタリング全部揃えると月額15万円近くなっちゃいました。CloudWatchの3万円からすると5倍。これは正直悩みました。

実装してわかった、本当のコスト構造

xychart-beta
    title CloudWatch vs Datadog 月額コスト比較（実例）
    x-axis [ログ取込, ストレージ, クエリ, APM, セキュリティ, 合計]
    y-axis "月額（円）" 0 to 150000
    line "CloudWatch" [5000, 3000, 8000, 0, 0, 16000]
    line "Datadog (Full Stack)" [30000, 0, 0, 40000, 20000, 90000]
    line "Datadog (Core)" [15000, 0, 0, 20000, 0, 35000]

これ、チームで何度も議論になった部分なんですけど、単純な「ログ監視だけ」であればCloudWatchの方が安いんですよ。ただし、APM（アプリケーションパフォーマンスモニタリング）とセキュリティを含めると話が変わってくる。Datadogなら、これらを一つのプラットフォームで統合できるから、複数ツールを組み合わせるよりはむしろ安くなることもあります。

実際にうちのチームがやったのは、以下のような構成にすることで、月額をDatadog基本機能で約35万円くらいに抑えたんですよ。

CloudWatch + Datadogの使い分け構成

最終的に落ち着いた構成は、こんな感じです：

  • CloudWatch: AWS環境メトリクス、ALB/Lambda/DynamoDBのネイティブメトリクスのみ
  • Datadog: アプリケーションログ、カスタムメトリクス、APM、セキュリティスキャン

こうすることで、「AWSネイティブはCloudWatch」「クロスプラットフォーム監視はDatadog」という責任分界が明確になって、スキル的にもコスト的にも最適化できた感じです。実装してみると、思ったより複雑じゃなかったし、チームの満足度も上がりました。

2026年時点での機能差分

実は去年と比べて、両ツールとも結構進化してるんですよね。特にCloudWatchはここ1年で改善が目立つ。

機能CloudWatchDatadog
ログ検索速度改善中だが秒単位100ms以下
カスタムダッシュボード基本的高度なカスタマイズ可能
APM機能X-Ray（機能限定）フル機能
インテグレーションAWS中心（200+）1000+（マルチクラウド対応）
ログ異常検知手動ルールベースAI自動検知（2025年末搭載）
コスト低（ログ重視）高（フル機能利用時）
セキュリティスキャンGuardDuty連携ネイティブCSPM/CWPP
リアルユーザーモニタリング(RUM)CloudWatch RUMRUM + セッションリプレイ

正直、ここ2年でCloudWatch Insightsの検索性能も上がってるんですよ。特にCloudWatch Logs Insightsのクエリ言語が充実してきて、複雑な集計もできるようになった。ただしUIの快適さという点では、Datadogが依然リード。気持ちよく使える、という点でやはり差がある。

実装パターン：どっちを選ぶ？

flowchart TD
    A[監視ツール選定] --> B{システム構成}
    B -->|AWS単一環境| C{ログ量}
    B -->|マルチクラウド| D[Datadog必須]
    C -->|1日10GB以下| E{APMが必要？}
    C -->|1日10GB以上| F{セキュリティ監視}
    E -->|不要| G[CloudWatch推奨]
    E -->|必要| H[CloudWatch + X-Ray<br/>or Datadog]
    F -->|必須| I[Datadog推奨]
    F -->|不要| H
    style D fill:#ff9999
    style G fill:#99ff99
    style I fill:#99ccff

うちのチームが得た結論としては、こんな感じですね。

CloudWatchを選ぶべきケース

  • AWS環境のみで、マルチクラウド対応が不要
  • ログ量が1日10GB程度で、コスト最小化を優先
  • X-Rayで十分なアプリケーション監視ができている
  • チーム全体がAWSに詳しく、他のツール学習コストをかけたくない

Datadogを選ぶべきケース

  • マルチクラウド環境（AWS + GCP + Azure等）
  • アプリケーション層の詳細なパフォーマンス監視が必須
  • セキュリティ監視（CSPM・CWPP）も一緒にやりたい
  • チーム規模が大きくて、高度な可視化・分析機能が欲しい
  • 他社SaaS（Slack、PagerDuty等）との統合を重視

実装例：Datadog APMの設定

Datadogに移行した際、APM（Application Performance Monitoring）の設定がなかなか奥深かったんですよね。簡単な例として、Node.jsアプリケーションにDatadog APMを組み込む場合、こんな感じになります。

// datadog-tracer-init.ts
import tracer from 'dd-trace';
import express from 'express';

tracer.init({
  service: 'my-api-service',
  env: 'production',
  version: '1.0.0',
  logInjection: true,
  profiling: {
    enabled: true,
    sourceMap: true
  },
  appsec: {
    enabled: true,
    rules: 'https://myorg.datadoghq.com/api/v2/apm/appsec'
  }
});

const app = express();

app.get('/api/users/:id', async (req, res) => {
  const span = tracer.activeSpan();
  
  // カスタムタグを追加
  span?.setTag('user.id', req.params.id);
  span?.setTag('custom.metric', Math.random());
  
  try {
    const user = await db.users.findById(req.params.id);
    span?.setTag('db.hit', !!user);
    res.json(user);
  } catch (err) {
    span?.setTag('error', true);
    span?.log({ error: err.message });
    res.status(500).json({ error: 'Internal error' });
  }
});

export default app;

これを設定すると、Datadogのダッシュボードで自動的にレイテンシ分布、エラー率、スパン別の実行時間などが可視化されるんですよ。CloudWatchでこれをやろうとすると、CloudWatch Logsにカスタムメトリクスを書き込んで、それをCloudWatch Metricsに変換して…という多段階の処理が必要になるんですけど、Datadogなら最初からこの形で動作する。そこが地味に便利なんですよね。

ログ取込とリテンション戦略

実は一番悩むのがログ保存期間とコストのバランスなんですよね。

CloudWatchの場合

  • ログ保存: 1GB = 0.03〜0.5円（保存期間により変動）
  • クエリ実行: スキャン容量課金（約0.005円/GB）
  • 月50GB保存 + 3GB/日クエリの場合、月額3万円程度

Datadogの場合

  • ログ取込: 1GB = 約30円（インデックス費）
  • ホットストレージ: 30日間無料（31日目以降は段階的）
  • アーカイブ: S3/GCS連携でコスト削減可能
  • 月50GB取込の場合、月額15万円（フル機能なし）+ アーカイブ費

重要なのは、Datadogでも「ログアーカイブ」という機能があって、S3に自動でログを流せるんですよ。これを使うと、長期保存のコストを大幅に削減できます。うちの場合、Datadogでホットログは30日だけ保持して、それ以降はS3（Glacier）に自動アーカイブするという構成にしました。正直、この設定次第でコストは大きく変わります。

{
  "retention": {
    "hot_storage_days": 30,
    "archive": {
      "enabled": true,
      "destination": "s3://my-log-archive/datadog-logs/",
      "retention_days": 365
    }
  }
}

インシデント対応時の違いを実感

正直、CloudWatchとDatadogの最大の差は「問題が起きたときの対応速度」なんだと思うんですよ。

先月、本番環境でエラー率が3%まで急騰したインシデントが起きたんですけど、Datadogだと30秒でダッシュボードから異常を検知できました。ログを見ると、特定のエンドポイント（/api/payment/process）でタイムアウトが発生してることが一目瞭然。さらにAPMデータを見ると、データベースクエリの実行時間が通常の3倍になってることまで、クリック一つで分かった。

CloudWatchでこれを同じ時間でやろうとすると、CloudWatch InsightsとX-Rayと、複数のツールを行き来して、手動でクエリを書いて…という流れになるんですよ。実際、過去に同じような状況でCloudWatchで調査した時は、原因特定まで10分かかってました。その差は、ビジネスインパクトとしては結構大きいんですよね。

まとめ

CloudWatchとDatadog、2026年時点での選定基準はこう考えてます。

  1. AWS単一環境で低コスト優先→CloudWatch ただし、ログ量多い場合は検索性能の課題あり。改善されてきてるけど、まだ実務的には待ち時間が発生することがある。

  2. マルチクラウドやAPM重視→Datadog コスト高いが、統合監視で運用効率化できるんですよ。人件費考えたら、むしろ黒字になることもある。

  3. ハイブリッド構成推奨 AWS基盤メトリクスはCloudWatch、アプリケーション層はDatadog、という使い分けが現実的。うちもこれで落ち着きました。

  4. ログアーカイブ戦略が鍵 どちらを選んでも、長期保存はS3/GCSに流すことでコスト最適化可能。ここを舐めるとコスト爆発するので注意。

  5. チーム規模で判断 5名以下の小規模チームならCloudWatchで十分。20名以上のエンタープライズなら、統合監視プラットフォームの効率性でDatadog検討価値あり。

実装する際は、既存環境を理解した上で、試験環境で実際に動かしてみることをお勧めします。特にDatadogは初期設定が複雑なので、導入前に専門家のレビューを受けるといいかも。正直、僕らも最初はいくつかミスをしてコスト無駄にしちゃったし。皆さんはどちらのツールを使ってますか？実装の工夫があれば教えてもらいたいです。

U

Untanbaby

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

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

関連記事

DevOps・SRE

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

DevOps・SRE

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

DevOps・SRE

CodePipeline V2とCodeBuild Fleet導入記：ビルド待機時間が20分から5分に短縮された話

DevOps・SRE

CodePipeline V2 × CodeBuild Fleet マルチアカウントCI/CD完全ガイド2026

DevOps・SRE

本番環境で障害テストしてみた話｜カオスエンジニアリングが2026年でこんなに変わってた

DevOps・SRE

SLO設計で2年失敗し続けた僕が、チームに本当に定着するまでの実装記録

← 記事一覧に戻る