Best practices for using Tags (Playbook)

1 – Objective #

The goal of this Playbook is to present best practices for using tags in IT resources , focusing on governance, cost traceability, security, and compliance. Furthermore, a very special objective of this playbook is to serve as a didactic guide on the use of metadata for FinOps.

2 – Scope #

This playbook applies to all types of metadata, although it uses the term “tag,” which may initially suggest the Azure ecosystem. However, the content can also be used in on-premises environments and other clouds such as AWS, GCP, and Huawei.

3 – Benefits of using Tags #

3.1 – Cost Visibility and Traceability #

Tags allow you to directly associate IT resources with applications, business areas, and cost centers. This makes it possible to identify who is consuming the resources and how much is being consumed. This benefit ensures the correct distribution of costs among those responsible.

3.2 – Governance and Information Security #

Tags contribute to greater control and visibility over the resource lifecycle. They can be used to reinforce information security, reducing the risk of exposure and identifying all resources that may have been affected by a cyberattack.

3.3 – Process Automation #

Several automations use tags as triggers, automating tasks such as server start/stop, data storage lifecycle, resource monitoring, and scalability. This is a strategy that reduces operational costs and ensures process standardization.

3.4 – Support for audits and compliance #

Organizations are subject to specific regulations and standards, such as LGPD, ISO, and similar standards. Tags offer direct support for classifying auditable or compliance-required resources, facilitating traceability and consistency in report creation. Examples follow below:

• Data classification : {Compliance: LGPD}
• Resource criticality : {Compliance:Confidential}
• Compliance status : {Compliance:Auditing}

This type of tag allows audits to be carried out more quickly.

3.5 – Resource Organization #

In complex environments, which can encompass multiple clouds, regions, and projects, the application of tags ensures a logical organizational structure that goes beyond the native groupings of each provider. This simplifies the location, categorization, and management of assets, as well as reducing waste from orphaned or duplicate resources.

4 – Naming Conventions and Standards #

Adopting naming conventions for tags and their values ​​is fundamental to ensuring consistency, reliability, and traceability in resource classification. Without standardization, tags lose value, as small spelling or semantic variations can lead to data fragmentation and render FinOps, compliance, or security reports unusable.

Recommendations: #

• Consistency : Keys and values ​​need to be documented and standardized to avoid variations. Example: Application ≠ APPLICATION ≠ application
• Clarity : the keys and values ​​need to be easily identifiable for all teams.
• Conventions : Tags must adopt a uniform form and a standard language. It is recommended to use an initial capital letter or CamelCase, without spaces, special characters, or accents.
• Proper granularity : tags need to be audited frequently to ensure full adoption.
• Organizational scope : The naming convention needs to be applicable across all areas, environments, and cloud providers. A corporate catalog of valid tags needs to be established.
• Automation : Higher levels of maturity will require the use of scripts, tools, policies, and pipelines to validate the adopted standards.

Basic tag template #

A good practice is to require tags only for essential metadata, and for this, a recommended standard would use the following tags:

• Environment : Differentiate the costs of production, development, and homologation.
• Application : Identify the application to which the resources belong.
• Owner : Identify the person or team that should be accountable for the resource.
• Cost Center : the department within the organization where costs should be allocated.
• Compliance : identifying specific regulatory requirements, standards, or classifications that a given resource must follow.

Note : By adopting a hybrid governance model, we can replace the Environment and CostCenter tags with one of the account hierarchy components.

5 – Procedures for Applying Tags #

5.1 – Layers complementary to Tag-based governance #

Tags are mutable and not supported by all resource types. Therefore, they should be viewed as a complement to native cloud and traditional IT governance structures, not replacements.

Account hierarchies allow you to build a successful cost allocation strategy, making use of the logical groupings below.

5.1.1 – Subscriptions / Accounts / Tenants

It can be used to separate environments, such as production, development, and testing. In the case of holding companies composed of diverse businesses, it is recommended that each company have its own subscriptions.

5.1.2 – Resource Groups / Projects / Folders

Create logical groupings that make sense within each company’s internal organization, potentially representing different environments if there’s no subscription-based separation. They can also be used to organize specific resources for certain applications.

5.1.3 – Management Groups / Organizations / Hierarchias

Use this to define centralized compliance, cost, and security policies for multiple subscriptions belonging to a specific business unit or organization.

5.1.4 – Naming Conventions

Resource naming conventions that are clear, consistent, and mandatory for all resources.

5.2 – Hybrid Governance Model #

Considering the complementary layers of governance listed above, we can say that the ideal governance model is not one that adopts tags as its main tool, but rather one that makes the ideal combination between:

• Strong and well-planned account hierarchies (RGs, Subscriptions, Management Groups, etc.) . The way the infrastructure is organized will form the first strategic layer of cost allocation, allowing for the isolation of costs by environment or application.
• A clear and consistent naming convention , applied to all resources, should be implemented. The organization should be encouraged to have a well-defined naming standard and processes to ensure that it is strictly followed.
• Complementary tags , for granularity, financial reporting (FinOps), automation, and specific use cases (audit, compliance). Tags help to route existing expenses to their respective responsible parties.

Thus, even if a tag is missing, basic categorization through logical grouping still exists. If the resource does not accept tags, it still belongs to a structure that provides context; and, if an audit requires traceability, it will be possible to cross-reference all the above data to ensure consistency in the information provided.

5.3 – Tag Inheritance #

An effective way to ensure that as many resources as possible are tagged is to use tag replication from a parent resource to its child resources, such as in the case of backups and disks attached to a specific server. Some providers, such as Azure, allow tag inheritance at the Resource Group level, ensuring that all resources created within that group receive the same tags.

5.4 – Tagging Policies #

To ensure that required tags are declared for resources that will be created, the cloud administrator can create policies that prevent the creation of new resources without the required tag keys and/or values.

If a user attempts to create a non-compliant resource, a Deny policy will prevent the creation of the new artifact in the environment, notifying the user to adjust the tags before attempting deployment again.

6 – Governance and Responsibilities (RACI) #

7 – Compliance Checklist #

The checklist below should be used periodically by the Governance, FinOps, Infrastructure, and Audit teams to ensure that the use of tags is consistent, up-to-date, and adheres to the defined policies.

7.1 – Structure and Patterns #

• There is an official catalog of tags that is defined and documented.
• All tags have a standardized key in accordance with established conventions.
• The values ​​follow the agreed standards (controlled lists, date formats, identifiers).
• The catalog is periodically reviewed to reflect changes in business, governance, and compliance.

7.2 – Application and Coverage #

• All critical resources have the required tags applied.
• There is a minimum coverage (%) of tagged resources defined (e.g., 95%).
• Resources that do not support tags are properly mapped and compensated for by other strategies (e.g., synthetic tags, naming conventions, logical groupings).
• Newly created resources receive tags at the time of creation (automation or blocking policy).

7.3 – Governance and Consistency #

• Tags do not have inconsistent values ​​(e.g., “Production”, “Prod”, “PRD”).
• Critical tags (e.g., Owner, Cost Center, Compliance) are validated periodically .
• There is a process for correcting invalid or missing tags (alerts, automation, runbooks).
• There is clarity regarding who is responsible for each tag (according to the RACI matrix).

7.4 – Use and Integration #

• Tags are used for reliable cost allocation (FinOps) .
• Tags are integrated with security policies (e.g., encryption control, critical environments).
• Tags are used in process automation (e.g., automatic shutdown of non-productive VMs, backups, scalability).
• Tags are integrated into audit and compliance reports .

7.5 – Auditing and Monitoring #

• There are periodic tag compliance reports (monthly, quarterly).
• Coverage gaps or inconsistencies are monitored and reported .
• External or internal audits can cross-reference information across tags, hierarchies, and naming conventions.
• There is an action plan in place to reduce deviations when they are identified.
• Tags are used to identify resources that need to meet regulatory and compliance standards.

8 – Support Tools #

Efficient tag management depends not only on policies and processes, but also on tools that facilitate their application, monitoring, auditing, and automation . Below are examples of tools that can support the process:

8.1 – Native Cloud Tools #

8.1.1 – Azure

• Azure Policy : allows you to create rules to enforce or correct tags on resources and resource groups.
• Azure Cost Management + Power BI : tag-based cost reports.
• Azure Resource Graph : queries to identify resources without tags or with invalid tags.

8.1.2 – AWS

• AWS Tag Editor : a tool for viewing and managing tags across multiple services.
• AWS Organizations + Service Control Policies : Apply centralized governance policies.
• AWS Cost Explorer / CUR : tag-based financial reports.

8.1.3 – Google Cloud (GCP)

• Resource Manager Labels : equivalent to tags for organizing resources.
• Billing Reports : allows you to filter costs by labels.
• Policy Controller : Validation of metadata policies in clusters.

8.1.4 – Huawei Cloud

• Tag Management Service (TMS) : allows you to create, manage, and apply tags across multiple services.
• Cost Center : cost reports filtered by tags.

8.2 – Automation and Data Analysis #

• Infrastructure as Code (IaC): Terraform, Bicep, ARM Templates, CloudFormation → allow you to define tags during provisioning.
• Scripting & Automation: PowerShell / Azure CLI / AWS CLI allow you to create scripts for tag validation and correction.
• Python (Pandas) : analyzing billing files to reconstruct missing tags based on naming conventions or business rules.
• Monitoring & Alerts: Grafana / Prometheus for creating dashboards that show tag coverage. Azure Monitor / AWS CloudWatch / GCP Operations for generating alerts for non-compliant resources.

9 – Limitations of Tags and Governance Supplement #

Although tags are a crucial strategy for classifying and organizing resources, it’s always necessary to consider:

9.1 – Not all resources support tags. #

Some resources may not allow the use of metadata. Therefore, the user should consider whether critical criteria for classification or cost allocation should be linked to a specific tag, since in practice not all resources will be able to use them.

Therefore, there will be a total of untagged expenses that will need to be audited through data analysis. In order to minimize this scenario, we can consider the following recommendations:

9.1.1 – First recommendation: Adopt a tool that allows the application of Synthetic Tags:

Cost management tools, such as Cloud8, for example, allow the use of Synthetic Tags. This feature allows the platform to manage agnostic tags within its own workload, applying them even to resources that cannot natively be tagged.

This strategy also has the advantage of allowing the unified management of metadata from various different service providers.

9.1.2 – Second recommendation: Logical Grouping Tags

Some cloud providers allow tagging in logical groupings. Azure, for example, allows the application of tags to resource groups.

Therefore, an effective strategy for dealing with resources that cannot be tagged in environments where groupings have failed to adopt Naming Conventions is to apply metadata to them. This makes it possible to mitigate the impacts of non-compliance with the naming standard, as well as identify the costs of resources that do not allow native tagging.

9.1.3 – Data Analysis based on billing files

Using data analysis libraries, such as Pandas (Python), it is possible to create scripts with rules for populating the Tags column using the organization’s own naming conventions and other business rules.

9.2 – Metadata is not immutable. #

Tags can be manually altered or inadvertently removed, which can compromise their reliability if there is no proper automation and governance.

9.3 – Exclusive reliance on Tags creates risk #

If all categorization of compliance, security, or costs is solely based on tags, consistency is lost when those tags are missing or applied incorrectly.