YACE: exporting AWS CloudWatch metrics to Prometheus by tag

What the exporter does

YACE, or yet another cloudwatch exporter, is a Prometheus exporter for AWS CloudWatch metrics, written in Go and using the official AWS SDK.

The feature list opens with the one that decides whether you need it. Stop worrying about your AWS IDs, with auto discovery of resources via tags. That is the core idea. In a static configuration you would have to list every resource by its identifier, and a resource identifier in AWS is not a friendly thing to put in a configuration file, so the exporter lets you instead select resources by a tag you already apply for grouping and cost purposes, and it discovers the identifiers for you at scrape time.

The rest of the list is the operational detail. There is structured logging in json and logfmt. Monitored resources can be filtered with a regular expression. Tag labels are added to metrics automatically, and so are dimension labels, which means the CloudWatch dimensions that distinguish one series from another become Prometheus labels rather than being folded into the metric name. And there is an option to allow exporting a zero even when CloudWatch returns nil, which is the difference between a gap in the graph and a series that reads zero.

Two further options are worth calling out. Exporting metrics with the CloudWatch timestamps is possible and is disabled by default, which is the right default since Prometheus prefers to timestamp on scrape. And static metrics support means the exporter can also cover every CloudWatch metric without auto discovery, for the services that do not support the tag based path.

The project joined the prometheus-community organisation in November 2024, which is why it is in that repository today, with announcement posts from both the Prometheus and Grafana blogs.

The service list, and what tag discovery needs

The supported services list is long, and it is the clearest statement of the exporter's scope. It runs to more than a hundred entries.

The AWS namespaces covered include the machine learning and generative AI services, with Sagemaker endpoints, training jobs, processing jobs, batch transform jobs and inference recommender jobs, and Bedrock. It includes the storage and compute core, with S3, EBS, EC2 and the spot instance variant, ECS, ECR, EFS, Lambda, and the elastic block and load balancing family. It includes the databases, with RDS, Redshift and its serverless variant, DynamoDB, ElastiCache, Neptune, DocumentDB, MemoryDB, QLDB, Cassandra, Timestream and Glue.

And it includes the networking and security services, with ApiGateway in both versions, CloudFront, ELB, NetworkELB, GatewayELB, TransitGateway, NATGateway, VPC Lattice, Direct Connect, ClientVPN, NetworkFirewall, PrivateLink endpoints and services, WAFv2, Shield, CertificateManager, ACM Private CA, and SecretsManager.

The listing also contains the metrics that come from agents rather than from the API, with CloudWatch agent metrics, ContainerInsights, the ECS flavour of it, and Managed Prometheus.

That breadth is the value of the project. Each entry is a service where the exporter knows how to enumerate resources by tag and which CloudWatch metrics to pull for them, and the effort of supporting one is a piece of work somebody else has already done.

The examples directory in the repository has the same shape, with a configuration file per service, and one for historic data, which is the pattern to follow when you add one.

Labels, cross-account roles and library use

Three features are worth understanding on their own.

The labelling is the part that decides whether the data is usable. Automatic adding of tag labels to metrics means the tag you used to select the resource comes back as a Prometheus label, so a metric from a resource tagged with its environment or its team is already split by that in the query. Automatic adding of dimension labels does the same for the CloudWatch dimensions, and the difference from tags is that dimensions are part of the identity of the CloudWatch metric, so without them several series would collapse into one and the numbers would be wrong rather than merely unsplittable.

The multi-account support pulls data from multiple AWS accounts using cross-account roles, which is how an organisation with a hub account and many member accounts scrapes everything from one exporter. The role assumption list in the module dependencies includes the security token service, which is what assumes those roles.

The third is that YACE can be used as a library in an external application. That matters when the exporter binary is not the right shape for your deployment, for example when you want the collection logic inside a service that already holds AWS credentials, or when you want to write a collector that shares the discovery and labelling code rather than the command line tool.

There is also support for scraping custom namespaces metrics with the CloudWatch dimensions, which covers metrics published to a custom namespace rather than to the standard service namespaces.

The project status, and the upgrade policy

The project status section is the most useful thing in the README for anyone running this in production, and it is unusually direct.

While YACE is at a version below 1.0.0, the maintainers say to expect that any new release might introduce breaking changes, and that the changes are documented in the changelog.

The policy for how those changes arrive is stated next. Where feasible, features will be deprecated instead of being immediately changed or removed. That means YACE will continue to work but might log warning messages, and the deprecation is expected to become a permanent change or removal within the next two or three releases.

So the contract is: a breaking change is announced by a log warning, it keeps working for a couple of releases, and then it goes. That is a reasonable way to run a pre-1.0 project, and it is a real operational commitment for anyone who depends on it, because a deprecation warning in a log is easy to miss in a large deployment.

On security, the rule is short and absolute. Only the latest version gets security updates, and older versions are not supported. There is a separate security policy file for reporting a vulnerability.

The release history shows the pace, with 0.68.0 from September 2026, 0.67.0 and 0.66.0 in quick succession in July, and the last push to the repository on 2026-10-14.

The build and the container image

The repository layout is the standard Prometheus project layout, and it comes with the tooling that implies.

There is a Makefile that includes a common one, which is the shared build system the Prometheus projects use, and the build configuration names the Docker repository and the image name. There is a promu configuration for the release tooling, a golangci configuration for the linter, a yamllint configuration for the example files, and a changelog, a release file, a version file, a maintainers file and a notice file.

The Dockerfile is worth reading because it shows what the project considers minimal.

FROM quay.io/prometheus/busybox-${OS}-${ARCH}:latest
COPY .build/${OS}-${ARCH}/yace /bin/yace
COPY examples/ec2.yml /etc/yace/config.yml

EXPOSE     5000
USER       nobody
ENTRYPOINT [ "/bin/yace" ]
CMD        [ "--config.file=/etc/yace/config.yml" ]

The base image is the Prometheus busybox image, so the container has a shell and nothing else. The binary is copied in, and the EC2 example configuration is copied in as the default configuration file, which means the image runs out of the box against EC2 metrics and you mount your own configuration over it.

The container runs as the nobody user, exposes port 5000, which is the Prometheus scrape port, and the entrypoint is the binary itself with the config file flag. The architecture and operating system are build arguments, so the same Dockerfile produces the images for each target platform.

The alternative, and when to choose it

The README names the alternative directly, and it is the one comparison worth making properly.

If you prefer a Java implementation, the official CloudWatch Exporter is the thing to look at instead. The difference is the implementation language and the ecosystem that comes with it, and it matters mainly if your organisation has standardised on one of them or has existing Java operational tooling.

The two are otherwise solving the same problem, and the official exporter is a project of the Prometheus organisation itself, which is worth weighing against YACE's much longer service list and its tag based discovery, which the official one is not centred on.

There is a third option that is not in this README but that anyone running Prometheus on AWS will know about, which is the CloudWatch agent and the metrics it pushes, or the managed service for Prometheus, which appears in the exporter's own supported services list under the AWS Prometheus namespace. Those move the data rather than pull it, and they are the right answer when you want the metrics without running a scraper against AWS at all, and the wrong answer when you want to keep the data inside your own account boundary.

And then there is the case for not exporting CloudWatch metrics into Prometheus at all, which is to treat the CloudWatch native tooling as the place to look at AWS metrics and keep Prometheus for the things you own. YACE makes that choice available rather than forcing it, since the exporter pulls only what you configure it to pull.

The clearest way to decide is the service list. If the metrics you care about are in the supported namespaces and tagged, YACE removes the work. If they are not, the configuration becomes a per-service project and the exporter stops being the cheap option.

Editorial conclusion

Adopt YACE if you run Prometheus against AWS and want CloudWatch metrics without a bespoke collector per service, because the tag based discovery and the label mapping do the tedious part. Do not adopt it if you need the guarantees of a version 1.0 project, because the maintainers state that any new release below 1.0.0 may introduce breaking changes and only the latest version receives security updates. Before you upgrade, read the changelog and the deprecation warnings in the logs, since the policy is to deprecate first and then remove within the next two or three releases.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. prometheus-community/yet-another-cloudwatch-exporter on GitHub
4. README
5. Releases