APM cost optimization: host-based vs usage-based pricing
Application performance monitoring (Datadog, New Relic, and others) prices by hosts, ingested data, or usage, and it is a notoriously large observability bill. Host right-sizing, data filtering, and sampling cut it. Here is how.
Quick answer
APM platforms (Datadog, New Relic, and others) price by monitored hosts, ingested data (logs, traces, metrics, custom metrics), and per-feature usage, and APM is often one of the largest observability bills. The levers: monitor the hosts that matter and right-size the fleet (per-host pricing punishes sprawl), filter and sample logs and traces before ingestion, control high-cardinality custom metrics (a top hidden cost), and set retention. Ingest what you will act on, and do not let host count and custom-metric cardinality sprawl.
Application performance monitoring gives deep visibility into application behavior, traces, metrics, logs, service maps, and it is powerful but notoriously expensive. Pricing combines per-host charges with data-ingestion and usage-based components, so host sprawl, heavy ingestion, and high-cardinality custom metrics all drive a bill that often surprises teams.
Where APM cost comes from
| Component | Cost driver |
|---|---|
| Hosts | Per monitored host (fleet size) |
| Ingested data | Logs, traces, metrics volume |
| Custom metrics | High cardinality (a top hidden cost) |
| Retention + features | How long, and which features |
Per-host pricing means a large or auto-scaling fleet multiplies cost (every host counts, including short-lived ones). Ingested logs and traces bill by volume. Custom metrics, especially high-cardinality ones (metrics with many unique label combinations), are a notorious hidden cost that can explode the bill. Retention and premium features add more.
Host sprawl and cardinality are the traps
The two biggest surprises are host sprawl (per-host pricing on a large or elastic fleet, including short-lived containers each counting) and high-cardinality custom metrics (a metric tagged with unbounded values like user ID or request ID generates a huge number of time series, each billed). Controlling both, right-sizing the fleet and bounding metric cardinality, prevents the worst overspend, the same cardinality warning as infrastructure monitoring.
Filter and sample data
Filter and sample logs and traces before ingestion, you do not need every log line or every trace, especially for high-volume healthy requests. Trace sampling (keeping a representative fraction plus all errors and slow requests) cuts trace ingestion dramatically while preserving the signal. Route low-value logs to cheaper storage, the log management discipline.
Controlling APM cost
Monitor the hosts that matter and right-size the fleet (per-host pricing punishes sprawl), bound custom metric cardinality (avoid unbounded labels, the top hidden cost), filter and sample logs and traces before ingestion, set retention to what you query, and use the right pricing tier for each workload. Because APM combines per-host and per-ingestion cost, controlling fleet size, cardinality, and ingested volume are the big levers on what is often the largest observability bill.
FAQ
What drives APM cost?
Per-host charges (fleet size, with every monitored host counting including short-lived ones), ingested data (logs, traces, metrics volume), custom metrics (especially high-cardinality ones, a top hidden cost), and retention plus premium features. APM combines per-host and per-ingestion pricing, so host sprawl, heavy ingestion, and metric cardinality all drive what is often the largest observability bill.
How do I reduce APM cost?
Monitor the hosts that matter and right-size the fleet (per-host pricing punishes sprawl), bound custom metric cardinality (avoid unbounded labels), filter and sample logs and traces before ingestion, set retention to what you query, and use the right pricing tier per workload. Controlling fleet size, cardinality, and ingested volume are the big levers.
Why are high-cardinality custom metrics expensive in APM?
Because a custom metric tagged with high-cardinality labels (unbounded values like user ID, request ID, or session ID) generates a separate time series for every unique label combination, and each time series is billed. So one metric with an unbounded label can explode into a huge number of billed time series, a notorious hidden APM cost. Bounding label cardinality prevents this.
Does host sprawl drive APM cost?
Yes, significantly, since APM often prices per monitored host. A large or auto-scaling fleet multiplies cost because every host counts, including short-lived containers that each register as a host. Right-sizing the fleet, monitoring the hosts that matter, and being aware that elastic scaling multiplies per-host charges control this major cost driver.
Should I sample traces in APM?
For high-volume traffic, yes. You do not need every trace, especially for high-volume healthy requests. Trace sampling keeps a representative fraction plus all errors and slow requests, cutting trace ingestion dramatically while preserving the signal you need to diagnose issues. Full trace capture on high-traffic services is a common source of avoidable APM ingestion cost.
Does C3X estimate APM cost?
APM cost is per-host and data-ingestion based rather than infrastructure C3X provisions, so C3X prices the underlying compute fleet (which influences host count) from your Terraform, and you model ingestion volume and custom-metric cardinality to estimate the APM charges. Right-sizing the fleet C3X prices helps control the per-host component.
What to do next
Price the fleet your APM monitors before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.