(core): When cloudformation spec adds a Tags property to an existing resource, this can break customer deployments or cause unexpected changes

[madeline-k]

If a CDK user has added Tags to a construct, those tags will be added to all cloudformation resources within that construct's scope. If the Tags property was added to a resource via a cloudformation spec update, then when the CDK user updates their CDK version, a new Tags property will be added to that resource. This might not be what the user intended, and can cause deployment failures in some cases.

Reproduction Steps

Repro steps for one incarnation of this issue.

1. Deploy below sample with CDK version 1.113.0 or below.

export class CodeDeploy extends cdk.Construct {
  constructor(scope: cdk.Stack, id: string, props: cdk.StackProps) {
    super(scope, id)
    
    const fn = new lambda.Function(this, 'MyLambda', {
      code: new lambda.InlineCode('foo'),
      handler: 'index.handler',
      runtime: lambda.Runtime.NODEJS_10_X,
    });
    const alias = new lambda.Alias(this, "alias", { aliasName: "Prod", version: fn.currentVersion })

    const deployment = new codedeploy.LambdaDeploymentGroup(this, "deployment-group", {
      alias,
    })

    // This adds a 'Name' tag to all cloudformation resources in the `deployment` construct's scope.
    cdk.Tags.of(deployment).add('Name', `buffer-${props.environment}`)
  }
}

2. Upgrade to CDK version 1.114.0 or greater.

What did you expect to happen?

Deployment succeeds after upgrade.

What actually happened?

Deployment failed with error "Update to resource type AWS::CodeDeploy::Application is not supported" after upgrade, because the "Name" tag was added to the CodeDeploy::Application resource inside the LambdaDeploymentGroup construct.

Workaround

Explicitly remove tags from being added to specific resource types within your constructs.

const tagOptions = {
  excludeResourceTypes: ['AWS::CodeDeploy::Application'],
};
cdk.Tags.of(deployment).add('Name', `buffer-${props.environment}`, tagOptions);

---

This is 🐛 Bug Report

[rix0rrr]

The solution to this will probably involve some feature flag. I don't see how else it could work. I'm thinking:

{
  "context": {
    "@aws-cdk/core.taggableResources": "1.115.0"
  }
}

Which will only apply tags to resources that were considered taggable in 1.115.0, or something like that.

That might actually be hard, the CloudFormation spec version might be easier, but further removed from users:

{
  "context": {
    "@aws-cdk/core.taggableResources": "3.38.0"
  }
}

Uhh, what now?

Another alternative is to deprecate tree-based tagging and replace it with something more explicit.

[polothy]

Just ran into this issue. Thank you very much for providing a workaround, worked like a charm!

Would tagging via the CloudFormation Stack avoid problems like this? For CodePipeline CloudFormation Actions, would have to generate a separate file for stack configuration (Scroll down to TemplateConfiguration here).