Estimate CloudWatch custom metrics (time series count)

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

This page is the time-series measurement workflow, not the bill-boundary page: the goal is to turn CloudWatch inventory, instrumentation config, exporters, dimension combinations, and growth multipliers into a defendable active-series model.

If you are still deciding which line items belong inside the CloudWatch metrics bill, go back to the pricing guide first.

Evidence pack before you estimate anything

• CloudWatch inventory: active series by namespace and environment.
• Instrumentation config: metric names and dimension sets defined in code or monitoring templates.
• Exporters: agents and collectors that can duplicate or multiply emitted series.
• Dimension combinations: the actual value sets that expand one metric into many active series.
• Growth multipliers: fleet size, tenant count, services, endpoints, and environments that cause expansion over time.

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.

Separate baseline series from growth windows

• Baseline series: stable namespaces, dimensions, and environments.
• Fleet-growth series: per-instance or per-pod dimensions that rise with infrastructure scale.
• Tenant-growth series: customer or tenant dimensions that expand as the business grows.
• Busy-month series: migrations, experiments, or temporary environments that expand active series for a limited window.

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

When the active-series model is good enough to hand off

• Go back to CloudWatch metrics pricing if you still are not sure which costs belong inside the metrics bill versus beside it.
• Move to CloudWatch metrics cost optimization when you can defend the dominant driver and want to change production behavior.

Validation checklist

• List the top namespaces and the top dimensions used (those explain most series).
• Model baseline vs growth windows (fleet size, tenant growth, and temporary environment 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