Increased cloud resources are hard to manage without tags. Tags can be used to manage, group, and search for resources. These resources include personnel, financial costs, and cloud services. This topic describes the best practices for tag design.


Tags are applicable to the following scenarios:

  • Management of application publishing procedures
  • Resource tracking and tag-based group search and management
  • Tag- and group-based automated O&M by using Alibaba Cloud services such as Operation Orchestration Service (OOS), Resource Orchestration Service (ROS), Auto Scaling, and Cloud Assistant
  • Tag-based cost management and cost allocation
  • Resource- or role-based access control


You can implement the best practice for tag design based on the following principles:

Mutual exclusivity

To implement the mutual exclusivity principle, we recommend that an attribute has only a single tag key. For example, if you use the owner tag key to represent the owner attribute, you cannot use other tag keys such as own or belonger to represent this attribute.

Collective exhaustion

Collective exhaustion indicates that when you plan resources, you must plan tags at the same time and prioritize the tag keys. All resources must have tags that consist of the planned tag keys and the corresponding tag values.

  • Each tag key-value pair must be named in a standard format.
  • Collective exhaustion is a prerequisite for future tag-based access control, cost tracking, automated O&M, and group search.

Limited values

This principle indicates that excess tag values must be removed and that only core tag values are retained.

Procedures for resource management, access control, automated O&M, and cost allocation can be simplified by implementing this principle. You can also use tags and automation tools under this principle to manage resources. Elastic Compute Service (ECS) allows you to control tags by calling API operations, which makes it easy to automatically manage, search for, and filter resources.

Considering ramifications of future changes

When you plan tags under the limited values principle, you must consider the impact of adding or removing tag values to improve the flexibility of modifying tags.

If you modify tags, tag-based access control, automated O&M, or related billing reports may change. For corporate or personal business, the best practice is to create business-related tag groups to manage resources in technical, business, and security dimensions. When you use automated O&M tools to manage resources and services, you can add automation-specific tags to aid in automated O&M.

Simplified design

Simplified design means that when you plan tags, you must create tag keys that have fixed dimensions to simplify the use of tag keys. By implementing this principle, you can reduce operation errors caused by redundant tag keys.

  • You can create business-related tag groups to manage resources in technical, business, and security dimensions.
  • When you use automated O&M tools to manage resources and services, you can add automation-specific tags to the resources and services.

Examples of designing tag keys

The following table describes the tag naming examples in the business dimension. We recommend that you use lowercase letters to name tags.

Dimension Tag key Tag value
  • company
  • department
  • organization
  • team
  • group
Organization-specific names
  • product
  • business
  • module
  • service
Business-specific names
  • role
  • user
  • network administrator
  • application administrator
  • system administrator
  • opsuser
  • devuser
  • testuser
  • purpose
  • use
Specific purposes
  • From project dimensions:
    • project
    • risk
    • schedule
    • subtask
    • environment
  • From personnel dimensions:
    • sponsor
    • member
    • decisionmaker or owner
    • creator
Project-related values
Business department (to implement cost allocation and business tracking)
  • costcenter
  • businessunit
  • biz
  • financecontact
Department-related values
Owner from the finance dimension (to identify the resource owner) owner Names or emails
Customers from the finance dimension (to identify the customers that a specific resource group serves) Custom or actual values Customer names
Project from the finance dimension (to identify the projects that are supported by specific resources) project Parameter
Order from the finance dimension order Order category IDs


Related API operations