Optimize your Tagging Policy

A well-governed tagging practice is a fundamental capability of every cloud governance initiative. Amongst others, it enables use cases like ownership, spend showback, cloud security management, and much more.


Learn more

There is a variety of available resources where you can learn more on why & how to implement a Cloud Tagging strategy:

Concrete suggestions for AWS, Azure and GCP can be found below.

Despite the fact that there are well-established best practices, many companies still struggle amongst the following topics:

  • It takes time to get a policy right in the first place
  • Adherence to a policy is hard to measure & optimize, especially in a multi-cloud / multi-account scenario
  • Developers & business stakeholders are often not aware of the policies in place, which often creates friction with the Cloud Center of Excellence.

Instead of enforcing a variety of tags technically - and hence seriously impacting the developer experience - successful companies excel in educating development teams on the policies and caused violations, enabling them to address tags consistently in their Infrastructure as Code (IaC) environments



Infrastructure as Code is well-established in modern IT Organizations as part of a DevOps toolset and culture. There are various good introductions available online, e.g. from IBM, also make sure to check our intro to Site Reliability Engineering which gives a bigger picture on modern software development

Define your Tagging Policy

A Tagging Policy in LeanIX Cloud Intelligence is defined in two steps:

  1. The Policy Fact Sheet is used to capture ownership & context. It entails a clear understandable name & a categorization (business driver). It is recommended to define your own Subscription Roles (e.g. Policy Owner) in order to express ownership and responsibility in the way how it's established in your organization.

  2. The Policy is linked to one or more Violation Type Fact Sheets. A Violation Type contains:

  • Category to group it next to other violation sources (like AWS Trusted Advisor)
  • Criticality (high / medium / low) to inform account & business owners about severity
  • Scope for which this Violation Type applies (e.g. all EC2 instances, all cloud components in a specific Azure Subscription)
  • Rule allowing you to match the cloud tag (e.g. Environment) to expected values (like non-empty, numeric, email address, selection list)


Best Practice

AWS, Azure and GCP have different technical restrictions (e.g. GCP does not allow upper case for tags). If possible, define a policy that is supported by all hyperscalers, e.g. instead of choosing applicationName for AWS and application_name for GCP, stick with the latter across hyperscalers.

Publish it to the entire organisation

There are various ways to publish the established tagging policies into your organization - see https://docs-ci.leanix.net/docs/publish-information. Often, a Policy Portal is a very simple way to inform technical & business stakeholders, without the need to give them a full introduction to Cloud Intelligence.

Bring Violations to Account & Business Owners

Once Policies & Violation Types are setup, the Violation Table at the Cloud Account & Business Context Fact Sheet provide always up-to-date information about the context specific violation, with a flexible grouping e.g. by environment or criticality.



Getting the Violations to the Cloud Account & Business Context Fact Sheet is only the first step. We are actively looking into topics like providing API access, triggering notifications into Slack or Microsoft Teams, creating JIRA tickets, or generating IaC Templates in order to simplify mitigation. Get in touch via [email protected] to learn more.

Consistently report on adherence

Dashboards provide very flexible way to report the adherence to tagging over time, also utilizing LeanIX Metrics - see https://docs-ci.leanix.net/docs/publish-information

Tagging Basics: Azure

You can apply tags to Azure resources in order to help with resource management, cost management, automation, etc., see https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/decision-guides/resource-tagging/?toc=/azure/azure-resource-manager/management/toc.json and https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources?tabs=json.

Each tag is a key-value pair.

  • Tag keys are case-insensitive.
  • Tag values are case-sensitive.


department:One == Department:One

department:One != department:one

To rename a tag key to fix casing, use this workaround:

Department:One -> department1:One -> department:One

Each resource can have a maximum of 50 tags.

You can use Azure Policy to ensure compliance of tagging rules, see https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/tag-policies.

Tagging Basics: AWS

You can add tags to AWS resources in order to help with resource organization, cost allocation, automation, access control, etc., see https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html.

Each tag is a key-value pair.
Both tag keys and values are case-sensitive.


department:One != Department:One

department:One != department:one

You cannot rename a tag key, but you can add a new tag with the new key and delete the old tag with the old key.

Each resource can have a maximum of 50 tags.

You can use AWS Resource Groups Tag Editor to find resources and to edit tags for a number of resources, see https://docs.aws.amazon.com/ARG/latest/userguide/tag-editor.html.

You can use AWS-generated and user-defined Cost Allocation Tags to assign costs to groups of AWS resouces, see https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html.

You can use AWS Config Rules to create notifications when a resource is not compliant with your tagging policy, see https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html.

Tagging Basics: GCP

You can attach labels to Google Cloud resources in order to help with resource organization, cost allocation, etc., see https://cloud.google.com/resource-manager/docs/creating-managing-labels.

Each label is a key-value pair.

Label keys and values can contain only lowercase letters, numeric characters, underscores, and dashes.

Each resource can have a maximum of 64 labels.

You can attach tags to Google Cloud organizations, folders and projects in order to help with resource organization, access control, etc., see https://cloud.google.com/resource-manager/docs/tags/tags-overview and https://cloud.google.com/resource-manager/docs/tags/tags-creating-and-managing.

Did this page help you?