Tagging in the cloud: how to get the most out of it?

Tagging matters! But which tags make sense and how to get the most out of using them in the cloud?

Kamil Kovář

Tagging resources in the cloud seems like the simplest discipline. The Cloud doesn’t bind us – we can name the tag (or tag) whatever we want, and give it any value we can think of. We don’t have to use a tag at all, or we can live it up and “wrap” every resource, every virtual machine, network, database, load balancer, or container with lots of “paper”. But which tags make sense? Let’s see what strategy to choose to make the most of this functionality.

What are tags and why do we use them?

Tags are labels, signs or if you want stickers that we use to label our cloud resources. We label virtual machines, databases, virtual networks, load balancers, we label everything. Tags help us differentiate, but also group, i.e. organize, cloud resources and resources.

If we view a cloud resource as a configuration item in our configuration database (CMDB), the tags are property metadata. For example, we mark whether the system is production or test.

And what are they good for? With tags, we can work with assets in bulk, delete, edit, optimize, assign policies, license, and most importantly, automate. They make our job easier.

A tag always consists of two parts. The first is his name, which we can choose freely. An example is “Environment”. I will write its value to the tag, in this example “Production”. However, if a colleague creates another virtual machine the next day and adds an “Environment” tag with a value of “Production” and another “Env” colleague with a value of “TST”, the tags on the resources will have very little value.

Syntax

The basis for the future arrangement of tags is to determine the syntax and strictly follow it. The syntax should have similar binding rules as the actual assignment of names to resources. Tags and their values are case sensitive and can be passed by various scripts and tools. It is therefore advisable to avoid spaces, diacritics and special characters. The best solution is to have fixed dialsidentical to the configuration database for maximum tags. For example, the environment will be set to “Dev, Test, Pre-prod, Prod“.

Mandatory and optional

Tags can be mandatory, conditionally mandatory and optional.

Mandatory tags, such as object owner, must always be filled in. Their absence can lead to serious problems in service delivery or evaluation.

Mandatory tags are required for proper technical operation, for example to establish a security policy or a backup method.

Optional tags are indicative, replacing, for example, searching for information in the CMDB or other information sources when they can be seen directly in the UI or displayed in the command line. Integrating tagging with a corporate configuration database is generally the preferred option for all larger environments, whether implemented bi-directionally or uni-directionally.

Automatic is better than manual

To ensure the presence of mandatory tags, it is advisable to insert them as variable parameters of scripts in AWS Cloud Formation, ARM templates, Terraform scripts, etc. This will usually provide coverage for all technical data for a given resource or the entire stack.

We also automate the presenceof mandatory tags with tools like AWS Config or through Azure Policy.

The correct approach is to inherit some tags from the resource group. For example, the application or owner name tag is usually common to the entire group. This makes the whole job easier and ensures tag consistency with policies that show compliance status and built-in corrective actions that automatically fill in missing tags from the resource group.

A proper implementation of the ITSM procedure for requesting the creation of a resourceor an entire environment should require that future resources be fully populated in the request or that their properties be copied from an existing environment. The automation process then creates all the tags that are needed for proper organization of resources – business and especially security.

The amount of tags on a single resource is set to about 50 items for both AWS and Azure, so when integrating with a configuration database, you need to map some items carefully and decide if you need all the data in both resources.

Who can and should change?

It is not possible to set a tag as mandatory and leave it blank. This condition, which can create a “rogue” resource, is good to check automatically. Policies also allow the enforcement of tag completion when a resource is created, regardless of how it is created.

When tags are used for security policies, we must ensure that they cannot be changed to circumvent data and application security.

For example, in Azure, tags can be changed by the Tag Contributor role via the API and the Contributor user interface. For example, by restrictively removing rights to change tags, we can prevent developers from changing properties and access to the production environment.

Mass change

In the course of improving the tagging system, it happens that we need to rename a tag or change the whole codebook. Subsequent bulk tag changes can be done in several ways. AWS offers a Tag Editor within the interface, but also a Resource Tagging API. In Azure, we’d reach for Powershell. Prefer to tag across groups of resources in bulk rather than individually. There are also specialised third-party tools such as Tag Manager that expand the range and make tag management more convenient.

Sensitive data

Tags are widely available to other services. Placing a password in the tag can mean that it appears fully readable and available in the billing report as one additional group. For this reason, it is recommended not to place any sensitive data in the tag values.

Similarly, we have to take into account that tags may appear in various reports and exports that we didn’t count on when building them. They may appear in third-party applications that have access to resource data, such as cost-optimization tools like Densify. It is therefore advisable to avoid personal data that is not strictly necessary for the operation, preferring to stick to anonymous identifiers where there is a need to establish a link to a person and their personal data.

Ownership

In a work environment, it is very good to have clear named tresponsibilities for everything. Therefore, one of the fundamental characteristics of each resource is its designated owner – in terms of business, application and infrastructure management. The owner is responsible for the life cycle of the asset.

Types of tags

If we wanted to divide the tags into several types, we could use the usage as a criterion. Simply, we get tags/tags:

Technical
Business
Security
Automation

The division is not limiting. It is an advantage if we can use the same brand for multiple purposes. For example, marking a resource as “Production” correctly in the billing, while applying a security policy to sensitive data, setting up the correct monitoring method, preventing shutdowns during the weekend, and locking down access for deployment and data manipulation to developers.

At the end of this article, we will list the most commonly used tags, but let’s explain their division by function:

Technical tags

Technical tags indicate parameters that relate to technical operation. To which application environment (Environment) and unit (FinancialApps) the resource belongs, whether it is a shared resource between applications (SharedRes), what identifier it has in the configuration database (CMDBKey), which operational team (OpsTeam) takes care of the resource. It is also possible to specify the logging level (LogLevel), backup parameters (BackupType) or monitoring according to the application criticality tag (Criticality, SLA, etc.) and required support (SupportHours).

Business tags

Business tags are not tied to technical operation, but they are metadata important for determining application logic support (for proper cost allocation), for determining the cost center (CostCenter) or business unit (BU), for mapping the application owner (BizOwner), project (OrigProject), migration status (MigrationStatus), etc.

Their main use is grouping and filtering in reporting, the ability to separate reports for individual departments or cost centres, but also in cost management.

These tags are usually identical to the configuration database and it is useful to link them in this way unidirectionally to the cloud resource. Their accuracy is crucial, for example, for cost accounting or finding the owner.

Figure 1 – Tag-based billing: a use case for cost allocation in Microsoft Azure (Source: https://docs.microsoft.com/cs-cz/azure/cost-management-billing/costs/get-started-partners)

Security tags

Security tags allow you to automatically apply security policies over resources, sources, accesses, and the data itself. This is a great weapon, but we need to secure it sufficiently, because by changing the tag we can change accesses and open critical data to unauthorized persons.

Common tags include data criticality (DataSensitivity), data restriction to a given geographic zone (AllowedZone). Also, information on whether and to what level to enable security logging (SecLogLevel) or change auditing (AuditOn). It is also possible to record compliance parameters according to the required standards and to automatically set preventive measures accordingly.

Automation tags

Another group of tags are automation tags that make it easier to manage, integrate, deploy or optimize resources and costs. Their range is very wide, but let’s take a look at the most common ones, which include whether the resource (virtual machine) can be shut down outside working hours (ShutdownAllowed), the start order (StartUpOrderInGroup), whether the resource can be scaled horizontally (AddNodes) or vertically or not at all (FixedResources).

So how to start?

Specify mandatory syntax and value dials.
Start with fewer tags that you can manage and control.
Don’t create “tag hell” from the start with lots of different tags.
Force the creation of mandatory tag values for each automation process.
Take advantage of possible policies and inheritance from groups.
Create a mechanism to verify the presence of mandatory tags and values that do not match the syntax and prevent the creation of “rogue” resources.
Link the tag system to the CMDB at least unilaterally in the first phase.
Develop strategies for technical, safety and development scenarios using tag values.

Detailed information and tutorials for MS Azure can be found here:

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources?tabs=json

And it’s worth checking out Best Practices from AWS: https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf