You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(tags): excludeResourceTypes does not work for tags applied at stack level (under feature flag) (#31443)
Stacks are considered taggable, and so `Tags.of(this).add('key', 'value')` used to add tags to Stacks in scope. Usually this happens if `this` is an instance of `Stack`, which it commonly is in user code.
Since `Tags.of(...)` walks the construct tree, it will add tags to the stack *and* to all the resources in the stack. Then, come deploy time, CloudFormation will also try and apply all the stack tags to the resources again. This is both unnecessary, as well as leads to loss of control: `excludeResourceTypes` appears to not work, since it will lead to resources not being tagged in the template (good) but then the resources will still be tagged by CloudFormation because the stack itself is tagged (bad).
Also, if the tags applied this way contain intrinsics, they will contain nonsense because they are applied in a context where CloudFormation expressions don't work.
## In this change
There is way to prevent Stacks from being tagged, by including `aws:cdk:stack` in the list of `excludeResourceTypes` (this is a fake resource type that Stack tags respect).
Under a feature flag, `@aws-cdk/core:explicitStackTags`, this is now the default behavior. That resource type will be excluded by default, unless it is listed in the `includeResourceTypes` list. However, doing `includeResourceTypes` is still not desirable: stack tags should be applied directly on the `Stack` object if desired.
This requires a user to make a conscious decision between resource-level and stack-level tagging: either apply tags to the stack, which will apply it to all resources but remove the ability to do `excludeResourceTypes`; or apply tags to (groups of) resources inside the template.
Another benefit is that for tags applied at the stack level, this will resolve the following issue: #15947, as resources "becoming" taggable all of a sudden will not affect the template anymore.
Closes#28017. Closes#33945. Closes#30055.
----
*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Copy file name to clipboardExpand all lines: packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md
+29Lines changed: 29 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -104,6 +104,7 @@ Flags come in three types:
104
104
|[@aws-cdk/aws-s3:publicAccessBlockedByDefault](#aws-cdkaws-s3publicaccessblockedbydefault)| When enabled, setting any combination of options for BlockPublicAccess will automatically set true for any options not defined. | 2.196.0 | fix |
105
105
|[@aws-cdk/aws-lambda:useCdkManagedLogGroup](#aws-cdkaws-lambdausecdkmanagedloggroup)| When enabled, CDK creates and manages loggroup for the lambda function | 2.200.0 | new default |
106
106
|[@aws-cdk/aws-kms:applyImportedAliasPermissionsToPrincipal](#aws-cdkaws-kmsapplyimportedaliaspermissionstoprincipal)| Enable grant methods on Aliases imported by name to use kms:ResourceAliases condition | 2.202.0 | fix |
107
+
|[@aws-cdk/core:explicitStackTags](#aws-cdkcoreexplicitstacktags)| When enabled, stack tags need to be assigned explicitly on a Stack. | V2NEXT | new default |
107
108
108
109
<!-- END table -->
109
110
@@ -167,6 +168,7 @@ The following json shows the current recommended set of flags, as `cdk init` wou
0 commit comments