aws-cloudformation / cloudformation-coverage-roadmap

The AWS CloudFormation Public Coverage Roadmap
https://aws.amazon.com/cloudformation/
Creative Commons Attribution Share Alike 4.0 International
1.11k stars 56 forks source link

AWS::CloudWatch::Alarm - allow tags #64

Closed Limess closed 7 months ago

Limess commented 5 years ago

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

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

@luiseduardocolon any updates on this ?

thomasklinger1234 commented 4 years ago

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 commented 4 years ago

Argh. Just ran into this one.

djfurman commented 3 years ago

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 commented 3 years ago

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

lisakester commented 3 years ago

+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 commented 3 years ago

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 commented 3 years ago

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

tkrajca commented 3 years ago

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

farski commented 3 years ago

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 commented 3 years ago

Is there any news about this? please.

MrSakhs commented 3 years ago

+1

qguang commented 3 years ago

+1

ytsipun commented 3 years ago

+1 from 2021!

jrombi commented 3 years ago

+1

abejaranog commented 3 years ago

I'm impressed that this feature doesn't have any avances 2 years after. We need tagging for create a team-based billing strategy and CW is one of our better consumers...

ytsipun commented 3 years ago

Covered this in CDK:

class AlarmTags extends cdk.Construct {
...
  const sdkCall: customResource.AwsSdkCall = {
    service: "CloudWatch",
    action: "tagResource",
    physicalResourceId: customResource.PhysicalResourceId.of(`${alarmName}Tags`),
    parameters: {
      ResourceARN: alarmArn,
      Tags: tags
    }
  }
  new customResource.AwsCustomResource(this, id, {
    resourceType: "Custom::AlarmTags",
    onCreate: sdkCall,
    onUpdate: sdkCall,
    logRetention: logs.RetentionDays.THREE_DAYS,
    policy: customResource.AwsCustomResourcePolicy.fromStatements([new iam.PolicyStatement({
      actions: ["cloudwatch:TagResource"],
      resources: ["*"]
    })]),
    timeout: cdk.Duration.minutes(1)
  })
...

Synth results in:

  1. Lambda function which performs the SDK call.
  2. Logs-related Lambda function.
  3. Custom::AlarmTags resource holding the SDK call parameters you provide and referencing the SDK call Lambda in Create and Update properties.

🚀 Lambdas aren't populated when instantiating several AlarmTags in a stack.

farski commented 3 years ago

For anyone trying to implement this on their own like we did, be warned that the rate limit on CloudWatch tagging is 1 per second, so it's extremely easy to hit when tagging a lot of resources at once via CloudFormation, such as when spinning up a new stack.

We set a high max retries and default backoff on the CloudWatch client, and give the function a bunch of time to run, basically just to let it fail a bunch and sort itself out.

phene commented 2 years ago

+1 from 2022

pchaganti commented 2 years ago

+1

ryanzhu2017 commented 2 years ago

+1

djfurman commented 2 years ago

+1 from April 2022

Risae commented 2 years ago

+1....

dougallaninthecloud commented 2 years ago

+1

gmahe commented 2 years ago

+1

JamesKyburz commented 2 years ago

+1 from 2022

towerbe commented 2 years ago

+1 from August 2022. Come on guys, this is basic stuff. This issue has been open for 3+ years.

teague-mfa commented 2 years ago

+1

jwalls89 commented 2 years ago

+1

joshbfei commented 2 years ago

+1

Risae commented 2 years ago

Can someone please take one for the team and apply for a job at AWS to add this feature?

towerbe commented 2 years ago

@Risae , Oh, I have, trust me, under my Global Account persona. Still doesn't seem to make a difference.

I will poke our account team on this one again and see if we can get any traction.

Risae commented 2 years ago

@Risae , Oh, I have, trust me, under my Global Account persona. Still doesn't seem to make a difference.

I will poke our account team on this one again and see if we can get any traction.

I did the same.... But i just noticed that even Terraform supports tagging of CloudWatch Alarms: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/cloudwatch_composite_alarm

Anybody know why Terraform is better than CloudFormation?!

Gekkko commented 2 years ago

+1

ngander-amfam commented 1 year ago

+1 This is getting pretty ridiculous. Why no CloudFormation support after 3+ years?

tonyshearer commented 1 year ago

+1

ellisium commented 1 year ago

+1

Gtofig commented 1 year ago

+1. Lack of tag support for alarms makes it hard for CDK users to apply tags consistently using CDK aspects

Virta commented 1 year ago

+1

rbartell commented 1 year ago

+1

wjg7 commented 1 year ago

+1

zoltanmajo commented 1 year ago

+1 from 2023. Thank you in advance.

oros-fundmore commented 1 year ago

+1

felihol commented 1 year ago

+1 on this, is there any plan to solve this somehow?

larse514 commented 1 year ago

+1 running into this limitation with our CDK usage

swachter commented 1 year ago

+1

kduvzc commented 1 year ago

+1

srinivas-vangari commented 1 year ago

+1000000000

This is already supported in Terraform, why not in CFn. Other services do support this via CFn, why not CFn?