Metric Cardinality

Metric cardinality describes how many distinct metric time series a monitoring system must handle within a defined scope and time window. A series is typically identified by a metric name and a complete set of dimension or label name-value pairs. Additional boundaries, such as a namespace, account, or Region, can also distinguish metrics. Cardinality is not the number of samples: one series containing a million measurements still has a cardinality of one.

Dimensions multiply the potential number of series. Suppose a request-count metric has three environment values, four service values, and twenty endpoint values. If every combination occurs, that metric produces 240 series. Adding an instance identifier with fifty possible values could increase the theoretical total to 12,000. Actual cardinality depends on which combinations are emitted, not simply on multiplying every value observed independently. Continually changing instance or container identifiers also create series churn, increasing the number of distinct series seen over time.

In cloud architectures, choose dimensions that support specific operational decisions. Environment, service, availability zone, and normalized endpoint often provide useful breakdowns. Request IDs, session IDs, arbitrary URLs, and user IDs can produce unbounded growth. For example, use the route template /orders/{orderId} rather than a separate dimension value for every order URL. Keep request-specific identifiers in logs or traces so engineers can investigate individual failures without creating a metric series for every request.

Amazon CloudWatch illustrates the identity rules tested in certification questions. Within an account and Region, a metric is identified by its namespace, metric name, and dimensions. Namespaces separate metric identities; they do not automatically aggregate measurements. CloudWatch supports up to 30 dimensions per metric, but that limit does not make high-cardinality values safe. Changing a dimension value or adding a dimension creates a different metric identity.

CloudWatch does not automatically aggregate custom metrics across dimensions. If an application publishes RequestCount with Service and InstanceId, requesting RequestCount with only Service does not retrieve an automatically stored service-level total. Publish an explicit rollup or use an appropriate query or metric-math expression over the underlying series. Some AWS service metrics offer predefined aggregations, so do not assume their behavior applies to custom metrics. Query-time aggregation can simplify results without reducing the cardinality already ingested.

Resolution and cardinality are separate design choices. CloudWatch standard-resolution custom metrics use 60-second resolution, while high-resolution custom metrics support one-second resolution. Publishing more frequently to an unchanged metric identity increases sample volume, not cardinality. Conversely, adding unique request identifiers increases cardinality even if each series receives only one sample. Costs depend on the monitoring service's pricing model, including custom metric counts, ingestion, storage, queries, and alarm configuration.

Control cardinality before ingestion by allowlisting dimensions, normalizing values, dropping unnecessary labels, and aggregating measurements at the required operational level. Preserve meaningful statistics during aggregation: summing request counts is appropriate, but averaging instance-level averages without sample counts can misrepresent latency. Maintain distributions or suitable histogram data when percentile analysis matters. Review both active series and series churn, and test instrumentation changes against realistic fleet size and traffic diversity before deploying them.