Observability

S4 Metrics

Govern CloudWatch metric cardinality

Tame metric cardinality cost AWS service it replaces: CloudWatch custom metrics

Cut your CloudWatch custom-metric bill: govern metric cardinality at ingest, then auto-baseline and roll up savings across your whole AWS Organization.

S4 Metrics governs CloudWatch custom-metric cardinality at the ingest edge — drop high-cardinality dimensions, bucket numeric ones, and aggregate windows BEFORE PutMetricData, so you pay for the series you need instead of an unbounded explosion. The open-source metricsd collector (StatsD/DogStatsD + OTLP/EMF/PutMetricData intake) does the governing and emits to CloudWatch plus an optional full-resolution S3/Prometheus tee. The commercial layer adds auto-baseline and an AWS Organizations consolidated rollup.

The problem

CloudWatch bills custom metrics per unique time series (namespace + metric name + dimension-value combination), where the first 10,000 series cost $0.30 each per month on a tiered rate. A handful of high-cardinality dimensions — user_id, request_id, path, instance_id — multiply combinatorially into thousands of series. What inflates the bill is not bytes or request volume but this unbounded explosion of unique series.

How it works

1
Point telemetry at metricsd

Override only the endpoint of your StatsD/DogStatsD, OTLP, EMF, or PutMetricData senders to the metricsd collector, leaving application code untouched.
2
Baseline your costliest dimensions

Auto-baseline scans your account read-only via ListMetrics, ranks dimensions by their contribution to the billable series count, and proposes a priced governance rule set.
3
Govern before PutMetricData

Apply the rules to drop, roll up, bucket, and window-aggregate dimensions before emit, so only the series worth paying for reach CloudWatch's billing path.

Highlights

Cardinality governance at ingest: drop / bucket / aggregate before PutMetricData.

Auto-baseline ranks your costliest dimensions and proposes a priced rule set.

AWS Organizations consolidated rollup via a READ-ONLY (ListMetrics-only) cross-account role.

What's included

metricsd OSS collector — StatsD/DogStatsD, OTLP, EMF, and PutMetricData intake, then govern, aggregate, and emit to CloudWatch.
Governance engine — deterministic keep / drop / rollup / bucket / sample on dimensions, with 60-second window aggregation and DDSketch quantiles so you stop sending one series per request.
Tier-aware dollar dry-run — a before/after/savings estimate priced against CloudWatch's tiers, from a file or a live read-only ListMetrics scan, before you apply anything.
Auto-baseline rule proposal (commercial) — ranks your costliest dimensions and writes a priced rule set as plain OSS YAML.
AWS Organizations consolidated savings rollup (commercial) — read-only, tier-correct per-account and org-total estimates.
Optional full-resolution tee — mirror dropped dimensions to S3 or Prometheus remote-write so nothing is thrown away, just moved off the per-series billing path.
Plain OSS YAML rules — the open-source metricsd reads them verbatim; no lock-in.

Use cases

Teams whose custom-metric bill is running away because user_id, request_id, or path landed on a metric and exploded into thousands of series.

Multi-account organizations that need one consolidated, tier-correct view of where cardinality cost lives.

Pre-spend cost review — price a candidate rule set with the dry-run and compare projected savings to the AMI rate before changing anything.

Teams that must keep full-resolution detail for investigations but want it off the per-series billing path (S3 / Prometheus tee).

FAQ

Will I lose the data I drop?

No. Dropped dimensions can be tee'd at full resolution to S3 or Prometheus remote-write; the detail is not deleted, just moved to storage that isn't billed per series, so you can read user_id back from the tee during an investigation.

Does this lock me in?

No. Every rule is plain OSS YAML that the open-source metricsd reads verbatim, and proposals are round-tripped through the OSS engine before you see them. Cancel the subscription and your collector and rules keep working unchanged.

How does it access my account safely, and where does it run?

The commercial CLI is strictly read-only — cloudwatch:ListMetrics, organizations:ListAccounts, sts:AssumeRole — and never emits metrics or mutates your account. Cross-account scans assume a role you create that grants ListMetrics only, with a fixed session name for CloudTrail audit. Everything runs on an AMI inside your own VPC.

What inputs are supported?

metricsd ingests StatsD/DogStatsD (UDP), plus OTLP metrics, EMF, and PutMetricData over HTTP. Migration is an endpoint override only.

What is open source versus commercial?

The collector (ingest/govern/aggregate/emit) and the tier-aware dry-run are open-source Apache-2.0 metricsd. The commercial layer adds the ListMetrics auto-baseline that writes rules for you, the AWS Organizations consolidated rollup, a savings dashboard, and one-click AMI/CloudFormation deploy — built on top of the OSS core, never a fork.