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

Tagging resources in the cloud seems like the simplest discipline. The cloud doesn't tie us down - 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, properly Czech tags, are labels, signs or if you want stickers, which we use to label our cloud resources. We label our virtual machines, databases, virtual networks, load balancers, we label everything. Tags help us to differentiate, but also to group, i.e. Organize, cloud resources and resources.

If we view the cloud resource as a configuration item in our configuration database (CMDB), the tags are metadata characteristics. 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 its Namewhich we can choose freely. An example is "Environment". I'll write the tag's value, in this example "Production". However, if a colleague creates another virtual machine the next day and adds the tag "Environment" with the value "Production" and another colleague "Env" with the value "TST", the tags on the resources will have very little value.

Syntax

The basis for the future arrangement of tags is the syntax and its strict adherence. The syntax should have similar binding rules as the actual assignment of names to resources. Tags and their values are case sensitive, 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 maximum tags fixed dials identical to the configuration database. For example, the environment will be set to "Dev, Test, Pre-sale, Prod".

Compulsory and optional

Tags can be mandatory, conditionally mandatory and optional.

Required tags, such as object owner, must always be filled in. Their absence can lead to serious problems in the provision of services or in their evaluation.

Conditionally required tags are needed for proper technical operation, for example to determine security policy or backup methods.

Optional tags are indicative, replacing, for example, searching for information in CMDB or other sources of information, when they can be seen directly in the UI or displayed in the command line. Integrating tagging with an enterprise configuration database is generally the preferred option for all larger environments, whether it is 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 variables script parameters v 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.

The same automated further checking the presence of mandatory tags by tools such as AWS Config or through Azure Policy.

The right approach is inheritance some tags from the group of means (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 remedies that automatically fill in missing tags from the resource group.

With the correct implementation of the ITSM procedure in requests for the creation of a resource or the entire environment should be required to fully populate the future resources in the application or copy their properties from an existing environment. The automation process will then create all the tags that are needed for proper organization of the resources - business and especially security.

Number of tags on a single resource is set to approximately 50 items for both AWS and Azure, so when integrating with a configuration database, we need to carefully map some items and decide if we need all the data in both sources.

Who can and should change?

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

If we use tags for security policies, we need to ensure that changing them cannot achieve circumventing security data and applications.

For example, in Azure, tags can change roles Tag Contributor via API and Contributor via the user interface. For example, by restrictively removing the 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 entire dial. Subsequent bulk tag changes can be done in several ways. AWS offers Tag Editor within the interface, but also Resource Tagging API. In Azure, we would reach for Powershell. It is better to mark across groups of resources in bulk rather than individually. There are also specialised third party tools such as Tag Managerthat expand the offer and make tag management more convenient.

Sensitive data

Tags are widely available to other services. Placing a password in a 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 in tag values no sensitive data.

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 can appear in third-party applications that have access to resource data, such as cost-optimization tools like Densify. It is therefore advisable avoid personal datathat are 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's very good to have a clear naming convention for everything responsibility. 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 resource.

Types of tags

If we wanted to divide the tags into several types, we could use the usage as a criterion. Simply put, 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, the "Production" label will correctly classify a resource in the billing, while applying a security policy to sensitive data, setting up the correct monitoring method, preventing shutdowns during the weekend, and locking out developers from deployment and data manipulation access.

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 the technical traffic. To which application environment (Environment) and the whole (FinancialApps) the resource belongs to, whether it is a shared resource between applications (SharedRes), what identifier it has in the configuration database (CMDBKey), which the operations team (OpsTeam) takes care of the middle. It is also possible to specify the logging level (LogLevel), backup parameters (BackupType) or monitoring by the application criticality tag (Criticality, SLA, etc.) and the necessary support (SupportHours).

Business tags

Business tags are not tied to technical operation, but 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), the 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 correctness is crucial, for example, for cost accounting or owner discovery.

Security tags

Security tags allow you to automatically apply security policies over resources, sources, access and the data itself. This is a great weapon, but one that must be sufficiently secured, as by changing the tag we can achieve a change of access and open critical data to unauthorized persons.

Common tags include a data criticality flag (DataSensitivity), their limitation to a given geographical 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 according to them.

Automation tags

Another group of tags are automation tags that facilitate report, integration, deployment or optimization of resources and costs. The range of these is very wide, but let's list the most common ones, which include whether a resource (virtual machine) can be shut down outside of business hours (ShutdownAllowed), starting order (StartUpOrderInGroup), whether the resource can be scaled horizontally (AddNodes) or vertically or not at all (FixedResources).

So how to start?

1. Specify mandatory syntax and value dials.
2. Start with fewer tags that you can manage and control.
3. Don't create "tag hell" from the start with a multitude of different tags.
4. For each automation process, force the creation of mandatory tag values.
5. Take advantage of possible policies and inheritance from groups.
6. 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.
7. Link the tag system to the CMDB at least unilaterally in the first phase.
8. Develop strategies for technical, safety and development scenarios using tag values.

You can view detailed information and tutorials for MS Azure here:

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

And from AWS, it's worth reviewing Best Practices: https://d1.awsstatic.com/whitepapers/aws-tagging-best-practices.pdf

And finally, from our experience:

The 10 most commonly used tag information:

• Environment
• Owner
• Application
• Cargo centre
• SLA
• Project
• OPS Team
• Risk Level
• Logging in
• Scheduling