Support tagging per resource type

[ROSeaboyer]

Is there an existing issue for this?

• [X] I have searched existing issues, it hasn't been reported yet

Use case description

I have a large number of lambda functions in a few stacks, and a requirement to add tags to every resource being deployed. Right now, we're using the deprecated serverless-plugin-tag-cloud-watch-logs but are looking to replace that, preferably with native functionality as the approach used in that plugin causes throttling for us in some cases.

Proposed solution (optional)

• In the existing provider.logs object, add an attribute called tags for global tags added to all serverless-controlled log groups (for lambda functions, httpApi, apiGateway, and websocket).
• Extend the provider.log settings for each of httpApi, apiGateway, and websocket to allow for independent tags in a property called tags
• Add either a property called logGroupTags in the function or logs.tags (the latter option for consistency with the provider section) to allow for specific tagging for the log group for a specific function
• Add a boolean flag at the provider level called something like applyProviderTagsToLogGroups to allow for applying provider.tags to all log groups; this would default to false as it would be a breaking change

The hierarchy would be provider.tags (if enabled) -> provider.log.tags -> provider.logs.<event>.tags/function[].logs.tags

I understand that there's been a lot of back and forth on this over the years, but I'm cautiously optimistic that this approach solves the long-standing concerns that people have around tagging.

[medikoo]

@ROSeaboyer per definition provider.stackTags are applied to all resources in the CloudFormation stack

[ROSeaboyer]

@medikoo Right, so that would allow us to avoid the need for adding provider.tags to the hierarchy. However, if I was to add tags to all of my log groups (and only my log groups), there's no way that I can find to do that short of making an extension resource for every independent log group.

If I were to remove the provider.tags references from the proposed solution, thoughts on the rest of it?

[medikoo]

@ROSeaboyer can you reclarify the use case then, as what you've explained as:

I have a large number of lambda functions in a few stacks and a requirement to add tags to every resource being deployed.

Can be addressed with provider.stackTags.

If that's not a solution, then I believe the use case was not explained well (or I have problems in understanding it)

[ROSeaboyer]

@medikoo I do have to add tags to each resource, but some of the tags I need to add are per resource type (ie all log groups), and some are individual to each individual resource, which is why I'm proposing a logs.tags attribute for the API Gateway definitions at the provider level and at the function level

[medikoo]

@ROSeaboyer thanks, that's clearer. This looks a rare use case that rather should be solved via external plugin. Still we can leave issue open, and if it gains significant interest we may consider taking that in.

[spongenee]

@medikoo a quick related question. Is there a way to (specifically) tag the Rest API, not the stages, other than using provider.stackTags that tags everything? I hope provider.tags tags the Rest API as well.

The concern is using 'stackTags' make many tagged resources irrelevant to the tag

[medikoo]

I hope provider.tags tags the Rest API as well.

@spongenee provider.tags are default tags for functions, and if I remember correctly they are also applied to REST API resources that are crated through http events on functions (still that might not be the case for the HTTP API, as that has been overlooked at implementation)

[nbcchen]

You can create a custom Serverless plugin and make a CloudWatchLogs:tagResource request