cfntagger
If there's one thIng I like in Azure, then it's Resource Groups. Inventory management in AWS is kinda difficult; if you're meticulous, you probably use CloudFormation or Terraform to deploy your infrastructure. And if you're truly dedicated, you probably use tags to identify projects, owners and/or creators. But if you're working in a team, it must be verified that all members use the same values for tags. I've seen too many times entries for 'Environment' like 'prod', 'Production', or 'PRD'. Which renders your AWS inventory queries either useless or way too complex.
Basically, your CloudFormation templates don't need to be littered with tag definitions: they must be programmatically added in a CI/CD chain before deployment. Programs like that are hard to find. There is Yor by BridgeCrew, but after some testing I found it to have too many quirks. that's why I developed my own CloudFormation tagging tool, called CfnTagger.
Cfntagger is a Python module which takes its configuration from an environment variable in the form of a dict:
Then, it's just a matter of running the tool on either a full directory or a single file. You can dry-run it to verify which changes are going to be applied before actually modifying anything. Another possibility is the option of having the git repo and file which defines the resource as tags as well, so you can easily identify which resource has been defined where.
Basically, your CloudFormation templates don't need to be littered with tag definitions: they must be programmatically added in a CI/CD chain before deployment. Programs like that are hard to find. There is Yor by BridgeCrew, but after some testing I found it to have too many quirks. that's why I developed my own CloudFormation tagging tool, called CfnTagger.
Cfntagger is a Python module which takes its configuration from an environment variable in the form of a dict:
$ export CFN_TAGS='{"Creator": "Erlich", "Application": "Aviato"}'
Then, it's just a matter of running the tool on either a full directory or a single file. You can dry-run it to verify which changes are going to be applied before actually modifying anything. Another possibility is the option of having the git repo and file which defines the resource as tags as well, so you can easily identify which resource has been defined where.