本番ログ月58万円→8万円に削減。3つのツール並行運用をやめた話
CloudWatch・Datadog・ELKを同時運用して月58万円吸い上げられていた。重複投資を整理して月50万円削減した実体験とツール選びの正解を語ります。
本番ログ分析で月50万円削減できた話
先日チームのSlackで『CloudWatchの請求、また跳ね上がってた』という悲鳴が上がって。確認してみたら月58万円。ログ保存だけで年700万円近く吸い上げられてたんですよ。その時点で3つの監視ツールを並行運用してたから、正直「これ、どれを選ぶか」以前に「何を捨てるか」が重要なんだと気づいた。2026年時点で本番運用した実体験をそのまま書きます。
ツール選びに失敗した原因、実は「使い分けの線引き」がなかった
うちのチームが月50万円も無駄にしていた理由は、シンプルです。CloudWatchで全ログを取りながら、DatatdogとELKも「念のため」で同じデータを重複保存してた。まさに「保険をかけてる」状態。
実際のアーキテクチャがこれです：
graph TD
A["Application Logs"]
A --> B["CloudWatch<br/>すべて"]
A --> C["Datadog<br/>すべて"]
A --> D["ELK Stack<br/>すべて"]
B --> X["💸 月58万円"]
C --> X
D --> X完全に無駄ですよね。重複投資の塊だった。だから6ヶ月かけて整理し直しました。
CloudWatch・Datadog・ELK、2026年時点での特性を正直に
実装した分析で気づいたことですが、「どれが最高」じゃなくて「何に使うか」が全てなんです。
| ツール | 得意なこと | 苦手なこと | 本番コスト感 | 導入フェーズ |
|---|---|---|---|---|
| CloudWatch | AWS統合・リアルタイム検索・基本的なダッシュボード | 複雑なAnomalyDetection・大規模ログ分析・カスタムメトリクス | 月10万～80万円（ログ量に比例） | 初期・小〜中規模 |
| Datadog | APM・分散トレーシング・AI異常検知・美しいダッシュボード | 初期コスト・エージェント管理の負担 | 月20万～150万円（機能選択次第） | 成長段階・大規模 |
| ELK Stack | カスタマイズ性・コスト効率（自前管理） | 運用負荷・スケーリング設計・セキュリティ維持 | 月5万～30万円（インフラ費用） | 確立段階・大規模 |
正直に言うと、2026年のうちの選択は「役割分担」です。それぞれの得意分野に仕事を分けて、重複を排除する。これだけで劇的に変わります。
うちが実装した本番ログ戦略（コスト月50万→月8万）
1. CloudWatch→S3+Athena への段階的移行
まず取った対策は、CloudWatch Logsへの全ログ送信を止めたこと。代わりにFirehoseでS3に直送します。
CloudWatch Logsは「リアルタイムで見たいログだけ」に絞りました。本番エラーと警告のみ。それ以外はすべてS3経由です。
# ログ送信先の新しい整理
CloudWatch Logsの出力層
├─ 本番エラー・警告のみ → CloudWatch（容量制限）
├─ 全ログ → Firehose → S3 Intelligent-Tiering
└─ リアルタイム分析が必要 → Datadog Agent（抽出的に）これだけで月45万円削減。S3のストレージコストは月3万円程度で、Athenaのクエリ費用が月2万円。CloudWatchの月58万円から月8万円に落ちました。
実装したFirehose設定がこれです：
{
"DeliveryStreamName": "prod-logs-to-s3",
"S3DestinationConfiguration": {
"RoleARN": "arn:aws:iam::ACCOUNT:role/FirehoseRole",
"BucketARN": "arn:aws:s3:::prod-logs-archive",
"Prefix": "logs/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/hour=!{timestamp:HH}/",
"BufferingHints": {
"SizeInMBs": 128,
"IntervalInSeconds": 60
},
"CompressionFormat": "GZIP",
"ProcessingConfiguration": {
"Enabled": true,
"Processors": [
{
"Type": "Lambda",
"Parameters": [
{
"ParameterName": "LambdaArn",
"ParameterValue": "arn:aws:lambda:ap-northeast-1:ACCOUNT:function:LogFilterFunction"
}
]
}
]
}
}
}ポイントは、Lambdaで「重要なログだけ」をフィルタリングしてS3に送ること。DEBUGログの全数保存をやめるだけで、データ量は1/3に圧縮できました。タイムスタンプはサーバーサイドで統一しておくことも重要です。後述の落とし穴で詳しく書きます。
2. Datadog は「APM・分散トレーシング専用」に絞った
最初うちは「すべてのログをDatadogに送信」してました。でも2026年時点では、Datadogの本当の価値は別のところにあります。ログ送信で月数十万円吸われるくらいなら、本来の得意分野に特化させた方が遥かに効率的です。
実装を整理したのは、こんな感じ：
Datadog Agent の役割を再定義
├─ APM（アプリケーションパフォーマンス）→ 全エージェント
├─ 分散トレーシング（マイクロサービス間通信） → 本番環境のみ
├─ インフラストラクチャメトリクス → 全環境
└─ エラーログ＋本番障害ログ → 抽出的に（月1GB以下）DatatdogのAI異常検知（Anomaly Detection）は本当に優秀です。3日前のトラフィック量と比較して「今日いつもと違う」を自動検出します。うちは深夜のリソースリークを2回これで発見しました。アラート設定がちゃんと入ってさえいれば、人間が寝てる間に問題を検出して教えてくれるんです。
でも「全ログを送る」必要はない。エラーと本番障害だけで十分。月のDatdog費用が月48万円から月15万円に落ちました。
3. ELKは「内部監査・デバッグ用」に限定
ELK Stackは自前運用だから「インフラコスト」ですけど、月5万円程度のEC2 2台で事足ります（t3.large × 2）。開発チームがトラブルを深掘りする時に必要な、詳細なログが全部ここに集約されます。
ここに流す情報は「過去30日分の詳細ログ」だけ。それより古いログはS3に移行します。「あの時何が起きたんだっけ」という問い合わせに応えるくらいの役割で十分です。
# Filebeat設定で「Warnログ以上」のみELKに流す
- type: log
enabled: true
paths:
- /var/log/application/*.log
fields:
level: warn
filter:
- regexp:
message: "^(WARN|ERROR|CRITICAL|FATAL)"これで「月数千万件のログ」から「重要な数千件」に絞られます。
本番で気づいた落とし穴と対策
1. タイムスタンプのズレで1時間分のログが消える
S3→Athenaの時にパーティションキーをタイムスタンプ（秒単位）で切ったら、アプリケーション側のクロックがズレてて、フォルダ構造がめちゃくちゃになった。結果1時間分のログが検索できなくなりました。
対策として、ログ受信時のタイムスタンプ（サーバーサイド）を使うように修正。Firehoseが受け取った時刻を基準にしました。アプリケーションサーバーのクロックなんて信用できません。
{
"timestamp": "!{timestamp:yyyy-MM-dd'T'HH:mm:ss.SSS'Z'}",
"received_at": "!{timestamp:yyyy-MM-dd HH:mm:ss}",
"data": "${log_data}"
}2. Datadog Agent がメモリリークで本番を止めかけた
APMを有効にしたDatadog Agentが、メモリを垂れ流してました。標準設定だと「全スタックトレースを保存」するから、エラーが多い日は数GB吸い上げられます。本番サーバーのメモリが圧迫されて、アプリケーション側がOOM Killerで落とされました。数分間のダウンタイムでした。
対策は、スタックトレース保存の上限を設定。メモリ使用量を明示的に制限しました：
# /etc/datadog-agent/datadog.yaml
apm_config:
enabled: true
max_memory: 512
max_cpu_percent: 20
span_buffer_size: 100
trace_writer:
payloads_per_second: 100これで「重要なトレースだけ」に限定。月のDatadog容量を1/3に圧縮できました。本番サーバーのリソースも余裕が出ました。
3. Athena クエリが「ログ探す間に月5万円かかる」問題
S3にあるログを片っ端からAthenaでクエリすると、スキャン対象が多すぎてコストが跳ね上がります。半日で月の予算を吹き飛ばすことも珍しくありません。
対策は「パーティションプルーニング」を徹底。日付・時間でフォルダを切って、検索範囲を明示的に限定します。これはめんどくさい制約に見えますが、本当に効きます。
-- ❌ 悪い例：全期間スキャン（月100万円以上）
SELECT * FROM prod_logs WHERE level = 'ERROR';
-- ✅ 良い例：3日分だけスキャン（月1000円程度）
SELECT * FROM prod_logs
WHERE
year = 2026
AND month = 8
AND day IN (8, 9, 10)
AND hour >= 14
AND level = 'ERROR';地味だけど本当に効きます。月5万円のAthena費用を月3000円に削減できました。
2026年のログ分析、本当の使い分け方
正直、ツール選びで一番重要なのは「何を分析するのか」です。ログ量と分析の複雑さで、選ぶべきツールが変わります。
pie title コスト削減の実績（月額）
title 削減内訳
"CloudWatch削減" : 45
"Datadog削減" : 33
"S3・Athena追加" : 5
"ELK据え置き" : 5うちの実装判断基準：
- 月1TB以下のログ：CloudWatch + S3/Athena でいい。シンプルで十分。開発チーム小さければこれで事足ります。
- 月1～10TB：Datadog + CloudWatchの役割分担。APMはDatadog、ログ長期保存はS3。これが今のうちのスタイル。
- 月10TB以上：ELK Stack自前運用が得。ただし運用負荷が跳ね上がります。うちは「月30TBなら諦めてDatadog一本化」を検討中です。
まとめ
ログ分析で月50万円削減できたのは、ツールの最適化じゃなくて「何を保存するか」「何を分析するか」を整理したからです。重複投資を認識して、役割を明確に分けるだけで劇的に変わります。
3つの実装ポイント：
- CloudWatch Logs全量保存は辞める → Firehose経由でS3に直送。CloudWatch は本番エラーのみに限定。
- Datadog は APM・分散トレーシング専用にする → ログ保存で月数十万円かかるなら、役割を絞る。
- ELKは30日分デバッグ用に限定 → 過去ログはS3+Athena。スケーリング負荷も減る。
あと正直、2026年時点だと「ログ分析ツール選び」より「ログそのものの減量」が効きます。DEBUGログをDEBUG環境だけにする、本番環境ではWARN以上に絞る、アプリケーション側でも「不要なログを出さない設計」を心がける。こっちの方が、ツール乗り換えより遥かに安くて、遥かに効果的です。
うちのチームも「月50万円削減」って言い方してますけど、実態は「これまでの無駄を整理した」だけ。皆さんのチームも、請求書をもう一度見直してみてください。必ずムダが見えます。