Cloud Tagging Strategies
guidance on proper tagging strategies for the public cloud
It is strongly recommended that anyone operating in the cloud is suggested to develop a tagging strategy.
Tagging helps in operating cloud services by having a common identifier for a solution or parts of a solution. So being able to find all the VMs and Databases configured for a service would be an example.
Beyond that there are many tools in the cloud that can help you manage your work by tag. An example use case is configuring your cloud back up to handle backup by a tag. Say that your development systems only need to keep backups for a few weeks where production requires a year retention. Having an environment tag that has values of Dev and Prod would help you implement that. So that when you start up a new Dev instance it automatically starts backing up with the correct retention.
Some items to consider:
1. Make sure you pick a multi cloud format
2. Identify services that can't be tagged. Record and list what you can not tag.
3. Use just enough tags. Look at avoiding putting in tags that you can query in other ways. Examples are provider (AWS/Azure/GCP) or Region
4. Try not to make tags that will require frequent update.
Some Links to help
An example table of tags:
|created-by||The user, group or role that has created the resource||Identifier of who or what created the resource. For AWS, use the automatic AWS “createdBy” cost allocation tag.||“bbadger,” “DBAdmin,” “CloudOps”|
|business-owner||The user, group or role that owns the resource and is accountable for the cost||Use to identify who owns the business results. Examples include a PI or a campus HR unit or Lab.||“bbadger,” “LOB1,” “LOB2”|
|operation-owner||The user, group or role that is responsible for operating the resource||Use groups or roles as values if you want to limit the updates. Use this to authorize access to resources via IAM.||“bbadger,” “DBAdmin,” “CloudOps”|
|cost-center||Use the cost center ID that will be commonly recognized by employees and will integrate with financial systems.||“UDDS-A06xxx”|
|department||The department that owns the resource or is accountable for the cost||Use functional departments to avoid impact of organizational changes, rather than using organizational strings aligned to programs or projects.||“DoIT,” “UW-cloud-team,” “IT,” “HR”|
|project||The project that the cloud resources refer to||Use project names or identifiers that follow a naming convention.||“PROD_ERP,” “DEV_R”|
|service (or application)||The application or service name that runs on the resource||Group multiple cloud resources under the same service or application name.||“CRM,” “ERP,” “datalake”|
|environment||The purpose of the deployed environment||Mirror the environment names you use in your software development life cycle.||“dev,” “pre-prod,” “prod”|
|stack||The technology stack installed on the resource||Group the most commonly used technology stacks in your organization. Use this to check for vulnerabilities or required technology updates.||“LAMP,” “.net,” “LAMP_php5.7|
|version||The version of the deployed resource||If you deploy using infrastructure-as-code tools, use this tag to track the version of the deployment template.||“1.12,” “12.14”|
|expires-on||The expiry date of the resources||Use this to automate the decommissioning of temporary resources. Example would be a Proof of Concept setup.||“20210331”|
|compliance||The regulatory frameworks the workload has to comply with||Use this to indicate resources that may fall under a specific regulatory compliance framework. Use this to check that specific compliance framework practices are in place. Break this down into multiple tags, one for each regulatory framework, if necessary.||“HIPAA,” “FERPA”|