# Cloud Cost Management for Observability: A Practical Guide

> Observability spend is outgrowing infrastructure budgets. What drives the cost up, how pricing models work, and a practical framework to manage it.

Source: https://last9.io/blog/cloud-cost-management-for-observability/

Observability costs grow faster than the infrastructure they're supposed to watch. Most teams don't notice until a monthly bill jumps by a number nobody can immediately explain.

In [a 2026 survey of 500 U.S. observability, SRE, and platform engineering professionals](https://www.businesswire.com/news/home/20260526456726/en/New-groundcover-Survey-Finds-AI-Workloads-Now-Consume-up-to-Half-of-Observability-Spend), conducted by Atomik Research on behalf of the observability vendor groundcover, 53% reported budget overages of 10% or more in the last fiscal year, and 42% put that overage in the 10-30% range.

The pattern is consistent. Teams instrument more, ship more data to their backend, and only find out the pricing model punished them for it after the invoice arrives.

Managing observability cost rarely means collecting less data. It means understanding which specific choices drive the bill — cardinality, retention, log verbosity, sampling strategy — and building a practice that catches cost growth before it becomes an emergency instead of after.

## What is observability cost management?

Observability cost management is the practice of controlling what telemetry a system produces, keeps, and queries, so the bill tracks the value the data delivers rather than the volume the system emits. It works on four levers: cardinality, log verbosity, retention, and the pricing model you are billed against.

Unlike general cloud cost management, which targets compute and storage for the workload itself, it targets the monitoring data about that workload, which often grows faster than the workload does.

## What drives observability costs up?

Four things push an observability bill up faster than the infrastructure it's monitoring, and they compound with each other rather than acting independently.

**Data volume grows nonlinearly with system complexity.** A monolith emits a relatively fixed set of metrics and logs. Break it into 40 microservices, add a service mesh, and instrument every hop with traces, and the same business logic emits an order of magnitude more telemetry.

Nothing got more complex functionally. There are simply more processes, more network calls, and more places to attach a label.

**Cardinality multiplies cost silently.** A metric with a handful of labels can look cheap right up until a `customer_id` or `request_id` label gets attached to it, at which point a 100-series metric can become millions of series. This is less "cost creeping up" and more "cost exploding at a single deploy", because cardinality growth is often not linear but combinatorial.

We've written a full breakdown of how this specific mechanism works in [our guide to high cardinality](https://last9.io/guides/high-cardinality/what-is-high-cardinality/), since it deserves its own deep dive rather than a summary here.

**Log verbosity is the quietest cost driver.** Logs are usually priced per GB ingested or per GB indexed, and most teams don't audit log levels in production the way they audit metric cardinality. `DEBUG`-level logging left on in a high-traffic service, or a single noisy dependency logging every retry attempt, can dwarf every other cost driver on the bill.

Nobody treats it as a cardinality-style incident, because it doesn't break anything; it only costs money.

**Retention and duplication add up over time.** Keeping every signal at full resolution and full retention regardless of how often it is queried is the single most common reason observability bills grow steadily rather than spiking. Three examples: traces sampled at 100% for a service nobody debugs, metrics retained at one-second resolution for a dashboard nobody opens daily, and staging logs retained on the production policy.

None of these shows up as a single alarming line item. Together they show up as a bill that is 30% higher than it needs to be, with no single cause to point at.

## How do observability pricing models work?

Pricing structure matters as much as data volume, because the same underlying telemetry can cost wildly different amounts depending on what unit the vendor bills against.

Most vendors bill on some combination of four things: a flat fee per monitored host, a fee per unique metric and label combination beyond a quota, a fee per GB ingested or indexed, and a per-seat fee layered on top.

Datadog's public pricing shows how these stack. Each row below is a separate meter, so a service with high cardinality, verbose logging, and full trace retention gets charged on several of them at once.

| Meter                     | Billed against                          | Datadog published rate                        | What makes it grow                        |
| ------------------------- | --------------------------------------- | --------------------------------------------- | ----------------------------------------- |
| Infrastructure monitoring | Per host                                | $15 / host / month (annual)                   | Host and container count                  |
| APM                       | Per host                                | $31 / host / month                            | Number of traced services                 |
| Custom metrics            | Per unique metric and label combination | ~$1 per 100 / month beyond 100 per host (Pro) | Cardinality: new labels, new label values |
| Log management            | Per GB indexed and per event ingested   | $0.10 / GB indexed + $1.27 per million events | Log verbosity and traffic                 |
| Seats                     | Per user                                | Varies by plan                                | Team size                                 |

**Bottom line**: the meters move independently, so the first lever worth pulling is the one attached to the meter you are billed most on. We've broken down the full mechanics, including where the quotas sit and where costs typically surprise people, in [our Datadog pricing guide](https://last9.io/blog/datadog-pricing-all-your-questions-answered/).

A pricing model rewards whatever behavior it doesn't charge for, and punishes whatever it does. Per-metric or per-GB pricing works fine as long as you know which meter you're on.

A team on per-custom-metric pricing has a direct financial incentive to control cardinality. A team on per-GB log pricing has a direct incentive to control log verbosity and retention. Knowing which meter you're actually being billed against changes which lever is worth pulling first.

## What's a practical framework for managing observability costs?

Cost management works best as an ongoing practice with specific checkpoints, not a one-time cleanup after a bad invoice.

**Set a budget per signal type, not just a total.** A single "observability budget" line item makes it hard to tell whether a cost increase came from more traces, more log volume, or more metric series. Splitting the budget by metrics, logs, and traces, and by team or service where possible, makes it obvious which part of the system is driving a change.

**Shape data before it hits storage, not after.** Filtering, aggregating, and dropping low-value telemetry at ingestion is cheaper and more effective than trying to clean up already-stored data. This is the same principle behind telemetry pipeline tools: the earlier in the pipeline a decision gets made about what to keep, the less you pay to store and query the data you were never going to use anyway.

**Match retention to actual query patterns, not to a default setting.** Most observability platforms ship with a default retention window that's the same for every signal and every service. Auditing what gets queried, and for how long after an incident, usually reveals that a meaningful chunk of stored data has never been queried past the first week.

Tiering retention (full resolution for a short window, downsampled or aggregated for longer-term trend analysis) cuts storage cost without cutting the data that gets used during an incident.

**Build cardinality and log-volume budgets per service, enforced before deploy where possible.** Catching a cardinality spike or a logging regression in code review or CI is dramatically cheaper than catching it in a monthly bill. Our guide on [cardinality cost optimization](https://last9.io/guides/high-cardinality/cost-optimization-and-emergency-response-surviving-cardinality-spikes-without-breaking-the-budget/) covers the specific tactics for budgeting and enforcing cardinality limits at the service level, including automated enforcement via collector configuration, in more depth than fits here.

**Review the pricing model itself periodically, not just usage against it.** Data volume grows every year almost by default as systems scale. If the pricing model charges per unit of something that grows in step with your infrastructure, the bill grows in step with it too, no matter how disciplined the usage practices are.

Periodically checking whether the pricing structure still fits the shape of your telemetry, rather than assuming a vendor chosen years ago is still the right fit, is part of the same discipline as auditing usage.

## Is cost management the same as data reduction?

Not entirely, and treating it as purely a data-reduction exercise is a common mistake. Dropping data indiscriminately to hit a budget target trades cost for visibility, and the debugging time lost during the next incident usually costs more than the observability bill it was meant to shrink.

The better framing is cost-to-value: keep the telemetry that actually gets used for detection, debugging, and capacity planning, and be deliberate about dropping or downsampling the telemetry that doesn't, rather than cutting a flat percentage across everything because a number needs to go down.

## Where to start

Observability costs grow because of a small set of identifiable mechanisms: cardinality explosion, log verbosity, retention that doesn't match query patterns, and pricing models that charge for the exact things that scale with your infrastructure. None of these are mysterious once you know where to look, and none of them require choosing between visibility and budget.

They require treating cost as a first-class signal alongside latency and error rate, checked on a cadence, not discovered on an invoice.

That's specifically the gap [Last9's Control Plane](https://last9.io/control-plane/) is built to close: real-time visibility into what's driving usage as it happens, plus the ability to drop, route, and aggregate telemetry before it hits storage, so cost decisions get made at ingestion instead of after a surprise bill.

It bills on events ingested rather than per custom metric or per series, so that cardinality growth doesn't turn into the kind of line item that shows up unannounced.

## FAQ

### What is the biggest driver of observability costs?

There's no single universal answer; it depends on the pricing model and the system. The two most common culprits are high-cardinality metrics (where a label like `customer_id` or `request_id` multiplies a metric's series count) and log verbosity (debug-level logging left on in production, or verbose logging from a noisy dependency). Both tend to grow silently until a monthly bill reflects the change.

### How much of a typical cloud budget goes to observability?

There's no single fixed percentage that applies across all organizations since it depends heavily on system architecture, telemetry volume, and vendor pricing model, but budget overruns are common: [a 2026 survey of 500 observability and platform engineering professionals](https://www.businesswire.com/news/home/20260526456726/en/New-groundcover-Survey-Finds-AI-Workloads-Now-Consume-up-to-Half-of-Observability-Spend) found 53% experienced budget overages of 10% or more in the previous fiscal year.

### Does reducing observability data hurt incident response?

It can, if data is cut indiscriminately. Dropping telemetry that's actually used for detection and debugging trades a smaller bill for slower incident resolution, which usually costs more than it saves. The better approach is being deliberate about what gets kept at full fidelity (the telemetry used during actual incidents) versus what gets downsampled or dropped (data that's rarely or never queried).

### What's the difference between cardinality-driven cost and volume-driven cost?

Cardinality-driven cost comes from the number of unique label combinations on a metric, and it can grow combinatorially: a single new label can multiply a metric's cost many times over in one deploy. Volume-driven cost, more common with logs and traces, grows roughly linearly with traffic and verbosity. They need different fixes: cardinality needs budgets and label discipline, volume needs sampling and retention tuning.

### Should observability cost management happen before or after data is stored?

Before, wherever possible. Filtering, aggregating, or dropping low-value telemetry at ingestion is cheaper than storing everything and cleaning it up later, and it also means the cost decision gets made once, at the pipeline level, instead of being fought repeatedly against an ever-growing stored dataset.

### How do I know if my observability pricing model is the right fit?

Check what the model charges you for (per host, per custom metric, per GB ingested, per seat) against what grows fastest in your system. A pricing model that charges heavily for the thing that scales fastest with your infrastructure (often cardinality or log volume in a microservices environment) will produce a bill that grows in lockstep with your architecture, regardless of how disciplined your usage practices are.