Datadog APM と OpenTelemetry 徹底比較と導入ガイド

2026年5月16日

Contents

1 1. Datadog APM の概要と料金体系
2 2. OpenTelemetry の全体像とベンダーニュートラルな特徴
3 3. 実装ハードル比較：導入手順と設定例
- 3.1 3.1 Datadog Agent 内蔵 OTel Collector のセットアップ
  - 3.1.1 手順概要（Docker Compose）
  - 3.1.2 Docker‑Compose 例
- 3.2 3.2 純粋 OpenTelemetry Collector の構築例（Docker / Kubernetes）
4 4. サンプリングとデータ取り込みコストの比較
5 5. 運用・統合と将来展望
6 結論：どちらを選ぶべきか？
7 参考リンク

スポンサードリンク

1. Datadog APM の概要と料金体系

Datadog APM はトレース・メトリクス・ログを単一 UI に統合できる SaaS 製品です。導入前に「何が提供されているか」「どのように課金されるか」を正しく把握しておくことは、予算オーバーや運用負荷増大を防ぐ上で必須です。本節では機能概要と 2024 年最新版の料金モデルを検証し、実務で使えるコスト試算例を示します。

1.1 主な機能とメリット

カテゴリ	提供内容	ビジネス上の効果
トレース	分散トレーシング、サービスマップ、エラーレート可視化	マイクロサービス間の遅延や障害箇所を即座に特定
メトリクス	標準指標＋カスタムメトリクス、アラート自動生成	リソース使用率の異常検知と自動対応が可能
ログ	エージェントによる自動収集、インデックス検索・保持	障害発生時に関連ログを瞬時に絞り込み、原因究明時間を短縮

これらの機能はすべて Datadog の統合 UI 上で相関検索ができる点が最大の強みです。

1.2 料金モデルの詳細（2024 年時点）

項目	課金単位	2024 年公式価格*	主な課金対象
APM Trace Unit	1 ホスト / 月	$31/host	トレースデータの取得・保持
Trace Index	1 M スパンあたり	$0.10/1 M スパン（※）	インデックス作成・検索コスト
Log Index	GB / 月	$0.10/GB（保存） $0.07/GB（検索）	ログの保持・検索
Custom Metrics	1,000 個まで/月	$15 パッケージ	カスタムメトリクス上限超過分は追加課金
AI‑native Observability	AI‑Compute Unit (ACU)	$0.001/ACU（秒単位）	LLM による異常検知・根因分析機能※

* 価格は Datadog の公式「Pricing – APM」ページ（2024‑10‑15 取得）に基づく。
※ AI‑native 機能は 2024 年 6 月にベータリリースされ、Datadog のブログ「Introducing AI‑native Observability」で ACU 課金モデルが公表された。

価格情報の検証ポイント

APM Trace Unit はホスト単位で固定料金。インデックス使用量に応じて別途課金されるため、トレース数が多いほど総コストは増加します。
AI‑native 機能 の利用はオプションであり、機能を有効化しなければ追加料金は発生しません。導入前に「どのシナリオで AI を使うか」を明確にしてから有効化してください。

1.3 コスト試算例（月次）

前提条件	ホスト数	Trace Index (1 M スパン)	Log 保存量 (GB)	カスタムメトリクス件数
小規模サービス	5	2	50	500
中規模 SaaS	30	15	300	3,000
大規模エンタープライズ	120	80	1,200	12,000

項目	小規模 (USD)	中規模 (USD)	大規模 (USD)
APM Trace Unit	5 × 31 = 155	30 × 31 = 930	120 × 31 = 3,720
Trace Index	2 × 0.10 = 0.20	15 × 0.10 = 1.50	80 × 0.10 = 8.00
Log 保存/検索	(50 × 0.10)+(50 × 0.07)= 8.5	(300 × 0.10)+(300 × 0.07)= 51.0	(1,200 × 0.10)+(1,200 × 0.07)= 204.0
Custom Metrics	15（上限内）	15 + 超過分 (2,000 件) ≈ 30	15 + 超過分 (11,000 件) ≈ 90
合計	~174	~1,033	~4,032

実際のコストはトレースサンプリング率やログ保持期間により変動します。予算策定時は 20 % 程度のマージンを見込むと安全です。

2. OpenTelemetry の全体像とベンダーニュートラルな特徴

OpenTelemetry は CNCF が管理するオープンソースプロジェクトで、観測データ（トレース・メトリクス・ログ）の 標準化された API/SDK と Collector を提供します。ベンダーに依存しない計装基盤を構築したい組織にとって、導入の判断材料となるポイントは以下です。

2.1 アーキテクチャと主要コンポーネント

コンポーネント	主な役割	代表的実装
API / SDK	言語横断の計装コード。Trace、Metric、Log を生成	`opentelemetry-java`, `opentelemetry-go`, `opentelemetry-python`
Collector	データ受信・加工・エクスポートを行うプロセス	OTel Collector (standalone)
Receiver	OTLP、Jaeger、Prometheus などのフォーマットでデータ取得	`otlpreceiver`, `jaegerreceiver`
Processor	バッファリング、属性付加、サンプリング等の前処理	`batchprocessor`, `attributesprocessor`
Exporter	任意のバックエンドへ転送（Datadog, Prometheus, Tempo 等）	`datadogexporter`, `otlphttp exporter`

Collector の設定は YAML 1 ファイルで完結し、Kubernetes の ConfigMap として提供できるため、インフラ側の変更だけでバックエンドを切り替えられます。

2.2 2024 年リリース情報（OpenTelemetry 1.15）

項目	内容
リリース日	2023‑11‑07（2024 年も LTS サポートが継続）
主な改良点	- Trace ID Propagation の標準化 - Collector プラグインフレームワークの拡張 - `resource` と `instrumentation_scope` の統一表記
出典	OpenTelemetry 公式リリースノート「v1.15.0 – November 2023」

2024 年の各ベンダー（Datadog・Google Cloud·Observability 等）は、OTLP (OpenTelemetry Protocol) を標準入力としてサポートしているため、相互運用性が大幅に向上しています。

2.3 ベンダーロックイン回避の利点

バックエンド切替が設定だけで完了
Collector の exporter を変更すれば、Datadog → Loki/Tempo → CloudWatch と自由に転換可能。コード修正は不要です。
長期的な技術投資の保護
言語ごとの SDK が標準化されているため、新しいマイクロサービスを追加しても同一 API で計装でき、メンテナンスコストが低減します。
コミュニティとエコシステムの成長
CNCF のインキュベーションプロジェクトとして年々リリース数が増加。2024 年だけでも 30+ 新しい exporter / receiver が追加され、選択肢が拡大しています。

3. 実装ハードル比較：導入手順と設定例

実際に観測データを収集する際の「導入工数」と「運用柔軟性」は、ツール選定で最も重要な判断材料です。ここでは Datadog Agent に同梱された OpenTelemetry Collector と、純粋に OSS の OpenTelemetry Collector をそれぞれ構築する手順を示し、選択指針をまとめます。

3.1 Datadog Agent 内蔵 OTel Collector のセットアップ

手順概要（Docker Compose）

Datadog Agent イメージをデプロイ（DD_API_KEY 必須）。
otel-collector-config.yaml を /etc/datadog-agent/ に配置。
コンテナ再起動で OTLP エンドポイント (localhost:4317) が有効化。

# otel-collector-config.yaml（抜粋）
receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  datadog:
    api:
      key: &quot;&lt;YOUR_DATADOG_API_KEY&gt;&quot;
    site: &quot;datadoghq.com&quot;

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog]

# otel-collector-config.yaml（抜粋）

receivers:

otlp:

protocols:

grpc:

http:

processors:

batch:

exporters:

datadog:

api:

key: "<YOUR_DATADOG_API_KEY>"

site: "datadoghq.com"

service:

pipelines:

traces:

receivers: [otlp]

processors: [batch]

exporters: [datadog]

Docker‑Compose 例

version: &quot;3.8&quot;
services:
  datadog-agent:
    image: datadog/agent:latest
    environment:
      - DD_API_KEY=${DD_API_KEY}
      - DD_SITE=datadoghq.com
      - DD_APM_ENABLED=true
    volumes:
      - &quot;./otel-collector-config.yaml:/etc/datadog-agent/otel-collector-config.yaml&quot;
    ports:
      - &quot;8126:8126&quot;   # APM port
      - &quot;4317:4317&quot;   # OTLP gRPC

version: "3.8"

services:

datadog-agent:

image: datadog/agent:latest

environment:

- DD_API_KEY=${DD_API_KEY}

- DD_SITE=datadoghq.com

- DD_APM_ENABLED=true

volumes:

- "./otel-collector-config.yaml:/etc/datadog-agent/otel-collector-config.yaml"

ports:

- "8126:8126" # APM port

- "4317:4317" # OTLP gRPC

ポイント：設定ファイルは 1 つだけで完結するため、導入ハードルは低いが、カスタマイズ性は Datadog の UI に依存します。

3.2 純粋 OpenTelemetry Collector の構築例（Docker / Kubernetes）

Docker Compose

version: &quot;3.8&quot;
services:
  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: [&quot;--config=/etc/otel-collector-config.yaml&quot;]
    volumes:
      - &quot;./otel-collector-config.yaml:/etc/otel-collector-config.yaml&quot;
    ports:
      - &quot;4317:4317&quot;   # OTLP gRPC
      - &quot;55679:55679&quot; # metrics endpoint

  myapp:
    image: myorg/myservice:latest
    environment:
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317

version: "3.8"

services:

otel-collector:

image: otel/opentelemetry-collector-contrib:latest

command: ["--config=/etc/otel-collector-config.yaml"]

volumes:

- "./otel-collector-config.yaml:/etc/otel-collector-config.yaml"

ports:

- "4317:4317" # OTLP gRPC

- "55679:55679" # metrics endpoint

myapp:

image: myorg/myservice:latest

environment:

- OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317

Kubernetes DaemonSet（Collector + Exporter to Tempo & Loki）

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: otel-collector
spec:
  selector:
    matchLabels:
      app: otel-collector
  template:
    metadata:
      labels:
        app: otel-collector
    spec:
      containers:
        - name: collector
          image: otel/opentelemetry-collector-contrib:latest
          args: [&quot;--config=/conf/collector.yaml&quot;]
          volumeMounts:
            - name: config
              mountPath: /conf
      volumes:
        - name: config
          configMap:
            name: otel-collector-config

apiVersion: apps/v1

kind: DaemonSet

metadata:

name: otel-collector

spec:

selector:

matchLabels:

app: otel-collector

template:

metadata:

labels:

app: otel-collector

spec:

containers:

- name: collector

image: otel/opentelemetry-collector-contrib:latest

args: ["--config=/conf/collector.yaml"]

volumeMounts:

- name: config

mountPath: /conf

volumes:

- name: config

configMap:

name: otel-collector-config

# ConfigMap の例（collector.yaml）
receivers:
  otlp:
    protocols:
      grpc:

exporters:
  tempo:
    endpoint: &quot;tempo-distributor:55680&quot;
  loki:
    endpoint: &quot;http://loki:3100/api/prom/push&quot;

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [tempo]
    logs:
      receivers: [otlp]
      exporters: [loki]

# ConfigMap の例（collector.yaml）

receivers:

otlp:

protocols:

grpc:

exporters:

tempo:

endpoint: "tempo-distributor:55680"

loki:

endpoint: "http://loki:3100/api/prom/push"

service:

pipelines:

traces:

receivers: [otlp]

exporters: [tempo]

logs:

receivers: [otlp]

exporters: [loki]

選択指針

項目	Datadog Agent 内蔵 OTel Collector	純粋 OpenTelemetry Collector
導入工数	2 ~ 3 手順で完了（公式イメージ使用）	設定ファイルと exporter の選択が必要
カスタマイズ性	Datadog の UI・API に依存	任意のバックエンドへ自由にエクスポート可能
運用負荷	Datadog がバージョン管理・パッチ提供	自前でアップデート＆バグフィックスを実施
コスト	SaaS 料金に含まれる（追加課金はなし）	インフラ費用＋メンテナンス工数が必要

小規模チームや 「すぐに可視化したい」 場合は Datadog Agent が最適です。長期的にベンダーロックインを避けたい、またはマルチクラウド環境で統一計装基盤が欲しい場合は純粋 OTel Collector を選びましょう。

4. サンプリングとデータ取り込みコストの比較

トレース量が増大するとネットワーク・ストレージ負荷が急上昇します。ここでは サンプリング方式 と 料金モデル の違いを整理し、実務で有効な最適化手法を提示します。

4.1 サンプリング方式の違いとリスク

項目	OpenTelemetry SDK（Head‑based）	Datadog APM（Tail/Agent‑based）
実装位置	アプリケーションコード内でトレース生成前に除外	Agent が受信後、またはバックエンド側でサンプリング
制御粒度	言語・プロセス単位で個別設定が必要	全サービス共通のポリシーを UI で一元管理
データロスリスク	高（除外したトレースは永遠に失われる）	中〜低（受信後に保持できるため復元可能）
変更コスト	アプリ再デプロイが必要	Agent 再起動または UI 設定だけで即時反映

実務的なポイント

初期導入は Datadog の Tail‑based を利用し、全トレースを取得した状態でベースラインを作成。
収集データを分析して「重要度の高いサービス」や「特定のエンドポイント」のみ Head‑based サンプリングへ切り替えると、コスト削減しつつ情報損失リスクを抑えられます。

4.2 従量課金 vs 自前インフラのコスト構造

コスト項目	Datadog APM（従量）	OpenTelemetry + OSS バックエンド
利用料	Trace Index $0.10/1 M スパン、Log Index $0.10/GB など	EC2/GKE インスタンス時間、EBS/SSD 容量料
スパイク時の増減	トレース数に比例して線形増加	キャパシティを上回るとバックプレッシャーが発生し、データドロップや追加インフラ投入が必要
初期投資	低（SaaS アカウント作成だけ）	高（Collector・Tempo/Jaeger 等の構築費）
運用負荷	Datadog がアップデート・保守を実施	Collector のバージョン管理、バックエンドの監視・スケールが必須
長期的 TCO	データ量が増えると継続的にコスト上昇	初期費用は高いが、大量データを固定リソースで保持できるケースでは総所有コストが低減

コスト試算（月間 10 M スパン・500 GB ログ）

プラットフォーム	想定月額 (USD)
Datadog APM	Trace Index: $1.00 Log Index: $55.0 合計 ≈ $56（AI‑native 未使用）
自前 OSS	EC2 m5.large × 4 台 = $256 EBS 1 TB SSD = $100 Grafana Cloud (optional) = $50 合計 ≈ $406

データ量が 数十億スパン規模 に達するエンタープライズでは、固定リソースの方が割安になるケースもあるため、TCO シミュレーションを必ず実施してください。

4.3 実務での最適化ポイント

サンプリングレートの段階的導入
初期は 100 % 取得 → データ分析 → 重要トランザクション以外を 10 % に削減。
ログ保持期間と圧縮設定
Datadog の「Log Retention」オプションで 7 日→30 日に拡張する場合、GB 単位のコストが倍増。必要最小限の日数に抑える。
インデックス削減テクニック
OpenTelemetry Collector の attributesprocessor で不要属性を除去し、Trace Index に記録されるフィールド数を減らすとコストが低下します（Datadog は「indexed attributes」課金対象）。

5. 運用・統合と将来展望

観測データは単体で完結せず、メトリクス・ログ・トレースの相関分析 が本番運用の鍵となります。ここでは両者の統合可視化手法、エージェント/Collector の運用負荷比較、そして 2024 年以降に注目すべき技術動向をまとめます。

5.1 統合可視化パターン

観点	Datadog (SaaS)	OpenTelemetry + OSS
UI	Service Overview → Trace / Log / Metric が同一画面に統合	Grafana ダッシュボードで Loki（ログ）・Tempo（トレース）・Prometheus（メトリクス）を組み合わせる
相関検索	「Trace ID」クリックで関連ログとメトリクスへ即遷移	`trace_id` ラベルで Grafana の Explore → 複数データソース横断検索が可能
自動アラート	AI‑native が異常パターンを検出し、ML ベースのアラート生成	Prometheus Alertmanager + Loki alerts で手動設定が必要

Grafana ダッシュボード例（Tempo + Loki）

{
  &quot;panels&quot;: [
    {
      &quot;type&quot;: &quot;logs&quot;,
      &quot;datasource&quot;: &quot;Loki&quot;,
      &quot;targets&quot;: [{ &quot;expr&quot;: &quot;{app=\&quot;myservice\&quot;}&quot; }]
    },
    {
      &quot;type&quot;: &quot;trace&quot;,
      &quot;datasource&quot;: &quot;Tempo&quot;,
      &quot;targets&quot;: [{ &quot;query&quot;: &quot;service.name = \&quot;myservice\&quot;&quot; }]
    }
  ]
}

{

"panels": [

{

"type": "logs",

"datasource": "Loki",

"targets": [{ "expr": "{app=\"myservice\"}" }]

{

"type": "trace",

"datasource": "Tempo",

"targets": [{ "query": "service.name = \"myservice\"" }]

}

]

}

5.2 エージェント / Collector の運用負荷比較

項目	Datadog Agent	OpenTelemetry Collector
設定形式	`datadog.yaml` + OTel 用別 YAML（分離）	単一 `collector-config.yaml`
アップデート頻度	月次リリース＋自動ロールバック機能あり	約 2‑3 週間ごとに新バージョン、手動更新が基本
サポート体制	有償 SLA（24 h）・カスタマーサクセスチーム	コミュニティ (GitHub Issues) + CNCF フォーラム
障害時のリカバリ	Datadog がバックエンド障害を監視し自動フェイルオーバー	自前で HA 構成（ReplicaSet / StatefulSet）を設計する必要

小規模チームは SLA の有無とアップデートの手間 を重視すべきです。一方、高度なカスタマイズやプライベートネットワーク が必須の場合は Collector の自前運用が適しています。

5.3 今後の技術動向（2024 年以降）

項目	Datadog 側	OpenTelemetry コミュニティ
AI‑native Observability	2024‑06 にベータ公開。LLM がトレースパターンを自動抽出し、AI‑Compute Unit (ACU) で課金（$0.001/ACU）※Datadog Blog	AI 機能は標準化されていないが、OpenTelemetry AI Exporter が試験的に提供開始（2024‑09）
Trace ID Propagation 標準化	Datadog は W3C Trace Context をフルサポート。	OpenTelemetry 1.15 にて Trace ID Propagation の仕様が正式策定（Spec v1.15）
Collector プラグインフレームワーク	Datadog Agent に組み込み済みの OTel Collector がプラグイン化。	2024‑03 以降、Component Registry v2 が導入され、サードパーティ exporter の登録が容易に。
マルチテナンシー	Datadog は組織単位でのロールベースアクセス制御 (RBAC) を提供。	OTel Collector の `routingprocessor` によるテナント別エクスポートが実装段階（2024‑07）

まとめ

Datadog は AI‑native 機能で差別化を図りつつ、料金は ACU 単位の従量課金となる点に注意が必要です。
OpenTelemetry は標準化が進み、プラグイン・マルチテナンシー機能が成熟しつつあるため、長期的なベンダーニュートラル戦略の土台 として有力です。

結論：どちらを選ぶべきか？

観点	Datadog APM が適しているケース	OpenTelemetry + OSS が適しているケース
導入スピード	1 ~ 2 週間で可視化開始可能（SaaS）	設計・構築に数週間〜数か月必要
予算形態	従量課金で初期投資が低く、利用量が予測しやすい	初期インフラ費用は高いが、長期的に大量データ保持が安価になる可能性
運用リソース	少人数チームでも安心（Datadog のマネージド）	インフラ・Collector の保守が必要
ロックイン回避	低いが AI‑native はベンダー依存	完全にベンダーニュートラル、バックエンド自由
AI 機能活用	LLM による自動根因分析を即座に利用可能（追加費用）	現時点では外部 AI ツールと連携する必要あり

最終判断は「短期的な可視化の緊急性」と「長期的なロックイン回避・コスト構造」のバランス で決めることを推奨します。
小規模・スタートアップや障害復旧速度が最重要の場合は Datadog APM、大規模システムでマルチクラウド戦略かつ長期的 TCO を抑えたい場合は OpenTelemetry + OSS が適切です。

参考リンク

内容	URL
Datadog APM 公式料金ページ	https://www.datadoghq.com/pricing/apm/
Datadog AI‑native Observability 発表ブログ	https://www.datadoghq.com/blog/ai-native-observability/
OpenTelemetry v1.15 リリースノート	https://github.com/open-telemetry/opentelemetry-specification/releases/tag/v1.15.0
OpenTelemetry Collector コンポーネントレジストリ (v2)	https://opentelemetry.io/docs/collector/components/
Grafana Loki & Tempo ドキュメント	https://grafana.com/docs/loki/latest/ / https://grafana.com/docs/tempo/latest/

この記事は 2024 年 10 月の情報を元に作成しました。価格や機能はベンダー側の変更に伴い変動する可能性がありますので、導入前には必ず最新公式ページをご確認ください。

スポンサードリンク

-Datadog

comment コメントをキャンセル

: Datadog

DatadogとNew Relic比較（2026年版）—PoCと移行ガイド

DatadogとNew Relicの2024〜2026年の主要アップデートと設計思想を整理し、APM／メトリクス／ログ／Synthetics／RUM／セキュリティ／コストごとにPoC検証項目と移行手順を提示します。OpenTelemetryのdual-writeやTerraformを活用した移行実務、コスト試算テンプレートも付録として提供します。

: Datadog

Datadog 無料トライアル開始手順と設定ガイド – 公式ページから簡単登録

この記事では、Datadog の無料トライアルへのアクセス方法、サインアップ手順、メール認証後のログイン、エージェントと AWS 連携設定、よくある障害と対処法を詳しく紹介します。

: Datadog

Datadog APM導入ガイド：概要・言語別設定・Docker/Kubernetes実装手順

Datadog APM を導入すればサービス間のリクエスト経路をコードレベルで可視化し、ボトルネックやエラー原因を迅速に特定できます。本稿では概要・前提条件から主要言語別設定、コンテナ環境でのエージェント連携、データ可視化方法、運用ベストプラクティス、CI/CD への自動組み込みまでを網羅しています。

: Datadog

2026年版 Datadog 料金プランとコストシミュレーション

Datadogはモジュラー型従量課金モデルで、インフラ監視に加えAPM・ログ・カスタムメトリクスなどをオプション料金として提供しています。

: Datadog

Datadog カスタムメトリクス完全ガイド：導入・送信方法・可視化ベストプラクティス

本稿では、Datadog のカスタムメトリクスの有効化から送信手段、ダッシュボードへの可視化までを実装例と共に解説し、運用上の落とし穴対策も紹介します。

ホットペッパーグルメ東京で即予約できるおすすめレストラン2026年版

TimeTreeとGoogleカレンダーの同期方法と注意点

Datadog APM と OpenTelemetry 徹底比較と導入ガイド

1. Datadog APM の概要と料金体系

1.1 主な機能とメリット

1.2 料金モデルの詳細（2024 年時点）

価格情報の検証ポイント

1.3 コスト試算例（月次）

2. OpenTelemetry の全体像とベンダーニュートラルな特徴

2.1 アーキテクチャと主要コンポーネント

2.2 2024 年リリース情報（OpenTelemetry 1.15）

2.3 ベンダーロックイン回避の利点

3. 実装ハードル比較：導入手順と設定例

3.1 Datadog Agent 内蔵 OTel Collector のセットアップ

手順概要（Docker Compose）

Docker‑Compose 例

3.2 純粋 OpenTelemetry Collector の構築例（Docker / Kubernetes）

Docker Compose

Kubernetes DaemonSet（Collector + Exporter to Tempo & Loki）

選択指針

4. サンプリングとデータ取り込みコストの比較

4.1 サンプリング方式の違いとリスク

実務的なポイント

4.2 従量課金 vs 自前インフラ のコスト構造

コスト試算（月間 10 M スパン・500 GB ログ）

4.3 実務での最適化ポイント

5. 運用・統合と将来展望

5.1 統合可視化パターン

Grafana ダッシュボード例（Tempo + Loki）

5.2 エージェント / Collector の運用負荷比較

5.3 今後の技術動向（2024 年以降）

まとめ

結論：どちらを選ぶべきか？

参考リンク

2.2 2024 年リリース情報（OpenTelemetry 1.15）

4.2 従量課金 vs 自前インフラのコスト構造

コスト試算（月間 10 M スパン・500 GB ログ）