Intro
When you need to monitor your resources with a CloudWatch alarm, what you normally have to do is to create an alarm with a specific matric of that resource. Although this gives a granular level of monitoring into your resources, you always have to add or remove alarms as and when you have new resources or when you remove a specific resource. Which is an operational overhead although it can be automated if you are using infrastructure as code tool.
Another option available is to use aggregated metrics in your alarms such as CPUUtilization for EC2 so you have coverage, but at high level into a group of resources you need to monitor. The downside of this is that it lacks granular visibility into your individual resources. Also, there is only a limited number of resources that support aggregated metrics.
In September 2025, Amazon CloudWatch introduced a nice feature of allowing monitor multiple individual metrics via a single alarm using CloudWatch Metric Insights. By using Metric insight SQL queries in the alarm, it automatically updates its query results with each evaluation and adjusts in real time when resources are created and deleted.
With the introduction of the multi-metric alarms, you can now get both granular level per resource monitoring as well as less maintenance where you don’t need to update alarms when resources are created or removed from your application because the alarm itself will automatically discover and monitor the resources.
How it works
You can define a generic SQL statement as the alarm metric.
For example, let’s assume that you would like to monitor all your SQS queues for available messages and if there are any messages available you need to be notified.
For this requirement, you can define a query as follows:
SELECT MAX(ApproximateNumberOfMessagesVisible)
FROM SCHEMA("AWS/SQS", QueueName)
GROUP BY QueueName
ORDER BY COUNT() DESC
With this query, the alarm will monitor all your queues for ApproximateNumberOfMessagesVisible count and trigger the alarm if a specific queue has at least one visible message. Also, if you add a new queue after the alarm is created, it will be taken into account when evaluating this query.
Also, you can use tags to filter the resources you need to monitor. For example…
SELECT MAX(ApproximateNumberOfMessagesVisible)
FROM SCHEMA("AWS/SQS", QueueName)
WHERE tag.Component = 'consumer'
AND tag.Environment = 'production'
AND tag.IsDLQ = 'true'
GROUP BY QueueName
ORDER BY COUNT() DESC
It would have been a great feature if this supports wildcards or regex based filtering into the resource properties, but as of now, only ways to use filters are using tags or the complete property value as equal or not equal.
When you create the alarm with this Metrics Insights Query, you can see a new section on the alarm called “Contributors”. Here, you can see all the resources that match the conditions in the alarm query as well as the current state of each contributor.
Image: CloudWatch multi metric alarm contributors.
Alarm states
When a single contributor metric breached the threshold, then its state will be changed to in alarm state. And in the alarm details, it is clearly defined which contributor caused the alarm to change the state. This is super helpful to identify the exact resource that triggered the alarm.
Image: CloudWatch multi metric alarm notification.
The alarm action is based on the contributor transitions. Which means even when the alarm is already in ‘In alarm’ state, if another contributor breached the threshold and its state becomes ‘In alarm’, the alarm action will be triggered.
Image: CloudWatch multi metric example alarm history.
This is how the similar situation shows in the CloudWatch console.
Image: CloudWatch multi metric example alarm graph.
Try this yourself
I have created a Github repository with a SAM template that helps to deploy some AWS resources into your AWS account and try this scenario.
Pre-requisites
You need to enable the CloudWatch setting “Resource tags for telemetry” if you need to use tag based filters in these queries. Go to CloudWatch > settings > Enable resource tags on telemetry in your region to enable this.
Clone the repository: https://github.com/pubudusj/cloudwatch-multi-metrics-alarm
Deploy the stack using AWS SAM CLI.
Once the stack is deployed, you can see in the created CloudWatch alarm, the contributors are available.
When you add some messages into one of the SQS queues, you can see the alarm state changed and you will receive the alarm notification which includes the contributor.
You can uncomment line 64 - 74 and deploy again to create a new resource.
This new resource will be evaluated and you can see it is listed in the contributors list.
If you add a message to the new queue, the alarm triggers.
Likewise, any resource new or old that matches the query will be considered to evaluate the alarm.
Limitations
There are some notable limitations in this approach.
Currently a single query can return no more than 500 time series and it is a hard limit. Which means as per the above query, maximum 500 resources can be monitored, which might not be not sufficient for a application with a lot of resources. When you have more than 500 resources to monitor, you will have to use multiple alarms.
There is no wildcard or regex supported in the query (comparing to some other features in CloudWatch)
Summary
The new feature of CloudWatch is great for monitoring dynamic resources in your application without the management overhead of adding/removing alarms when the resources are created and deleted. There are some hard limits where this might not be suitable for all the situations. However, I believe there will be more improvements added to this feature in near future - like wild card or regex based resource filtering, that will give better developer experience.
Resources
Release news: Amazon CloudWatch query alarms now support monitoring metrics individually. https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-cloudwatch-alarm-multiple-metrics/
Creating a Metrics Insights CloudWatch alarm. https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-alarm-create.html
Metrics Insights quotas https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-limits.html
👋 I regularly create content on AWS and Serverless, and if you're interested, feel free to follow/connect with me so you don't miss out on my latest posts!
LinkedIn: https://www.linkedin.com/in/pubudusj
Twitter/X: https://x.com/pubudusj
Medium: https://medium.com/@pubudusj
Personal blog: https://pubudu.dev
Top comments (1)
Great post Pubudu