// the find
prometheus-community/yet-another-cloudwatch-exporter
Prometheus exporter for AWS CloudWatch - Discovers services through AWS tags, gets CloudWatch metrics data and provides them as Prometheus metrics with AWS tags as labels
YACE polls CloudWatch for metrics across a huge list of AWS services and exposes them to Prometheus, using tag-based discovery so you don't have to hardcode resource ARNs. It's for teams running a non-trivial AWS footprint who want Prometheus-native monitoring without writing a bespoke exporter per service.
Tag-based auto-discovery covers 100+ CloudWatch namespaces out of the box, so adding a new RDS instance or Lambda function to monitoring is a tag, not a config change. Decoupled scraping (its own polling interval, separate from Prometheus's scrape interval) exists specifically to avoid hammering the CloudWatch API, which is the real cost/throttling bottleneck in these exporters - it even exposes a yace_cloudwatch_requests_total metric so you can track and forecast your own CloudWatch bill. Multi-account support via STS AssumeRole with external ID handling is built in, which matters if you're running a central monitoring account across an AWS Organization. It can also be embedded as a library if you don't want to run it as a standalone binary.
Still pre-1.0 and says so plainly - breaking changes land between releases, so pin versions and actually read the changelog before bumping. It depends entirely on consistent tagging discipline; anything untagged needs manual static job config, which doesn't scale the same way and is easy to let drift. The quick-start IAM policy in the README is a flat wildcard-resource grant across a dozen services - fine for a demo, but don't copy-paste it into production without trimming it to the namespaces you actually use. GetMetricData calls are still billed per request; concurrency controls help avoid throttling but won't stop costs climbing once you're scraping dozens of namespaces across multiple accounts, and that's left entirely on you to watch.