New major optional template section - Stack tags

[gwenael-hagenmuller]

1. Title

New major optional template section - Tags

2. Scope of request

A new major (optional) template section which could be called Tags to list the tags to associate with the stack that is created or updated and to propagate to resources in the stack.

This list can already be passed to aws cloudformation deploy through the --tags parameter. See corresponding AWS CLI Command Reference.

That would be in the same idea of the major template section Parameters which allows the user to input custom values to his/her template each time he/she creates or updates a stack. Those parameters can be overridden thanks to the --parameter-overrides parameter of aws cloudformation deploy.

Default values specified in the Tags section of the template should also be overridable thanks to --tags parameter (which should probably be renamed).

Tags:

  Moniker:
    Description: 'Moniker tag'
    Default: 'mycompany:moniker=myservice-myenvironment-awsregion'

  Service:
    Description: 'Service tag'
    Default: 'mycompany:service=myservice-myenvironment-awsregion'

  Environment:
    Description: 'Environment tag'
    Default: 'mycompany:environment=myenvironment'

$ aws cloudformation deploy \
   --tags-overrides \
      Moniker="mycompany:moniker=myservice-DIFFERENTenvironment-awsregion"

It should be possible to reference parameters in the Tags section like it is possible in the Resources section.

Parameters:

  Environment:
    Description: 'Environment in where to deploy the stack'


Tags:

  Environment:
    Description: 'Environment tag'
    Default: !Join ['', ['mycompany:environment=', !Ref 'Environment']]

3. Expected behavior

Tags:

  Moniker:
    Description: 'Moniker tag'
    Default: 'mycompany:moniker=myservice-myenvironment-awsregion'

  Service:
    Description: 'Service tag'
    Default: 'mycompany:service=myservice-myenvironment-awsregion'

  Environment:
    Description: 'Environment tag'
    Default: 'mycompany:environment=myenvironment'

would have the same behavior as:

$ aws cloudformation deploy \
   --tags \
      mycompany:moniker=myservice-myenvironment-awsregion \
      mycompany:service=myservice-myenvironment-awsregion \
      mycompany:environment=myenvironment

4. Category

Other (IoT, Migration, Budgets...)

[tkahnoski]

This would do a lot for tooling. As is we're looking at having to build custom logic around create-stack/update stack to use the --tags argument, but being able to define this as part of the Stack itself would be a massive improvement!

We use tags for limiting team access to things so teams right now can't be granted 'delete stack' permissions in a general way.

[benbridts]

I like this idea a lot, but would like to nitpick some details:

Format

I think it would be best to have to properties, one for Tag Key, an one for Tag Value. Eg:

Tags:
  Moniker:
    Description: 'Moniker tag'
    Key: mycompany:moniker
    Default: 'myservice-myenvironment-awsregion'

References

I can see a value in being able to use an input parameter as a tag, but I see more value the other way around. Another approach might be to work similar to exports and allow the template author to indicate which parameters should also be tags.

Parameters:
  Environment:
    Description: 'Environment in where to deploy the stack'
    TagKey: mycompany:moniker

This leads to some extra advantages where it can follow the exact behaviour regarding overrides as Parameters.

The fact that you cannot use !Refs / !Joins in a description is tracked in aws-cloudformation/cfn-language-discussion#55, adding the same kind of "Tag Export" to the solutions proposed there would address this.

Behaviour

As Parameters

If tags are an extension of parameters, most behaviour is already defined. One thing that needs to be addressed is how to handle possible conflicts with tags from outside the template. I think that making "template tags" behave as read only tags when using the tags apis might be a good solution.

As new section

Updating Tags could work exactly like how tags work right now, with the caveat that it should be impossible to remove tags that are defined in the template. If there will be an "AllowedPattern" for Tags, this should also always be validated.

[electrofelix]

Supporting this would allow fully handling compliance tagging for cloudformation stacks via a transform macro.

Right now can add a custom transform to the template, where the macro lambda walks all of the resources defined to apply tags defined by a platform team. That allows for teams not to have to update config to roll out tag changes, just redeploy existing artifact when the tag store has been updated and have the macro update the template with the new values before a changeset is created. It also side steps issues around tags changing and trying to do rollback to an earlier release.

Unfortunately not possible to automatically apply the stack level tags from the same macro. instead these must be specified at deploy time.

This makes the deploy pipeline the only way to handle injecting tags automatically to be used to create resources. Why not use this? That works provided the deploy pipeline is the only way to create resources, ignoring local dev creating temporary stacks. When trying to ensure all resources are tagged for cost tracking, being able to automatically alter the tags based on who is deploying to help capture this is very helpful. Deploy pipeline user, add defaults, developer, add ir skip some tags.

Also turns out that stack level tags are propagated after resource creation, while most resource level tags are added to the resource creation request. That complicates adding SCPs requiring tags at request time, similarly having any automated remediation using aws config will always trigger even if the right tag would be applied later because the initial item recorded is missing the tag.

Allowing for the template to manage these means platform support team can just provide a macro into every aws account and tell teams to use it and it's covered with 1 automation whether it's a dev deploying an isolated stack to test things out, or the deploy pipeline assuming the team is using exactly what is provided and don't have a custom use case.