search

aws / aws-cdk

The AWS Cloud Development Kit is a framework for defining cloud infrastructure in code
https://aws.amazon.com/cdk
Apache License 2.0
11.72k stars 3.94k forks source link

aws-lambda: Tags get added to EventSourceMapping even though event source mappings are not taggable in GovCloud #31965

Open bdoyle0182 opened 1 month ago

bdoyle0182 commented 1 month ago

Describe the bug

EventSourceMappings currently are not taggable in GovCloud. This results in a failed deployment if attempting to deploy a stack with an EventSourceMapping to multiple regions and will fail just on GovCloud.

The Tags documentation suggests that the cdk behavior should only Tag resources that are taggable so that the developer doesn't have to account for it.

Also, the Tag class only tags taggable resources, so you don't need to test whether a construct is taggable before applying a tag.

This is a little special where whether something is taggable or not is based on the AWS partition. But still think it should be that there is some logic added where tags are only added to the EventSourceMapping resource if the partition of the stack the construct is instantiated in is Gov.

I'm sure I can come up with a workaround but it's complicated in terms of a library in the amount of special logic I will now have to add to make sure Tags are not added to GovCloud for stack level tags if the construct type is an EventSourceMapping.

Regression Issue

Last Known Working CDK Version

No response

Expected Behavior

Tags not get added to a resource in the stack that is not taggable based on partition / region

Current Behavior

Synthesizes with tags on EventSourceMapping for govcloud partition stacks, resulting in deploy time failure in CloudFormation due to CreateEventSourceMapping 400 api failure

Reproduction Steps

n/a

Possible Solution

No response

Additional Information/Context

No response

CDK CLI Version

2.164.1

Framework Version

No response

Node.js Version

node22

OS

MacOS

Language

TypeScript, Python, .NET, Java, Go

Language Version

No response

Other information

No response

bdoyle0182 commented 1 month ago

https://aws.amazon.com/about-aws/whats-new/2024/09/aws-lambda-tagging-event-source-mappings-code-signing-config-resources/

It seems like Tags on event sources was only introduced a month ago. So I assume that this actually only became a problem after September 23rd and became a bug after that point once a cdk released that updated the L1 for EventSourceMapping to match the new cloud formation api that supported tags. If this gets rolled forward in GovCloud such that the L1 also supports tags then this bug will go away but don't know how long that will be.

I haven't been able to figure out a work around because when you instantiate an event source in CDK it creates an IEventSource which seems to use Composition rather than Inheritance on IConstruct so the consumer doesn't have access to the scope to be able to manually disable stack level Tags on the event source mapping construct. If anyone has any workaround ideas that would be great!

douglasdennis commented 1 month ago

I haven't been able to figure out a work around because when you instantiate an event source in CDK it creates an IEventSource which seems to use Composition rather than Inheritance on IConstruct so the consumer doesn't have access to the scope to be able to manually disable stack level Tags on the event source mapping construct. If anyone has any workaround ideas that would be great!

If using Tags.of(...).add("name", "value") I have found a workaround by excluding that resource type:

Tags.of(...).add("name", "value", {excludeResourceTypes: ["AWS::Lambda::EventSourceMapping"]})
bdoyle0182 commented 1 month ago

This is awesome and just what I needed, thanks so much Douglas!

I think this issue opens up a broader discussion point though on AWS partitions and feature parity between those partitions. Understandably things will get rolled out to govcloud later than commercial, but that gap leaves exposure in cdk if the L1 api is based solely on the commercial api where an api change could apply side effects to higher level concepts of the cdk like global / stack level tags that go unaccounted for. I wonder if this pattern could be better build into the cdk over the long term so that the cloud formation api of each individual aws partition could be accounted for when synthesizing if there is global context / logic that will change output dependent on an individual resource's api.

ashishdhingra commented 1 month ago

Looks like this needs to be evaluated by CDK team to figure out resources that are not taggable in GovCloud.