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. This is the maximum of the lower 99% of the month's hourly host counts. It excludes the top outlier hours before it takes the maximum. A brief autoscale spike under about 1% of the month's hours (roughly 7 hours in a 730-hour month) can fall inside that excluded slice. It never touches the bill. A longer spike sets the month's host charge. So does a spike that repeats often enough to leave the top 1%. The charge is the same as if that many hosts ran all month.

The result is the opposite of "any spike costs you". Short, rare spikes cost almost nothing under this method. A sustained autoscale event bills as if it ran all month. The lever is to cap how high and how long an autoscaling group can scale. Do not try to remove every spike.

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

Adding one metric name does not add one billable metric. Datadog counts a custom metric as a unique combination of metric name and tag values, including the host tag. Tag one metric by customer_id or request_id across a growing user base, and it becomes thousands of billable series. No new metric name is needed. The fix is to drop or aggregate the highest-cardinality tags, not to rename 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 adds five more. That gives up to ten billable metrics behind what looks like one metric.submit call in code. This compounds with the cardinality trap above. A high-cardinality histogram is the 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, and nobody may notice. A log that is ingested but never indexed still bills its ingestion cost, even though nobody can search it. Many teams send everything to full-price indexing by default. They do not decide case by case what needs to be searchable. This is the most common way a logging bill outgrows the traffic it describes.

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. AWS's launch announcement states the tradeoff. AWS says Standard stays the choice for logs that need "real-time operational visibility and advanced analytical capabilities". Its examples: "extracting metrics from logs, anomaly detection, sensitive data protection, or real-time logs analysis". IA supports none of them. Logs Insights queries still work on IA logs. Metric filters, alarms derived from log content, and anomaly detection do not. The move is safe only for logs that feed no live signal.

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

Datadog's documentation says this. "If a metric is not submitted from one of the more than 1,000 Datadog integrations it's considered a custom metric". The rule includes OpenTelemetry metrics outside Datadog's built-in semantic-convention mappings. Teams use OTel to stay vendor-neutral. Many then find that their metrics bill at custom-metric rates, with the cardinality multiplier, unless the metric matches a mapping that Datadog ships. CloudWatch has a similar gap. OTel metrics sent through its OTLP endpoint bill by ingested byte. That is a separate meter from its per-metric custom-metrics pricing.

A CloudWatch log group defaults to never expiring

A CloudWatch log group's default retention is "Never Expire" unless you set a period. Every byte ever ingested into that group keeps billing storage forever. Nothing cleans it up, and nothing fails, so nothing alerts you. The cost 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. Almost nothing forces anyone to set it.