An Introduction to Tagging
Tags: cloud, aws, gcp, azure
Published: 2022-10-10 21:38:34

Anonymous resources in technical environments can be a real headache. They can be a security risk, they can be an unexpected source of cost, and they can introduce unnecessary complexity. This is what makes tagging absolutely vital in any technical organization, but this also comes with its own set of headaches. What tags should be introduced for resources? How should these tags be formatted? Where should this information be consolidated? This post will introduce a variety of approaches for tagging in a technical environment, and will link resources for further research. 

## Definition

Tags consist of a key and a value, both of which are typically strings.  Tags are meant to be applied to a resource or a set of resources, and are meant to reflect some kind of metadata about the service. In this instance, metadata refers to data that elucidates the identity and purpose of the resource. Among other things, this could refer to the author of the resource, the desired environment of the resource, or the project that the resource is associated with. 

The details for how tags are implemented and administered vary across major cloud providers, but something consistent across all of them is that tags can be utilized to delineate access and permissions. For example, something with a tag with a key/value of “environment”/”development” would likely reflect a more lenient permission set than something with a key/value of “environment”/”production”. This is typically achieved through a cloud provider’s identity & access management service. Tags are often also integrated with a cloud provider’s billing services. If tagged properly, it can often be possible to determine how much money a specific project is spending within your cloud environment. (This direct integration does not occur with GCP’s tags, but can be worked-around with GCP’s ‘labeling’ tool.)

## Tag Categories

By definition, tags can be quite broad. However, as large technical organizations have experimented with tagging practices, specific tagging categories have emerged. AWS documentation delineates four tag categories:

- Technical tags: Information about the resource that may need to be accessed programmatically. (Cluster-id, resource-id, etc.)
- Tags for Automation: Information that might be accessed by automation to perform routine maintenance (Date/time, explicit opt-in/out, etc.)
- Business tags: Information meant to associate cost with responsible parties. (Owner, project-id, etc.)
- Security tags: Not sensitive security information, but instead information associated with how sensitive the information is, or if it needs to be held to certain compliance standards. (Confidentiality-id, compliance-id, etc.)

Microsoft Azure documentation breaks this down even further, and delineates tag categories for resource management, workload optimization, and operations management.  Something to highlight in both of these categorizations is that these are all tags designed with a specific use-case in mind. This could be service-orchestration, cost-management, or automated compliance, but it is important when approaching tag practices to anticipate what your use-cases will be. 

## Best Practices

The first step in establishing best practices is to standardize tagging across your organization. This is done through a tagging schema. With this, you can establish what tags new resources should be associated with, and the format of valid key/value strings. Here are a few things to consider:

- Do not include personally identifiable information (PII) in tags. Tags can be displayed in cost-reports, which may violate compliance requirements.
- Consider enforcing the value of a tag to be one of a list of strings. An example of this list could be [‘development’, ‘staging’, ‘production’] as possible values for ‘environment.’
- Consider enforcing specific prefixes or suffixes. An example of this could be enforcing one of ‘web-’ or ‘backend-’ as a prefix for values associated with key ‘resource-id’
- It is usually better to have ‘too many’ tags than too few. 

Something to consider when implementing a tagging schema is to anticipate the audience for these tags. If technical resources are minimal, it might make more sense to have a purely functional tagging schema meant purely for technical purposes. If you’re working in a larger organization, it may make more sense to have a more ‘purpose’ oriented tagging schema, meant to provide information to inform business decisions and future investment. (For example, a ‘severity’ tag meant to convey the importance of a resource to an operation.)

Suggested Reading

https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/resource-tagging/?toc=%2Fazure%2Fazure-resource-manager%2Fmanagement%2Ftoc.json

https://cloud.google.com/resource-manager/docs/tags/tags-overview