Datadog を検討し始めると、「結局いくらかかるのか」が分かりにくいという壁に当たります。製品ごとに課金の単位が違い、ホスト数、データ量、件数が組み合わさって請求額が決まるからです。この記事では、Datadog がどんなサービスかを短く押さえたうえで、料金の仕組みを製品ごとに分けて説明し、自分の環境で見積もる手順までをまとめます。
料金の数字は、とくに断りがない限り 2026 年 11 月時点で Datadog の公式サイトに載っている米ドルの定価です。契約の条件や量によって変わるので、実際の金額は公式の価格ページと見積もりで確かめてください。
Datadog とは
Datadog はサーバー、コンテナ、アプリケーション、データベース、クラウドサービスなどの状態をひとつの画面に集めて見る、SaaS 型の監視サービスです。メトリクス (CPU 使用率や接続数のような数値の推移)、ログ、トレース (1 つのリクエストがどのサービスをどう通ったかの記録) をまとめて扱えるので、オブザーバビリティ (システムの中で何が起きているかを外から把握できる状態) の基盤として使われます。オブザーバビリティの考え方は オブザーバビリティとは で説明しています。
データの集め方は大きく 2 つあります。1 つはサーバーに Datadog Agent というプログラムを入れて、そのホストやその上で動くソフトウェアの情報を送る方法です。もう 1 つは AWS や Google Cloud などのクラウドと API でつなぎ、クラウド側が持っているメトリクスを取り込む方法です。
機能は「製品」という単位に分かれていて、使う製品だけを契約します。代表的なものは次のとおりです。
| 製品 | 何を見るか |
|---|---|
| Infrastructure Monitoring | ホストやコンテナのメトリクス、各種ミドルウェアのインテグレーション |
| APM | アプリケーションのトレース、エンドポイントごとの遅延やエラー |
| Log Management | ログの収集、検索、保存 |
| Database Monitoring | クエリ単位の性能、実行計画、DB ホストの状態 |
| RUM / Synthetic Monitoring | 実際のユーザーの体験、外形監視 (定期的なテストの実行) |
| Cloud Security など | セキュリティの検知や設定の監査 |
この「製品ごとに契約する」という作りが、そのまま料金の分かりにくさにつながっています。
料金の基本: 製品ごとに課金の単位が違う
Datadog の料金は製品ごとの使用量を暦月ごとに集計して計算されます。単位は製品によって違い、大きく分けると「ホストの数」で決まるものと、「データの量や件数」で決まるものがあります。
主な製品の課金単位と定価を表にしました (2026 年 11 月時点、公式の価格一覧より)。左から年契約、月ごとの契約、オンデマンド (契約の量を超えた分や、契約なしで使う分) の単価です。
| 製品 | 課金の単位 | 年契約 | 月契約 | オンデマンド |
|---|---|---|---|---|
| Infrastructure Pro | ホスト / 月 | $15 | $18 | $18 |
| Infrastructure Enterprise | ホスト / 月 | $23 | $27 | $27 |
| APM | APM ホスト / 月 | $31 | $36 | $36 |
| Database Monitoring | DB ホスト / 月 | $70 | $84 | $84 |
| カスタムメトリクス (超過分) | 100 メトリクス / 月 | $5 | $5 | $5 |
| ログの取り込み | 1 GB | $0.10 | $0.10 | $0.10 |
| ログのインデックス (15 日保持) | 100 万件 / 月 | $1.70 | $2.04 | $2.55 |
| Flex Logs Storage | 100 万件 / 月 | $0.05 | $0.06 | $0.075 |
このほか、Infrastructure には最大 5 ホスト、メトリクスの保持 1 日の無料プランがあります。年契約の列は「from (〜から)」と書かれた開始価格で、量に応じた割引があるとされています。
ホスト数の数え方
ホスト単位の製品 (Infrastructure、APM、Database Monitoring など) は、ホスト数を 1 時間ごとに数えます。標準のプランでは、月末にその月の 1 時間ごとの値を並べ、上位 1% を除いた中での最大値を請求の対象にします。公式ドキュメントでは「下位 99% の最大値 (ハイウォーターマーク)」と説明されています。
1 か月はおよそ 720 時間なので、除かれる上位 1% はおよそ 7 時間分です。数時間だけホストが増えたなら請求には響きませんが、オートスケールで 1 日以上ホストが増えたままだと、その最大値で 1 か月分が計算されます。もう 1 つ、月ごとの最低利用量を決めておき、それを超えた分だけ時間単位で払う「月額・時間単位のハイブリッドプラン」もあります。
コンテナの数え方
コンテナは 5 分ごとに数えられ、動いていた時間の割合で課金されます。Infrastructure Pro にはホストあたり 5 個、Enterprise には 10 個のコンテナが含まれ、それを超えると前払いなら 1 コンテナあたり月 $1、超過分なら 1 コンテナ・1 時間あたり $0.002 です。1 台のホストに多くのコンテナを詰め込む構成では、この超過分が積み上がります。
カスタムメトリクスの数え方
カスタムメトリクスは「メトリクスの名前とタグの値の組み合わせ (ホストのタグを含む)」1 つを 1 件と数えます。Infrastructure Pro ではホストあたり 100 件、Enterprise では 200 件が含まれ、この枠はアカウント全体で合算されます。件数は 1 時間ごとの種類の数を、その月の時間数で平均して出します。送る頻度やクエリの回数は件数に関係しません。
自分で送るメトリクス (DogStatsD やカスタムチェック) のほかに、AWS のインテグレーションから取り込むメトリクスや、MySQL・PostgreSQL・SQL Server などのインテグレーションで設定して集めるメトリクスもカスタムメトリクスとして数えられることがあります。
ログの数え方
ログは「取り込み」と「インデックス」の 2 段階で課金されます。取り込みは送った量 (圧縮前の GB) で、インデックスは検索できる状態にした件数で決まります。取り込んだログのうち、どれをインデックスするかは除外フィルタで選べます。長く保管したいけれど頻繁には検索しないログには、件数あたりの単価が低い Flex Logs という選択肢もあります。
Database Monitoring の位置づけ
データベースの監視には、Datadog の中に 2 つの段階があります。
1 つ目は Infrastructure に含まれるインテグレーションです。MySQL や PostgreSQL のインテグレーションを有効にすると、接続数、スループット、レプリケーションの遅延といった DB 全体のメトリクスが集まります。RDS や Cloud SQL なら、クラウドとの連携でクラウド側のメトリクスも取り込めます。
2 つ目が Database Monitoring (DBM) という別の製品です。DBM はクエリの単位まで踏み込みます。公式ドキュメントでは、次のような機能が挙げられています。
- 正規化したクエリ (値の部分を伏せて同じ形のクエリをまとめたもの) ごとの実行時間や回数の推移
- 個々の実行のサンプルと、それを実行したユーザーやアプリケーション
- 実行計画 (データベースがクエリをどう処理するかの手順)
- DB ホストごとの状態の一覧と、改善の提案
対応しているのは PostgreSQL、MySQL、MariaDB、Oracle、SQL Server、MongoDB、Amazon DocumentDB、ClickHouse で、自前で動かしている DB と、RDS などのマネージドサービスの両方です。使うには、DB 側の設定 (監視用のユーザーや統計情報の有効化) と、Datadog Agent の導入が必要です。
料金は DB ホストごとで、定価は年契約で月 $70、月契約とオンデマンドで月 $84 です (2026 年 11 月時点、公式の価格一覧より)。DB ホストの数は Infrastructure と同じく 1 時間ごとに数えられ、ハイウォーターマークで請求されます。
DBM は 1 つの DB ホストにつき 200 個の正規化クエリを追跡し、それ以外は「Other Queries」としてまとめます。この 200 は 10 秒ごとの収集で上位に入ったクエリの数なので、長い期間で見ると 200 を超える種類のクエリが記録されることもあります。
DBM を入れるかどうかは、「遅いクエリを Datadog の画面で探して直したいか」で決めるのが分かりやすいでしょう。接続数や遅延の推移が見られれば十分なら、インテグレーションだけで足ります。クエリ単位で調べたいとき、自分で調べる方法としては MySQL のスロークエリの見つけ方 や PostgreSQL のスロークエリの見つけ方 で紹介している手順もあります。
費用が膨らみやすいところ
「Datadog は高い」という声は、単価そのものより、使い始めてから使用量が想定より増えることから出てくる場合が多いようです。増えやすいところは決まっています。
ホスト数が一時的に増えたまま
ハイウォーターマークで請求されるので、負荷試験やバッチのために 1 日以上ホストを増やすと、その月の請求はその台数で計算されます。開発環境や検証環境に Agent を入れたままにしておくのも同じです。
タグの組み合わせでカスタムメトリクスが増える
カスタムメトリクスは組み合わせの数で数えるので、タグを 1 つ足すと件数が掛け算で増えます。たとえば、API の応答時間を endpoint (30 種類) と status (4 種類) のタグをつけて 10 台のホストから送ると、最大で 30 × 4 × 10 = 1,200 件です。これを distribution 型 (既定で 5 種類の集計値を持つ) で送ると、5 倍の 6,000 件になります。
Infrastructure Pro を 10 ホスト契約していれば枠は 1,000 件なので、5,000 件が超過です。定価の $5 / 100 件で計算すると、これだけで月 $250 になります。ユーザー ID や注文 ID のように値の種類が多いものをタグにすると、件数はさらに増えます。
ログを全部インデックスする
ログは取り込みとインデックスで 2 回課金されます。アクセスログやデバッグログをすべてインデックスすると、件数が大きくなります。15 日保持のインデックスを定価 (年契約) で 1 日 1,000 万件使うと、月 3 億件で約 $510 です。
使う製品が少しずつ増える
最初は Infrastructure だけでも、APM、ログ、DBM、RUM と製品を足すたびに課金の単位も増えます。それぞれは小さな金額でも、合計すると最初の見積もりから大きく離れることがあります。
見積もりの考え方
見積もりは、製品ごとに「課金の単位 × 数量 × 単価」を出して足すのが基本です。手順を順に書きます。
- 使う製品を決めます。最初から全部入れる前提にせず、Infrastructure だけ、または Infrastructure と APM から始めるなど、範囲を絞ります。
- 製品ごとに数量を数えます。ホスト数はピーク時の台数で数えます (ハイウォーターマークのため)。コンテナ数、DB ホスト数、1 日あたりのログの量と件数、カスタムメトリクスとして送りたいメトリクスとタグの種類を書き出します。
- 単価を当てはめます。年契約か月契約かで単価が違います。超過分はオンデマンドの単価になる点も含めます。
- 余裕を見ます。使い始めるとログやメトリクスを足したくなるので、増える前提で幅を持たせます。
例として、Web サービスを次の構成で監視する場合を、定価で試算してみます。
- アプリケーションと周辺のホスト 10 台 (Infrastructure Pro)
- そのうち 4 台で APM
- RDS の DB ホスト 2 台で Database Monitoring
- ログの取り込み 月 300 GB、そのうち 5,000 万件を 15 日保持でインデックス
| 項目 | 年契約の単価で | オンデマンドの単価で |
|---|---|---|
| Infrastructure Pro 10 ホスト | $150 | $180 |
| APM 4 ホスト | $124 | $144 |
| Database Monitoring 2 ホスト | $140 | $168 |
| ログの取り込み 300 GB | $30 | $30 |
| ログのインデックス 5,000 万件 | $85 | $127.50 |
| 合計 (月) | $529 | $649.50 |
これはあくまで定価で計算した目安です。実際にはコンテナの超過、カスタムメトリクスの超過、APM のスパンの超過などが加わることがあり、逆に量に応じた割引が入ることもあります。
使い始めたあとは、datadog.estimated_usage.hosts や datadog.estimated_usage.logs.ingested_bytes のような推定使用量のメトリクスでダッシュボードやモニターを作れます。ほぼリアルタイムで使用量の増え方を追えますが、公式ドキュメントによると請求額とは平均で 10〜20% ほどずれることがあるので、目安として使います。集計には sum を使います。
どんなチームに合うか
Datadog が向いているのは、たとえば次のような状況です。
- コンテナやマイクロサービスでサービスの数が多く、メトリクス・ログ・トレースを 1 か所で横断して見たい
- 監視の仕組みを自前で運用する人手を割けず、SaaS に任せたい
- 複数のクラウドやミドルウェアを使っていて、既製のインテグレーションで素早く監視を始めたい
- 使用量を管理する担当を置き、タグの設計やログの除外フィルタを継続して見直せる
一方で、次のような状況では、費用と得られるものの釣り合いを慎重に見たほうがよいでしょう。
- 監視したいのが数台のサーバーと 1 つのデータベースだけで、死活監視とリソースの監視で足りる
- ログの量が多いが、検索することはまれ (この場合は Flex Logs やアーカイブの使い方を先に考える)
- 使用量を見張る担当がおらず、タグやログの量が管理されないまま増えていきそう
ほかの監視ツールとの違いは データベース監視ツールの選び方 で整理しています。RDS や Aurora を CloudWatch で監視する方法は RDS・Aurora の監視 を見てください。
データベースの中身を見張るには
Datadog の監視は、ホスト、クエリ、ログといったシステムの側の状態が中心です。一方で、「注文が急に減った」「決済の失敗が増えた」「バッチの処理待ちが溜まっている」といった、データベースの中の業務データの変化は、別に見張る仕組みが要ります。MySQL や PostgreSQL のインテグレーションの custom_queries で SQL の結果をメトリクスにする方法もありますが、その場合はカスタムメトリクスとして数えられ、どの値をどの閾値で見るかも自分で決めることになります。
手作業で続けるなら、確認用の SQL を cron で定期的に実行し、結果が範囲を外れたら通知する形になります。業務データの監視の考え方は データベース監視とは にまとめています。
この確認を AI に任せる方法もあります。Scandock は、接続文字列を登録すると、AI がテーブルの構成と実データを読んで、注文数や決済の成否、ジョブの滞留など何を監視するかを決めます。固定の閾値ではなく、値の推移や過去の発火の結末を踏まえて異常かどうかを判断し、異常のときは読み取り専用のクエリで原因を調べてから、根拠と対処案をつけて Slack やメールなどに通知します。DB サーバーにエージェントを入れる必要はありません。