AWS::Logs::LogGroup - Tags

[harai]

Name of the resource

AWS::Logs::LogGroup

Resource name

No response

Description

CloudWatch Logs Log Group resource supports Tags attribute as described by AWS CLI Command Reference.

Current CloudFormation AWS::Logs::LogGroup resource doesn't support Tags property and should be supported.

Other Details

• https://awscli.amazonaws.com/v2/documentation/api/latest/reference/logs/create-log-group.html
• https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-loggroup.html

[samjarrett]

See also #77 and aws-cloudformation/aws-cloudformation-resource-providers-logs#53

[wchunl]

Apologies for delay, the release of this feature is now complete.

[samjarrett]

@wchunl documentation? https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-logs-loggroup.html

[wchunl]

@samjarrett We are working on the documentation right now, will update when published

[seittema]

Unfortunately if you have existing stacks you may hit what I think is a bug trying to add tags. It appears if you currently use StackTags on your CFT Stacks, cloudformation thinks those tags are already on your loggroup and therefore will not add the tags even if you put it in your template. We added the Tags to our resource, and only 1 showed up out of the 8 we added. The other 7 were missing, however they also mirror existing StackTags that we have had on our stacks for years.

[farski]

The way this has been implemented is not playing nicely with drift detection.

1. Create a new stack which does NOT contain a log group, but does have resource tags set on the stack itself (e.g., Foo=Bar)
2. Update the stack by adding a log group which does NOT have any tags defined
3. If you look at the log group, you'll see that the stack-level tags did propagate to the log group
4. Update the stack by adding matching tags (i.e., Foo=Bar) explicitly to the log group
5. Run a drift detection on the stack
6. The drift status will now show MODIFIED, and the details will show an expected value of {Foo=Bar, Foo=Bar}, which can never happen on the actual resource.

[RobertoTorino]

Actually we had similar issues:
Known resources
AWS::SecretsManager::Secret
AWS::ApiGateway::Deployment
AWS::EC2::NetworkAcl
AWS::ECS::Cluster
AWS::Backup::BackupPlan
AWS::Backup::BackupVault

I just recently noticed I also got this on AWS BackUp and BackUpVault , resources deployed through cdk2.0/cloudformation.

I get tags starting with Key ":aws:" and when I want to remove it in the console it gives an error that tags starting with :aws are invalid.

But no way to remove the tags...

[rgoltz]

The way this has been implemented is not playing nicely with drift detection.

1. Create a new stack which does NOT contain a log group, but does have resource tags set on the stack itself (e.g., Foo=Bar)
2. Update the stack by adding a log group which does NOT have any tags defined
3. If you look at the log group, you'll see that the stack-level tags did propagate to the log group
4. Update the stack by adding matching tags (i.e., Foo=Bar) explicitly to the log group
5. Run a drift detection on the stack
6. The drift status will now show MODIFIED, and the details will show an expected value of {Foo=Bar, Foo=Bar}, which can never happen on the actual resource.

Hi Chris / @farski - We ran into the same issue. In order to have a better tracking with AWS ServiceTeam, we split this CFN Drift detection issue and the AWS team opened a new, dedicated issue #1256

Actually we had similar issues: Known resources AWS::SecretsManager::Secret AWS::ApiGateway::Deployment AWS::EC2::NetworkAcl AWS::ECS::Cluster AWS::Backup::BackupPlan AWS::Backup::BackupVault

I just recently noticed I also got this on AWS BackUp and BackUpVault , resources deployed through cdk2.0/cloudformation.

I get tags starting with Key ":aws:" and when I want to remove it in the console it gives an error that tags starting with :aws are invalid.

But no way to remove the tags...

Bună Philip / @RobertoTorino - Regarding this in terms of AWS::Logs::LogGroup, the AWS team opened a new, dedicated issue #1255 - Here the CFN Drift detection should get better as well (Hence, you would not need to remove this helpful aws: tags.