If this concept is new, no worries, just head over and read this.
I would also recommend that you spend some time thinking about how you want to approach this before just jumping in. It's not impossible to change course once you start down a path, but it is much easier to take some time and think through how best to go forward. If you really aren't sure, try and start with technical and business tags for example. A technical tag for example could be the environment, or an application ID. A business tag could be a project name, a product or type type, the actual names will be entered as values.
Some of the benefits or more practical reasons for using tags include resource organization, cost allocation (P&L, projects customer, business unit/Team), automation and access control (IAM conditions), security or risk identification.
As your environment(s) mature and grow, and become more complex it will become extremely helpful to have a solid, well thought out tagging plan.
Remember, it doesn't need to be super complicated or complex from the start, for me this is one of the situation where something is better than nothing, and the sooner the better!
Both Dev and DevOps teams often struggle with tagging consistency, both in the frequency and the tagging content itself. The eventual state to help address this, may be using automation. A great option may be to consider using yor.
Yor is another open-source tool to automatically adds tags to infrastructure configurations. Yor currently supports Terraform, AWS CloudFormation, and server less.
By default, Yor will add a number of tags to each resource block, including the name of the git organization, the repository, and the file that contains the template that created the resource. Another really powerful feature from Yor is that it adds a unique identifier which allows for quick search in Github to locate the code for example.
Top comments (0)