Datadog ログ料金の 3 層 - Ingest / Index / Flex
Datadog のログ料金は、取り込み (Ingest) を GB で、インデックス (Index) をイベント数と保持日数で、長期保存 (Flex Logs) を保存イベント数で数える 3 層構造です。層ごとの課金単位と契約形態、GB からイベント数への換算手順、リハイドレートの 2 段の費用構造を押さえ、保持日数と検索頻度から層を選ぶ判断表を示します。具体的な単価は公式料金ページを参照する構成です。
ログ料金は 3 層で数える
「ログは GB なのか件数なのか」という問いへの答えは「層によって違う」です。Datadog のログ料金は、取り込み (Ingest)、インデックス (Standard Indexing)、長期保存 (Flex Logs) の 3 層に分かれ、それぞれ数える単位が異なります。2026 年 8 月時点の公式料金ページ (US リージョン) では次の構造です。
| 層 | 数える単位 | 契約形態 | 主な注意点 | 何に効くか |
|---|---|---|---|---|
| Ingest (取り込み) | 非圧縮 GB / 月 | 年契約 / 月契約 / オンデマンドの 3 形態 (この層は形態による単価差なし) | 索引に入れなくても掛かる | 送った量そのもの |
| Standard Indexing (索引) | 100 万イベント / 月 × 保持日数 (3 / 7 / 15 / 30 日) | 3 形態で単価が異なり、保持日数が長いほど単価が上がる | 30 日を超える保持は価格非公表 | 検索できる件数と、何日分まで検索できるか |
| Flex Logs Storage (長期保存) | 保存 100 万イベント / 月 (保持 1〜15 ヶ月、最低 30 日分) | 3 形態で単価が異なる | 検索用の Flex Compute は別 SKU (本記事では扱わず、公式料金ページで確認) | 長く残す件数。検索には計算資源を別に選ぶ |
| Flex Logs Starter | 保存 100 万イベント / 月 (保持 3 / 6 / 12 / 15 ヶ月) | 3 形態で単価が異なる (保存と検索計算の一体型) | 月 20 億イベント未満の組織向けと案内 | 小規模の長期保存を 1 つの単価で持つ |
表は上から「送った量 → 検索できる量 → 長く残す量」の順です。請求を左右する変数が層ごとに違うので、「ログ料金を下げる」も層ごとに手段が違います。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。
なぜ取り込みは GB で、インデックスはイベント数なのか
取り込みは Datadog がログを受け取って処理する工程なので、通る量 (非圧縮 GB) で数えます。一方、インデックスは検索できる状態で保持する工程で、1 件のログを何日分置くかが費用の本質なので、イベント数 × 保持日数で数えます。公式もイベント課金は内容の豊かなログを促す設計だと料金ページの FAQ で説明しています (2026 年 8 月時点・出典: Datadog Pricing)。請求は月末に確定します。公式の課金ドキュメントによれば、Datadog は月末に索引されたイベント総数を計算し、契約量以下なら請求は変わらず、超えた分だけがオンデマンド単価 (契約単価より割高) で加算されます (2026 年 9 月時点・出典: Log Management Billing)。契約が月単位なので、1 日だけ跳ねても月平均が契約量に近ければ超過にならない点は運用上の余裕です。2 段課金の基本と索引の設計はログ管理とログインデックスに委ね、本記事は数え方と計算に集中します。
Flex Logs は何が安く、何ができないのか
Flex Logs は保存 (Storage) と検索の計算資源 (Compute) を切り離した層です。公式ドキュメントはログの置き場を 3 つに住み分けています (2026 年 9 月時点・出典: Flex Logs)。
- Standard Indexing: 頻繁に検索し、短期で持つログ (例: アプリケーションログ)
- Flex Logs: 長く残し、ときに急いで検索するログ (例: セキュリティ / トランザクション / ネットワークのログ)
- アーカイブ: ほとんど検索せず、長期保管するログ (例: 監査ログ / 設定ログ)
- 併用時の順序: Standard に置いた期間が終わってから Flex へ (例: Standard 3 日 + Flex 90 日なら Flex には 87 日分)
保存だけの Flex Logs Storage は、検索できる状態で持つ Standard Indexing よりはるかに低い単価で公開されており、この単価差が「長く残すなら層を変える」という判断の根拠になります (実額は公式料金ページ)。検索計算は Starter / XS / S / M / L の 5 段から選び、目安は保存イベント累計が 100 億件未満なら Starter、100〜500 億件なら XS です。制約もはっきりしています。Flex Logs のログはモニターと Watchdog の対象にならず、ダッシュボードは使えます。保持は Starter が 3 / 6 / 12 / 15 ヶ月、XS 以上では 30〜450 日で、Standard と併用した索引では Standard の期間が終わってから Flex に移ります。
GB からイベント数へ換算する公式の手順
「1 日 10 GB のログは何イベントか」に公式の換算式はありません。1 イベントの大きさがログの種類で大きく違うからです。料金ページの FAQ が示す手順は、直近 24 時間の件数を count クエリで数え、30 倍して月間イベント数を見積もる、の 1 つです (2026 年 8 月時点・出典: Datadog Pricing)。件数は Usage 画面の Indexed Logs グラフ、索引の設定画面、Log Explorer の一覧上部の 3 か所で確かめられます (2026 年 9 月時点・出典: Log Management Billing)。実測が無い段階では「1 イベント = 1 KB、1 GB = 100 万 KB」のように仮定を明示して置きます。この仮定では 1 日 10 GB は 1 日 1,000 万イベント、月 3 億イベント (100 万イベント単位で 300) になります。この件数に各層の単価を掛けるのが見積もりの骨組みで、仮定を変えれば結果もそのまま動くことを忘れないでください。
リハイドレートは 2 回払う - スキャンと再インデックス
アーカイブからログを戻す操作がリハイドレートで、費用は 2 段で発生します。1 段目はスキャンした圧縮 GB あたりの料金で、取り込み (Ingest) と同じ単価が適用されます (2026 年 8 月時点の料金ページ・契約形態による差なし)。2 段目は戻したイベントの索引分で、選んだ保持期間の契約インデックス単価が別途掛かります (出典: Datadog Pricing)。絞り込みはファイル取得後に適用されるため、スキャン量は「その期間のアーカイブ全量」で決まり、service:A で絞っても他サービスのログも読まれます (2026 年 9 月時点・出典: Rehydrating from Archives)。スキャン費を抑えるには期間を狭めるのが最も効きます。1 回の historical view で戻せるのは最大 10 億イベントで、管理者は件数上限と保持期間の選択肢を設定できます。索引の除外フィルターは適用されないため、当時落としたログも戻せます。
自分の構成ではどう決まるか - 層の選び方の判断表
月額を式にすると「取り込み GB × Ingest 単価 + 索引 100 万件 × 保持日数別の Index 単価 + Flex 保存 100 万件 × Flex 単価」です。Flex の保存量は保持期間分が積み上がった定常状態で数え、検索計算 (Flex Compute) は別に足します。式の各項に何が入るかは、ログをどの層に置くかで決まり、その置き場は「何日分まで遡って検索するか」と「どれくらいの頻度で検索するか」の 2 軸でほぼ決まります。
| 遡る日数 | 検索頻度 | 向く層 | 費用を動かす変数 |
|---|---|---|---|
| 30 日以内 | 頻繁 (日常の調査) | Standard Indexing。保持は 3 / 7 / 15 / 30 日から実際に遡る日数で選ぶ | 索引率 (取り込んだうち索引する割合) と保持日数 |
| 30 日以内 | まれ (障害時だけ) | 索引率を絞り、残りは取り込みのみ + アーカイブ | 取り込み GB。索引費用は絞った分だけ比例して減る |
| 30 日超 | ときどき急いで検索する | Flex Logs (累計件数が小さければ Starter、大きければ XS 以上) | 定常状態の保存件数と Flex Compute の段 |
| 30 日超 | ほとんど検索しない | アーカイブ (必要時にリハイドレート) | 戻す頻度 × スキャン GB + 再索引の件数 |
読み取れることは 3 つあります。第一に、全件を Standard に索引する構成では索引の項が請求の主役になり、取り込みは脇役です。第二に、索引率を 3 割にすれば索引の項はそのまま 3 割になるので、日常の調査で使わないログを索引から外す判断は、保持日数を短くする判断よりも大きく効きます。第三に、監査ログのように 12 ヶ月残す要件は、Standard の 30 日超が価格非公表である以上、最初から Flex Logs (Starter か XS 以上) の問いとして立てるのが正しい順序です。自分の構成の答えは、上の式に実測の GB と件数、公式料金ページの単価を入れれば出ます。
保持日数を延ばす前に層を変える
「30 日では足りないから 60 日に」と延ばす前に、判断の順序を決めておくと費用が読みやすくなります。まず、索引に入れる量を減らせないかを見ます。索引率は費用に比例して効き (10 割から 3 割へ下げれば索引の費用はそのまま 3 割)、保持日数の延長は料金ページに並ぶ単価の段差の分だけ効きます。どちらが大きいかは、その段差と自分の索引率で決まります。次に、Standard の保持は 3 / 7 / 15 / 30 日の中で「調査で実際に遡る日数」に合わせ、30 日を超える要件は Standard の延長 (価格非公表) ではなく Flex かアーカイブへ層を変えます。最後に、Flex とアーカイブの分岐は検索頻度で決めます。週次で戻すならリハイドレートのスキャン費と再索引費が繰り返し掛かるので Flex、年に数回ならアーカイブが向きます。保持期間の既定値、使用量の確認 (料金の確認方法)、SKU 全体の読み方 (料金体系の読み解き方)、届いた直後のログを流し見する Live Tail は各項に委ねます。