DevOps・SRE

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

CloudWatchのクエリ遅延で本番が止まった経験から、ログ分析ツール3つの現実的な使い分けを解説。チーム規模と予算で決まる、本当に必要な選択基準とは。

DevOpsSREログ分析CloudWatchDatadogELK運用本番環境

ログ分析で本番が火を噴いた話｜2026年の選択と運用の現実

先日ずっと気になってた話があって、チームで「ログ分析ってどうしてこんなに複雑なんだ」って地獄を見てたんですよ。僕たちが導入したCloudWatchが突然クエリ遅延で本番の問題追跡ができなくなったのがきっかけなんですが、その後DatadogとELKスタック両方試した経験から見えてきたことがめちゃめちゃ大事だと思うんです。

実際、2026年のこの時点で「正解のログ分析ツール」ってもうないんですよ。プロジェクトの規模、チームの技術スタック、なにより予算で大きく変わるし、運用の負荷がツール選びに直結する。今日はその辺りの現実を、失敗談と一緒に共有したいと思います。

CloudWatchは思ったより「足りない」という現実

うちのチームが最初にハマったのがこれなんですが、CloudWatchって「ログを吐き出すまでは楽」なんですよ。AWS使ってるエンジニアなら設定も簡単だし、CloudWatch Logs Insightsで基本的なクエリもすぐ動く。でも本番環境で「このログ群から異常値を抽出したい」「複数のログストリーム横断で分析したい」ってなると、途端に辛くなる。

具体的に何が起きたかというと、あるインシデント時に「過去7日間のエラーログで、特定のユーザーIDが関係してるケース全部抽出してほしい」って要件が出たんです。CloudWatch Logs Insightsで書いたクエリがこれです：

fields @timestamp, @message, userId, statusCode
| filter statusCode >= 400 and userId = "user_12345"
| stats count() as errorCount by @timestamp
| sort @timestamp desc

これが… 30分以上かかるんですよ。一方、同じデータをAthenaで検索（S3にエクスポート）すると10秒で返ってくる。その時点で「あ、これスケールしないな」って気づいたんですね。正直なところ、CloudWatch Logsって最大100個のスキャン深度に制限があるから、大規模ログに対しては設計的に弱いんですよ。

そこからうちのチームはDatadog導入を決めたんですが、実装してみてわかったのは、ツール選びって「検索性能」だけでは判断できないということなんです。

Datadog導入で月額300万円の請求と戦った6ヶ月

正直に言うと、Datadog最初の3ヶ月で月額が300万円超えました。何もしてないのに跳ね上がるんですよ。原因はログインジェストレート。アプリケーションログ・アクセスログ・DBクエリログ・セキュリティログが全部Datadogに吸い込まれる設定になってて、実質「全ログ垂れ流し」状態だったわけです。

Datadog側でカスタムメトリクスまで定義してたから、「ログ分析するために月300万？」ってなるわけですよ。そこから4ヶ月かけて以下の対策を打ちました：

  1. ログの事前フィルタリング - Datadogに送る前にFluentdで不要ログを落とす。エラーログと本番環境のログだけに絞った
  2. サンプリング導入 - アクセスログは1%サンプリング。重要なリクエスト（エラー・遅延）は100%キャプチャ
  3. ログ保持期間の短縮 - 全ログ30日→7日。エラーログだけ90日保持に変更

これで月額が月額110万円まで落ちました。ただしここから見えてきたのは「Datadogが高い」じゃなくて「ログの取捨選択をちゃんとしないと、どのツールでも高くなる」という現実なんですね。

それと、Datadogのいいところは検索速度だけじゃなくアラート設定の融通性なんですよ。複数のログパターンを組み合わせて「このエラーが5分以内に3回出たらSlack通知」みたいなルールが簡単に書ける。CloudWatchだとこれがかなり複雑で、Lambda経由でカスタムロジック組まないといけません。

ELKスタックを本番運用して1年、地獄の自動化作業

実は並行してELKスタック（Elasticsearch・Logstash・Kibana）も自前構築して運用してたんですよ。AWS上でElasticsearchを使って、EC2でLogstashを走らせるやつです。理由は「Datadogのコスト削減できないか」という藁にもすがる思いでした。

最初の設計はこんな感じでした：

graph TB
    subgraph "Application Servers"
        App1["App Instances"]
        App2["App Instances"]
    end
    
    subgraph "ELK Stack on AWS"
        Logstash["Logstash<br/>ログパース・フィルタリング"]
        ES["Elasticsearch<br/>インデックス管理"]
        Kibana["Kibana<br/>可視化・検索"]
    end
    
    subgraph "Storage & Monitoring"
        S3["S3<br/>ログアーカイブ"]
        CloudWatch["CloudWatch<br/>メトリクス"]
    end
    
    App1 -->|Filebeat| Logstash
    App2 -->|Filebeat| Logstash
    Logstash -->|Index| ES
    ES -->|Query| Kibana
    ES -->|Archive| S3
    Kibana -->|Metrics| CloudWatch

これ、実装するのは簡単でも運用が死ぬほどしんどいんですよ。Elasticsearchのインデックス管理だけで月1回は「なぜかディスク満杯になってる」という修羅場が来ます。本来はIndex Lifecycle Management（ILM）で自動化するはずなんですが、設定ミスると古いインデックスがどんどん溜まったり、ローテーションが失敗したりして、結局エンジニアが手動対応になるんですね。

実際に僕たちが経験した地雷は：

  • JVMメモリリーク - Elasticsearchが月1回くらい謎のメモリ圧迫で落ちます。ログを見ても原因不明で、最終的には毎週リスタートスケジュール組むはめに
  • Logstashの遅延 - パース処理が重くなるとキューが溜まって、ログが数時間遅れで吸い込まれる。本番対応の時間が足りなくなる
  • クエリパフォーマンス - 全ログを全文検索するKibanaクエリが、1日以上のデータを対象にするときっかけで5分以上かかる

これらの問題をFixするためにチームのエンジニアが月30時間くらい運用に取られてました。Datadogは「月110万円払ってうちが全部面倒見る」という値段だったから、結局ELKスタックのほうが割高だったんですよ。人件費換算すると。

2026年時点で見える「ログ分析ツール選定の正解」

1年半の試行錯誤を経て、うちのチームがようやく安定した構成に落ち着いたので、その経験から見えてきた判断基準を整理します。

CloudWatch vs Datadog vs ELK の現実的な使い分け

項目CloudWatchDatadogELK Stack
初期構築15分1日2週間
月額コスト月5～15万円月50～300万円月0円（インフラ費用のみ）
検索速度遅い（100行制限）高速（秒単位）中程度（インデックス設計次第）
アラート設定簡単複雑だが強力手動設定が多い
運用負荷ほぼゼロ月4～8時間（フィルタリング調整）月30時間以上
スケーラビリティ中程度高い自分たちの構成次第
学習コスト低い中程度高い

正直なところ、大半のチームにはDatadog（月50～100万円レンジ）で十分だと思います。理由は単純で、「月100万円÷エンジニア給与（月50万）= 2人月分の運用コスト」と考えると、ELKで2人が月30時間×12ヶ月運用するより断然安いんです。

CloudWatchだけで済むのは本当に小規模（ログボリューム月100GB以下）のプロジェクトだけですね。うちで試した「CloudWatch単独でいけるか」という実験は3ヶ月で挫折しました。

実装パターン：2026年の現実的な構成

うちのチームが今運用してるのはこれです。正直、Datadogの値段は高いけど、検索速度と運用負荷のバランスがいいという判断です：

graph TB
    subgraph "Application Layer"
        App1["ECS Tasks<br/>アプリログ"]
        App2["Lambda<br/>実行ログ"]
        RDS["Aurora<br/>スロークエリ"]
    end
    
    subgraph "Collection & Filter"
        FB1["Filebeat<br/>ECS用"]
        FB2["CloudWatch Logs<br/>Lambda用"]
        FB3["Enhanced Monitoring<br/>RDS用"]
        Filter["カスタムフィルタ<br/>Datadog Agent"]
    end
    
    subgraph "Datadog Platform"
        Logs["Logs Pipeline<br/>パース・サンプリング"]
        Analytics["Log Analytics<br/>検索・分析"]
        Monitoring["APM & Monitoring<br/>メトリクス連携"]
    end
    
    subgraph "Archival & Compliance"
        S3["S3 Bucket<br/>30日以上保持"]
        Athena["Athena<br/>長期分析"]
    end
    
    App1 --> FB1
    App2 --> FB2
    RDS --> FB3
    FB1 --> Filter
    FB2 --> Filter
    FB3 --> Filter
    Filter --> Logs
    Logs --> Analytics
    Analytics --> Monitoring
    Logs -->|Export| S3
    S3 --> Athena

この構成のポイントは以下の通り：

  • 複数ソースからのログを統一的に扱う - ECS・Lambda・RDSのログを全部Datadogに集約。ただしフィルタリングで量を絞ります
  • 長期保存はS3+Athena - Datadog保持期間7日で最新の異常検知は高速。月次分析が必要なときはAthenaで過去ログを検索
  • APMとログを連携 - トレースIDでアプリログとメトリクスを繋ぐことで、単純なログ検索より問題原因の特定が圧倒的に早い

検索パフォーマンス：実装コード例

実際にこれが効いた例が「本番でエラーが急増した時」の対応です。Datadogなら秒単位で以下が検索できます：

{
  "query": "status:error AND service:order-api AND duration:[5000 TO *]",
  "time_range": "past_15m",
  "group_by": ["host", "error_code"],
  "sort": [{
    "timestamp": "desc"
  }]
}

結果が2～3秒で返ってきて、「どのホストで、どのエラーコードが出ているか」が一目瞭然ですよ。CloudWatchでこれをやると、Logs Insightsのタイムアウトと戦うことになります。

コスト削減：ログサンプリングの実装

Datadogのコストを抑えるために実装した工夫がこれです。本番環境では全ログ、ステージングは1%サンプリングという割り切り方をしてます：

// Node.js + Winston logger例
const winston = require('winston');
const transport = new winston.transports.Http({
  host: 'http-intake.logs.datadoghq.com',
  path: '/v1/input/{DD_API_KEY}',
  ssl: true,
  auth: {
    bearer: process.env.DD_API_KEY
  },
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.json(),
    // サンプリングロジック
    winston.format((info) => {
      if (process.env.ENVIRONMENT === 'staging') {
        // ステージングは1%だけDatadogに送信
        if (Math.random() > 0.01) {
          return false;
        }
      }
      // エラーログはサンプリング対象外
      if (info.level === 'error' || info.level === 'fatal') {
        return info;
      }
      return info;
    })()
  )
});

const logger = winston.createLogger({
  transports: [transport]
});

これで月額を30%削減できました。ステージングの詳細ログが必要なときはAthenaで過去データを引っ張ることもできるし、バランスがいいんですよ。

運用で見えたアンチパターン

最後に「こんなことしてたら失敗する」という地雷をまとめます。正直ハマった経験です：

「全ログ一律で送信」は絶対やめたほうがいい。これやると絶対コストが爆発します。アクセスログだけで月100GB超えることもありますから。最初から「どのログが必要か」を定義しましょう。

ツール決定を検索速度だけで判断するのも危険ですね。Datadogが速いからといって、チーム規模と予算を無視して導入すると炎上します。CloudWatchで十分ならCloudWatchで運用ノウハウを深める方がいい場合もあります。

ELKスタックを選ぶなら、導入時点でインデックス設計を決めてください。どの期間でロテーション、どのフィールドで集約するのか、これを後回しにすると後で地獄になります。

アラート設定をセットアップして放置するのも地味に危険ですよ。どのツールでも同じですが、アラート設定した後は定期的に見直しが必要です。False Positiveが増え続けると、誰も通知を見なくなるんですね。うちのチームは月1回「このアラート本当に必要？」という棚卸しを入れてます。

まとめ

2026年の今、「最高のログ分析ツール」はありません。あるのは「自分たちのプロジェクトに最適なツール」だけです。判断基準は以下の3点ですね：

  • ログボリューム - 月100GB以下ならCloudWatch、それ以上はDatadogかELK
  • 検索頻度と速度要件 - 本番対応で秒単位の検索が必要ならDatadog、定期的な分析ならELKやAthena
  • 運用リソース - エンジニアの手が空いてるならELK自前構築で学べるし、それが無理ならマネージドサービス（Datadog）に払う価値がある

正直、うちのチームは**Datadog月100万円+CloudWatch（メトリクス・アラート用）+S3+Athena（長期分析用）**の組み合わせで落ち着きました。これで運用負荷も月4～8時間だし、本番対応も十分な速度が確保できています。

あなたたちのチームはどのレンジですかね？もし「ログ分析で困ってる」なら、一度現在のログボリュームを見直してみることをお勧めします。意外と「実はこのログ、誰も見てない」って気づくことがあります。そこからが最適化の第一歩ですよ。

U

Untanbaby

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

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

関連記事

DevOps・SRE

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

DevOps・SRE

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

DevOps・SRE

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

DevOps・SRE

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

DevOps・SRE

SLO設計で2年間失敗し続けた僕が、ようやく運用が回り始めた話

DevOps・SRE

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

← 記事一覧に戻る