Home › Decoder › CW:MetricMonitorUsage and CW:AlarmMonitorUsage - custom metrics and alarms

CW:MetricMonitorUsage and CW:AlarmMonitorUsage - custom metrics and alarms

CW:MetricMonitorUsage is the charge for CloudWatch custom metrics ($0.30 per metric-month for the first 10,000 in US East N. Virginia) and CW:AlarmMonitorUsage the charge for standard alarms ($0.10 per alarm-month).

In your bill the usage type reads: CW:MetricMonitorUsage, USE1-CW:MetricMonitorUsage, CW:AlarmMonitorUsage, USE1-CW:AlarmMonitorUsage

What it costs

ChargePriceUnit
Custom metric, first 10,000 metrics (CW:MetricMonitorUsage)$0.30per metric-month
Standard-resolution alarm (CW:AlarmMonitorUsage)$0.10per alarm-month

US East (N. Virginia); other regions differ. Checked 2026-11-04. Sources: AWS CloudWatch pricing, AWS price list file, CloudWatch offer, us-east-1.

Example with made-up numbers

1,200 custom metrics and 300 alarms

Metrics: 1,200 x $0.30 = $360.00 per month; alarms: 300 x $0.10 = $30.00 per month; total $390.00

If one dimension (request id) is dropped and the metric count falls to 200: 200 x $0.30 = $60.00, a saving of $300.00 per month

Typical causes

A high-cardinality dimension

Every distinct value of a dimension (user id, container id, request id) is a separate billed metric.

Per-instance metrics on short-lived hosts

Autoscaling or spot fleets create a new metric series for every new instance id.

Alarms on deleted resources

Alarms stay and bill until they are deleted, even in INSUFFICIENT_DATA.

Duplicate agents

Two agents publishing the same metrics under different namespaces bill twice.

Find it in your bill

Have a CUR file queryable in Athena? Paste this and run it:

SELECT date_trunc('month', line_item_usage_start_date) AS month,
       line_item_product_code,
       line_item_usage_type,
       line_item_resource_id,
       SUM(line_item_usage_amount)  AS usage_amount,
       SUM(line_item_unblended_cost) AS cost
FROM your_cur_table
WHERE line_item_usage_type LIKE '%CW:MetricMonitorUsage'
     OR line_item_usage_type LIKE '%CW:AlarmMonitorUsage'
GROUP BY 1, 2, 3, 4
ORDER BY month DESC, cost DESC
LIMIT 50;

Columns used: line_item_usage_start_date, line_item_product_code, line_item_usage_type, line_item_resource_id, line_item_usage_amount, line_item_unblended_cost.

No CUR file? Use Cost Explorer

  1. Open Billing and Cost Management, then Cost Explorer, and set the date range to the last 3 months with Monthly granularity.
  2. Set Group by to Usage type.
  3. In the Filters panel choose Usage type and tick the entries ending in CW:MetricMonitorUsage or CW:AlarmMonitorUsage (the region prefix, such as USE1-, differs by region).
  4. Read the monthly cost per usage type. A line that grows faster than your traffic is the one to chase with the fix below.
  5. To see which resource drives it, query the CUR above; resource IDs appear only if your CUR was set up with resource IDs included, otherwise the resource column is empty.

Column names checked against: docs.aws.amazon.com/cur/latest/userguide/Lineitem-columns.html, docs.aws.amazon.com/cur/latest/userguide/cur-ate-run.html.

The fix, step by step

Verify first

Check these before you change anything: the steps below are suggestions, and only you can see your own configuration.

  • Count metrics per namespace before cutting; a few namespaces usually account for almost all of the bill.
  • Check that no dashboard, alarm or autoscaling policy reads a metric before you stop publishing it.
  • Alarms in INSUFFICIENT_DATA may belong to resources that only run at certain times; confirm they are really unused.
  • This line is custom metrics and alarms only; AWS service metrics (EC2, RDS and so on) are not billed here.

In the console

  1. CloudWatch console > Metrics > All metrics > Custom namespaces; open each namespace and count the dimension combinations.
  2. Find the namespaces with the most metrics and the dimension (user id, request id, pod name) that multiplies them.
  3. Stop publishing the high-cardinality dimension or aggregate before publishing (metrics you stop publishing stop billing).
  4. CloudWatch > Alarms > All alarms; filter State = Insufficient data and delete alarms on resources that no longer exist.
  5. Replace several per-resource alarms with one composite or metric-math alarm where it fits.

With the CLI

aws cloudwatch list-metrics --namespace MyApp --query "length(Metrics)"
aws cloudwatch describe-alarms --state-value INSUFFICIENT_DATA --query "MetricAlarms[].[AlarmName,StateUpdatedTimestamp]" --output table
aws cloudwatch delete-alarms --alarm-names my-old-alarm
aws cloudwatch list-metrics --query "Metrics[].Namespace" --output text | tr "\t" "\n" | sort | uniq -c | sort -rn

Rollback

Re-create the alarm from its definition (export it first with describe-alarms) or resume publishing the metric.

Find your CloudWatch metric lines in your own bill

Drop in your Cost Explorer or CUR CSV. Billtrim reads it in your browser, finds the metric and alarm lines and shows the monthly dollars.

See a sample result

Paste your export: how to export a Cost Explorer CSV or CUR file in two minutes.

Questions people ask

Are AWS service metrics billed here?

No. Metrics AWS services publish by default are free; this line is custom metrics.

Do metrics I stop publishing keep billing?

A metric is billed while it is receiving data; check the CloudWatch pricing page for the exact proration rules.

Related

Part of the guide: Reduce your AWS bill as a startup: a checklist for teams with no FinOps person