Excessive CloudWatch GetMetricData API Polling by Monitoring Tools

GetMetricData is billed by the number of metrics requested and, unlike ordinary CloudWatch API requests, it is never covered by the free tier. AWS's own cost guide warns that GetMetricData can significantly increase costs and that third-party monitoring tools often do so when they frequently pull data.

The charge grows with polling frequency multiplied by the number of metrics pulled. Integrations are often set up to collect every namespace in every Region at a short interval, several tools or accounts poll the same metrics, and metrics that nobody charts or alerts on are fetched around the clock. Because the cost appears on the AWS bill under CloudWatch rather than on the monitoring vendor's invoice, it is easy to miss.

GetMetricData requests

Billed per 1,000 metrics requested from the first call, reported under usage type GMD-Metrics

Standard API requests

GetMetricStatistics, ListMetrics and similar calls are billed per 1,000 requests after the free tier of 1 million requests per month

Metric streams

Billed per metric update streamed, plus Amazon Data Firehose delivery charges

CloudTrail data events

Optional logging of GetMetricData calls to identify callers adds CloudTrail data event charges

• In Cost Explorer, filter to CloudWatch, group by usage type and look for GMD-Metrics (for example EU-CW:GMD-Metrics) growing or making up a large share of CloudWatch spend, then group by API operation to confirm GetMetricData
• Chart the AWS/Usage CallCount metric for the CloudWatch GetMetricData API to see daily call volume and spikes
• Enable CloudTrail data events for CloudWatch metrics for a limited period and group GetMetricData events by userIdentity.arn, sourceIPAddress and userAgent to identify which tools, roles and accounts make the calls; calls made by CloudWatch dashboards and by a cross-account monitoring account also appear in CloudTrail but are not charged
• Review each monitoring integration's settings for polling interval, enabled namespaces, Regions and metric filters, and look for more than one tool collecting the same metrics

• Restrict integrations to the namespaces, Regions, resources and metrics that are actually charted or alerted on
• Lengthen polling intervals where near-real-time data is not needed, for example for cost, capacity and daily reporting metrics
• For high-volume, continuous collection by a partner tool, evaluate CloudWatch metric streams with include filters, comparing the per-update streaming and Firehose cost against current GetMetricData cost before switching
• For small, infrequent pulls in custom scripts, GetMetricStatistics can be cheaper because it is covered by the free tier of 1 million API requests
• Remove duplicate collectors so each metric is pulled by one system, and turn off CloudTrail data events for CloudWatch once the callers have been identified

• Amazon CloudWatch Pricingaws.amazon.com
• Analyzing, optimizing, and reducing CloudWatch costsdocs.aws.amazon.com
• GetMetricData - Amazon CloudWatch API Referencedocs.aws.amazon.com
• Use metric streamsdocs.aws.amazon.com
• Identifying resources driving Amazon CloudWatch GetMetricData charges using AWS CloudTrailaws.amazon.com