Estimate CloudWatch custom metrics (time series count)

For CloudWatch custom metrics, the key planning input is the number of unique time series. A time series is typically one metric name plus one specific set of dimension values. If you add a dimension that has many unique values, you multiply your series count quickly.

Custom metrics count inputs

• Unique dimensions: each label set is a time series.
• Metrics per service: services x metrics x environments.
• High-cardinality: avoid exploding labels.

Step 0: the basic formula

Time series ~= metric names * unique dimension combinations * environments

• If a metric has no dimensions, each metric name is usually one series per environment.
• If a metric has dimensions (service, region, statusCode, etc.), each combination becomes a separate series.

Step 1: inventory where custom metrics come from

• App instrumentation: custom business and service metrics you emit (latency, error rate, queue lag).
• Agents: exporters (Kubernetes/EC2 agents) that emit per-node/pod/container metrics.
• Log-based metrics: metric filters that turn log patterns into metrics.

Step 2: identify "multipliers" (the cardinality drivers)

• Per instance/pod: instanceId, podName, containerId -> series scale with fleet size.
• Per tenant/customer: tenantId/customerId -> series scale with customer growth.
• Per endpoint: path/method -> series scale with API surface area.
• Per region/AZ: region/az -> series multiply across deployment topology.

If a dimension is unbounded (new values keep appearing), treat it as a risk and model a growth scenario.

Three practical estimation methods

• From instrumentation config: count metric names and dimension sets in your code or monitoring-as-code templates.
• From agent inventory: estimate per-node/per-pod metric series and multiply by average fleet size.
• From CloudWatch inventory: count active time series by namespace and dimension keys from a representative week.

Worked example (why dimensions matter)

• Metric: http_requests with dimensions service and status
• Services: 12, statuses: 5 -> combinations: 60
• Environments: prod + staging -> 120 series
• If you add a tenantId dimension with 1,000 tenants -> 120,000 series

This is why "one extra dimension" can dominate the entire CloudWatch bill.

Turn series into cost

Validation checklist

• List the top namespaces and the top dimensions used (those explain most series).
• Model baseline vs busy month (fleet size and tenant growth scenarios).
• Confirm you don't have duplicated exporters emitting equivalent series.
• Once deployed, compare estimate vs measured active series from a real week.

Sources

• CloudWatch pricing: aws.amazon.com/cloudwatch/pricing

Related guides

Related calculators

FAQ