What is your observability stack actually costing you?

Host billing runs close to the month's peak, not an average

Datadog bills infrastructure hosts at the high-water mark: the maximum of the lower 99% of the month's hourly host counts, which excludes the very top outlier hours before taking the max. A brief autoscale spike lasting less than about 1% of the month's hours (roughly 7 hours in a 730-hour month) can fall inside that excluded slice and never touch the bill. A spike that runs longer than that, or repeats often enough to no longer be the top 1%, sets the month's host charge just as surely as running that many hosts the whole time would have.

The practical upshot is the opposite of "any spike costs you": short, rare spikes are close to free under this methodology, but anything approaching a sustained autoscale event is billed as if it ran all month. Capping how high and how long an autoscaling group is allowed to scale is the lever, not eliminating spikes entirely.

A custom metric bills per tag combination, not per metric name

Adding one metric name doesn't add one billable metric. Datadog counts a custom metric as a unique combination of metric name and tag values, including the host tag, so tagging a single metric by customer_id or request_id across a growing user base multiplies it into thousands of billable series without a single new metric name ever being created. The fix is dropping or aggregating the highest-cardinality tags, not renaming metrics.

A HISTOGRAM or DISTRIBUTION metric bills as up to 10 metrics, not 1

By default, a HISTOGRAM metric generates five billable custom metrics per unique tag combination (max, median, avg, p95, and count). Turning on percentile aggregations for a DISTRIBUTION metric stacks another five on top, for up to ten billable metrics behind what looks, in code, like a single metric.submit call. This compounds directly with the cardinality trap above: a high-cardinality histogram is the single most expensive shape a custom metric can take.

Ingesting a log and indexing it are two different charges

Both Datadog and CloudWatch bill log ingestion and log storage/indexing as separate meters. A verbose logging change can move both line items at once without anyone realizing it, and a log that's ingested but never indexed still bills its ingestion cost even though nobody can search it. Sending everything to full-price indexing by default, rather than deciding case by case what needs to be searchable, is the single most common way a logging bill outgrows the traffic it's describing.

CloudWatch's Infrequent Access log class isn't a free discount

Moving a log group to CloudWatch's Infrequent Access class halves the ingestion rate, but AWS's own launch announcement is explicit about the tradeoff: Standard remains the choice for logs that need "real-time operational visibility and advanced analytical capabilities such as extracting metrics from logs, anomaly detection, sensitive data protection, or real-time logs analysis," none of which IA supports. Logs Insights queries still work on IA logs. Metric filters, alarms derived from log content, and anomaly detection do not. It's a safe move only for logs nobody's deriving a live signal from.

An OpenTelemetry metric is a custom metric unless it's explicitly mapped

Datadog's own documentation is direct about this: "If a metric is not submitted from one of the more than 1,000 Datadog integrations it's considered a custom metric," and that includes OpenTelemetry metrics outside Datadog's built-in semantic-convention mappings. Teams standardizing on OTel instrumentation to stay vendor-neutral routinely discover their metrics are billed at custom-metric rates, cardinality multiplier included, unless the specific metric happens to match a mapping Datadog ships out of the box. CloudWatch has its own version of the same gap: OTel metrics sent through its OTLP endpoint bill by ingested byte, a separate meter from its per-metric custom-metrics pricing.

A CloudWatch log group defaults to never expiring

Unless a retention period is set explicitly, a CloudWatch log group's default is "Never Expire." Every byte ever ingested into that group keeps billing storage forever, with no automatic cleanup and nothing to notice failing, because nothing fails. It just accumulates. This is the same shape as the lifecycle-policy trap on S3 and EBS: the fix is a one-time retention setting, not an ongoing cleanup task, but almost nothing forces anyone to set it.