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.

Before you trust the active-series model, show which namespaces are truly custom, which dimensions only restate infrastructure identity, and which exporter or dashboard habits would make the same metric family appear larger than the billable CloudWatch series count.

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.

You are ready to hand this estimate to pricing or optimization only when another reviewer can see the baseline series, the main cardinality multiplier, and the small set of dimensions most likely to change next month if the system grows.

Sources

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

Related guides

Related calculators

FAQ