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 metric dimensions should be low-cardinality fields such as stage or route so aggregations and alarms remain tractable. Unbounded identifiers like citizenId create metric explosions, cost, and unusable dashboards. Per-request metric names or dropping structure for raw logs alone do not provide actionable, scalable metrics.