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
| Charge | Price | Unit |
|---|---|---|
| Custom metric, first 10,000 metrics (CW:MetricMonitorUsage) | $0.30 | per metric-month |
| Standard-resolution alarm (CW:AlarmMonitorUsage) | $0.10 | per 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
- Open Billing and Cost Management, then Cost Explorer, and set the date range to the last 3 months with Monthly granularity.
- Set Group by to Usage type.
- 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).
- Read the monthly cost per usage type. A line that grows faster than your traffic is the one to chase with the fix below.
- 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
- CloudWatch console > Metrics > All metrics > Custom namespaces; open each namespace and count the dimension combinations.
- Find the namespaces with the most metrics and the dimension (user id, request id, pod name) that multiplies them.
- Stop publishing the high-cardinality dimension or aggregate before publishing (metrics you stop publishing stop billing).
- CloudWatch > Alarms > All alarms; filter State = Insufficient data and delete alarms on resources that no longer exist.
- 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.
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
- CloudWatch Logs DataProcessing-Bytes: the log ingestion line
- Lambda-GB-Second - the Lambda compute line, and the 20% cheaper arm64
- VpcEndpoint-Hours: what interface endpoints cost
Part of the guide: Reduce your AWS bill as a startup: a checklist for teams with no FinOps person