cloudformation-coverage-roadmap
cloudformation-coverage-roadmap copied to clipboard
aws-cloudformation
AWS::CloudWatch::Alarm - allow tags
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.
@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.
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.
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
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.
+1 as well - this would be huge for us to be able to fully utilize tags for automating dashboard creation.
+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.
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.
using description for tags. so desperate we are. no patience we have.
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 }
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...
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:
- Lambda function which performs the SDK call.
- Logs-related Lambda function.
- 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.
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.
+1 from August 2022. Come on guys, this is basic stuff. This issue has been open for 3+ years.
