CloudWatch custom metrics for a permitting API need actionable dashboards. Which dimension strategy avoids high-cardinality explosions?
Select an answer to reveal the explanation.
Short Explanation
Dimensions are the labels on your dashboard knobs—stage and route help; citizenId is a million tiny knobs nobody can turn. Stick to low-cardinality labels so CloudWatch stays useful and cheap. Per-user ids belong in logs or traces, not metric dimensions.
Full Explanation
CloudWatch custom metrics for a permitting API need actionable dashboards without high-cardinality explosions, so use low-cardinality dimensions such as stage and route while avoiding unbounded values like citizenId. High-cardinality dimensions create metric explosion, cost spikes, and unusable dashboards. Municipal KPIs should aggregate by operational axes, not per-citizen identity.
Adding citizenId as a dimension on every metric creates unbounded time series and costly cardinality.
Creating a unique metric name for every citizen request body hash is an extreme cardinality anti-pattern.
Disabling dimensions entirely and publishing only raw log lines to metrics abandons useful aggregation unless a separate logs-to-metrics path is intentionally designed.
Exam caveat: Prefer low-cardinality dimensions; put high-cardinality identifiers in logs/traces instead of metric dimensions.
Operational check: Redesign metrics with stage and route dimensions, move citizenId into structured logs, validate dashboard load and cost, and document the cardinality standard for the permitting team. Keep the civic/municipal context in mind: large cities can have millions of citizenIds—metrics cardinality will follow if you dimension on them.