AWS::CloudWatch::Alarm - allow tags

[Limess]

1. Title

CloudWatch supports tagging and untagging alarms, and it should be supported in CloudFormation.

2. Scope of request

Allow for tags on create, updating tags, etc.

3. Expected behavior

See 2 above.

4. Test case recommendation

• Adding tags on create of CloudWatch alarm.
• Addings tags on update of CloudWach alarm.
• Removing tags on update of CloudWatch Alarm.

5. Links to existing API doc

API Docs: https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_TagResource.html

In CloudWatch, alarms can be tagged.

6. Category tag

Management

7. Any additional context

The documentation on this feature is sparse.

Existing resource: AWS::CloudWatch::Alarm.

This is supported by Boto: CloudWatch.Client.tag_resource.

[tvb]

@luiseduardocolon It has been sitting in status "We're working on it" since Jan 11th. Any update for this? My finance dept. is killing me for not being able to filter on tags for our alarms.

[JanneKataja-TomTom]

Also hoping this gets implemented soon. We want to set incident priority and urgency based on CloudWatch alarm tags, and not have to configure these separately in another system.

[qmg-drettie]

@luiseduardocolon any updates on this ?

[thomasklinger1234]

Also hoping this gets implemented soon. We want to set incident priority and urgency based on CloudWatch alarm tags, and not have to configure these separately in another system.

THIS. It would be so much easier to tag alarms and then create a CloudWatch event rule which forwards alarm state changes to a Lambda which checks the tags and forwards messages.. Thats my plan once tagging is available

[alexbarnes]

Argh. Just ran into this one.

[djfurman]

Adding my plus-one here. We have so many teams and applications we don't know who to contact about cleaning up their alarms that point to resources that may no longer exist.

[butangero]

+1 as well - this would be huge for us to be able to fully utilize tags for automating dashboard creation.

[lisakester]

+1 We need cloudwatch alarm tags so we can allow people to tag their alarms with information that's needed for our shared lambda functions.

[ptdel]

Hoping to implement the following in one go: https://aws.amazon.com/about-aws/whats-new/2019/04/you-can-now-use-resource-level-permissions-for-amazon-cloudwatch/ would be nice to deploy tagged cloudwatch alarms via CFN alongside the policy that applies to them.

[jenshoffmann1331]

using description for tags. so desperate we are. no patience we have.

[tkrajca]

Just ran into this one as well :( any ETAs?

[farski]

If anyone needs a solution to this before it's supported natively, this is the custom resource Lambda that I'm using:

const response = require('cfn-response');
const AWS = require('aws-sdk');
const cloudwatch = new AWS.CloudWatch();

exports.handler = async (event, context) => {
  console.log(event);

  try {
    const tags = event.ResourceProperties.Tags;
    const arn = event.ResourceProperties.AlarmArn;

    if (!tags || !tags.length || !arn) {
      console.error('AlarmArn and Tags properties must be defined');
      await response.send(event, context, response.FAILED, {});
    }

    if (event.RequestType === 'Create') {
      // Create all tags on the custom resource
      await cloudwatch.tagResource({
        ResourceARN: arn,
        Tags: tags,
      }).promise();
    } else if (event.RequestType === 'Update') {
      // Remove tags that were present in the old resource properties, but are
      // no longer present
      const previousTags = event.OldResourceProperties.Tags;
      const currentTagKeys = tags.map(t => t.Key);

      const staleTags = previousTags.filter(p => !currentTagKeys.includes(p.Key));

      if (staleTags.length) {
          await cloudwatch.untagResource({
            ResourceARN: arn,
            TagKeys: staleTags.map(t => t.Key),
          }).promise();
      }

      // Create/update all values present in the current resource properties
      await cloudwatch.tagResource({
        ResourceARN: arn,
        Tags: tags,
      }).promise();
    } else if (event.RequestType === 'Delete') {
      // Remove all tags on the custom resource
      await cloudwatch.untagResource({
        ResourceARN: arn,
        TagKeys: tags.map(t => t.Key),
      }).promise();
    }

    await response.send(event, context, response.SUCCESS, {});
  } catch (error) {
    console.error(error);
    await response.send(event, context, response.FAILED, {});
  }
};

Which would work with a custom resource like this:

  MyAlarmTags:
    Type: Custom::CloudWatchAlarmTags
    Properties:
      ServiceToken: !Ref CloudWatchAlarmTaggerServiceToken
      AlarmArn: !GetAtt MyAlarm.Arn
      Tags:
        - { Key: Severity, Value: Critical }
        - { Key: LogGroup, Value: arn:aws:logs:us-east-1:1234567890:log-group:my-service-logs }

[venkiit58]

Is there any news about this? please.

[MrSakhs]

+1

[qguang]

+1

[ytsipun]

+1 from 2021!

[jrombi]

+1

[bhuvanprasadg]

+1 we needs this

[nickdavo]

I remember being at reInvent where AWS were talking about their differentiator being that they were customer obsessed. Waiting 5 years for this does not feel customer obsessed. Please add this soon.

[ninadvadujkar]

I just ran into this one as well :(

[bdoyle0182]

Pls

[cbertozzi]

+1

[guusvw]

Just for the record: +1

[ramakanth1997]

Any updates for adding tags to cloudwatch alarms via cloudformation?

[rgoltz]

Today, I run the following test via CloudFormation - Spoiler: I was able to add Tags via CFN to AWS::CloudWatch::Alarm.
Here my example in eu-central-1:

Test Cases with Stack-Level-Tags

1. Create a new stack with Stack-Level Tags (sure, still without Tag definition within the template/on the resource). In my example below, I'm adding the following stack-level Tag:

TagFromCdkOnStack - 1

2. Using the following simplified CFN YAML template as Stack-Template:

---
AWSTemplateFormatVersion: '2010-09-09'
Description: CFN Drift detection test for AWS::CloudWatch::Alarm - test for new stack

Resources:
  SampleAlarmWithStackTags:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmDescription: We like Alarms with Tags and without Drifts
      AlarmName: TestAlarm-rogo
      ComparisonOperator: GreaterThanOrEqualToThreshold
      MetricName: HTTPCode_Target_5XX_Count
      Namespace: AWS/ApplicationELB
      EvaluationPeriods: 1
      Period: 900
      Statistic: Sum
      Threshold: 100

4. Checking the Console for Tags - We can see the stack-level Tag + built-in CFN tags / default service-managed auto-tags of CFN:
   

Result

• If you create a new stack and add stack-level Tags (it's a Best Practices following the AWS Cloud Development Kit (CDK) to add Tags on Stack-Level as well: https://docs.aws.amazon.com/cdk/v2/guide/tagging.html), CFN propagate the Stack-Tags to the AWS::CloudWatch::Alarm resource. (If you run Drift-Detection, Stack is IN_SYNC)
• If you have an existing stack with stack-level Tags without an update, there are no tags. Furthermore those Stacks are in state DRIFTED.
• If an update of existing stack with stack-level Tags would help, I need to check.

Things are moving forward! 🛼🛼 - I guess/hope it's an interim step before AWS::CloudWatch::Alarm will get Tags property on resource-level ❤️

[r-heimann]

I also just tested this in eu-central-1, and it seems like they sneakily !added! tag support. This works:

AWSTemplateFormatVersion: 2010-09-09
Description: CFN Drift detection test for AWS::CloudWatch::Alarm - test for new stack

Resources:
  SampleAlarmWithStackTags:
    Type: AWS::CloudWatch::Alarm
    Properties:
      ComparisonOperator: GreaterThanOrEqualToThreshold
      MetricName: RunningInstancesCount
      Namespace: AWSLicenseManager/licenseUsage
      Dimensions:
       - Name: SubscriptionName
         Value: "Red Hat Enterprise Linux Server"
      EvaluationPeriods: 1
      Period: 900
      Statistic: Sum
      Threshold: 100
      Tags:
       - Key: Name
         Value: Test

Thanks a lot to the CloudWatch devs, but for the love of god don't disable it 😂
The documentation is not updated yet: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudwatch-alarm.html
Now it's time to finally add tags to all of my Alarms.

[j-schwerer]

Hi all,
I have to say you are an amazing community. Your votes helped us prioritize, and as you found out 😄 we are actively working on it. May I suggest to please hold a few more days until we can announce it before using it, as the deployment is still ongoing? In progress deployment implies no documentation as pointed out in the previous message, and a lot of regions still don't have it. But more importantly, if we hit any last minute issue with deployment we cannot fully rule out yet the risk of having to roll back and starting a new deployment again a few days later. I am really impatient to share this with you, with updated doc and a due announcement. I'll update here as soon as we are in a position to confirm the deployment is complete (expect a few more days).
Thanks again for your great support and interest in this feature.

[r-heimann]

Hi all, I have to say you are an amazing community. Your votes helped us prioritize, and as you found out 😄 we are actively working on it. May I suggest to please hold a few more days until we can announce it before using it, as the deployment is still ongoing? In progress deployment implies no documentation as pointed out in the previous message, and a lot of regions still don't have it. But more importantly, if we hit any last minute issue with deployment we cannot fully rule out yet the risk of having to roll back and starting a new deployment again a few days later. I am really impatient to share this with you, with updated doc and a due announcement. I'll update here as soon as we are in a position to confirm the deployment is complete (expect a few more days). Thanks again for your great support and interest in this feature.

Thank you so much!

[farski]

After 5 years, literally yesterday I finally carved out some time to deployed a custom resource for tagging alarms across our AWS Organization. This is great news, but the timing 😭

[theaussiepom]

Oh man, I feel you farski!!! Fantastic it’s being worked on, but I too finally got a working solution up and running today, throttling retries and all 😂

[bdoyle0182]

So just to confirm what's coming in the next few days will only apply to stack level tags propagating to alarms correctly? Or individual alarm resource tags as well?

[iainelder]

@bdoyle0182 From @r-heimann's message it looks like alarm resource tags are on the way.

Let's be patient so @j-schwerer can complete the deployment. We've waited 5 years so 5 more days won't kill us :-)

Thanks to the CloudWatch and CloudFormation service teams for listening to the community!

[j-schwerer]

Hi all, yes indeed individual alarm resource tags are in scope as well. I'm as impatient as you to see this deployment completed.
:-) Stay tuned, so far so good

[bdoyle0182]

Amazing! So happy to see this being added.

I asked because I tested this through cdk yesterday and seemed only the stack level tags got applied. However I think it's just a cdk update needed as it's not adding the resource tag to the template output

[r-heimann]

Hi all, yes indeed individual alarm resource tags are in scope as well. I'm as impatient as you to see this deployment completed. :-) Stay tuned, so far so good

Just wanted to let you know that (in eu-central-1) the following works:

• Adding tags using Tags property
• Adding additional tags using Tags property
• Removing tags using Tags property
• Adding tags through Stack-Level Tags
• Adding tags through Stack-Level Tags + Tags property at the same time
• CloudFormation changesets for changing tags
• Drift detection works properly (original reason why we saw that something is being worked on, drift detection was broken for CloudWatch Alarms with an error i never saw before 😄)
• All CloudFormation default tags (aws:cloudformation:*) are properly added to the Alarms

This feels like an awesome, out-of-the-box working implementation. Although I'm only talking about "pure" CloudFormation, not entirely sure what has to be done for CDK support.

[j-schwerer]

Hi all, many many thanks for the great interaction here. It is my pleasure and privilege to confirm you that you can officially use it now, expect what's new post and doc updates in the coming hours

[tommyhegarty]

Re: @r-heimann 's comment; when should we expect CDK support to roll out? Currently, using best-practices CDK (making use of Tags.of(stack).add(key, value)) does not propagate the tags down to the individual Alarm resources when cdk synthed, at least when running version 2.135

[tmcclarnon]

We have also seen an issue where only tags that have new values are being applied to the alarm resources.

[kddejong]

As this is supported we are going to close this issue. We can work on new issues as needed. https://aws.amazon.com/about-aws/whats-new/2024/04/amazon-cloudwatch-tagging-alarms-cloudformation/

[kddejong]

Re: @r-heimann 's comment; when should we expect CDK support to roll out? Currently, using best-practices CDK (making use of Tags.of(stack).add(key, value)) does not propagate the tags down to the individual Alarm resources when cdk synthed, at least when running version 2.135

This should come shortly. CDK works off of the specs/schemas so they will be building out the layer 1 tag support shortly as those files are updated with the tagging property.

[rgoltz]

Re: @r-heimann 's comment; when should we expect CDK support to roll out? Currently, using best-practices CDK (making use of Tags.of(stack).add(key, value)) does not propagate the tags down to the individual Alarm resources when cdk synthed, at least when running version 2.135

If you are using higher-level constructs (e.g. L2), it needs implementation/a PR: aws/aws-cdk#29759 (👍 would be good as well.) In case you are using L1 in CDK, it should get available soon after CDK L1 CloudFormation resource definitions update as part of an upcoming CDK release.

[katlim-br]

(1: And I thought Alarms supported tags from way before Apr 2024)
(2: I ask here because it seems like the only place where I can find some related information)

I am creating a CW Alarm with Tags using CloudFormation. It works! However, when the alarm is triggered and sent to the SNS topic, the Tags property does not arrive.

I just want to know if this is by design or could it be a missing piece or bug?

When I configure the Subscription, I also see a checkbox "Enable raw delivery" but that doesn't seem to make a difference.

Hopefully I can get an answer 🤞

[j-schwerer]

Hi Kat Lim, thanks for the question. Alarms don't propagate the tags to the notifications. Some customers use a Lambda to create a customized notification, including enriching the notification with a subset of the alarm tags, when they need. As this thread is closed, would it make sense to take future questions that don't fit in CloudFormation roadmap to the AWS repost site?