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

https://aws.amazon.com/answers/account-management/aws-tagging-strategies/

An example table of tags:

Key	Description	Reasoning	Example
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”

The above table is based on Gartner document "Implementing a Tagging Strategy for Cloud IaaS and PaaS"

Cloud Tagging Strategies

If you have any questions, feedback or ideas please Contact Us