Tag policy is a strategy used to help enterprises improve tag standardization. Through tag policy, enterprises can restrict resources to bind tags. After completing tag standardization management, it can improve the management efficiency of enterprises in scenarios such as tag billing, tag authentication, and automated operation and maintenance.
Tag policy supports two modes: Single Account and Multiple Accounts. Enterprises can use it according to their own situation, which can meet the needs of standardized control of tags at different stages. Multi-account is based on group account system. See TCO Tag Policy.
Note:
Tag Policy has been launched for public beta across the network. If you have any suggestions when using this service, please feel free to give feedback and submit Online Tickets.
Advantages
The usage scenarios and value of Tag Policy are mainly reflected in the following aspects:
Organizational Resources: By assigning Tags to Sub-users in the Tag Policy, Sub-users can manage and organize resources more easily and improve Tag Accuracy. For example, if it is agreed in the Tag Policy that Sub-users need to bind Tags such as "project: project1" and "department: Technical Department 1", then if the Sub-user binds the wrong Tag, it can be repaired according to the policy to better comply with the company's internal Tag standards.
Cost Allocation: Tag Policy can help users better track and analyze the usage cost of resources. Tag Policy assists Sub-users in binding and repairing accurate Tags. By enabling Settlement Tag, you can view the fees for each resource in the Billing Center's invoice, so as to better understand the resource consumption of each project or department.
Security and Compliance: Tag Policy can help users better implement access control and compliance management of resources. For example, you use Tag authorization to restrict users to access only resources with specific Tags, but if the Sub-user binds the wrong Tag, the authorization scope changes accordingly. However, Tag Policy helps repair, thereby ensuring the security of resources.
Automation: Tag Policy can choose whether to automatically repair, which can be used together with CAM - Support Only Match Tag Key When Authorizing by Tag to realize automatic management of resources. For example, in the CAM policy, it is required that a sub-user must bind a certain type of tag when performing a specific operation, and then through the tag policy, if the sub-user modifies the tag incorrectly, it will be automatically repaired. You can choose auto-fill. For example, every time you create a resource, you need to bind 4 tags, which can reduce the cumbersome process of sub-users entering tags.
Use Limits
Type | Default upper limit | Processing Rules when Exceeded upper limit | Whether to support Enhancement | Enhancement Method |
Quantity of Tag Policies under a Single Root Account | Maximum value 100 | Saving is not allowed when creating a Tag Policy | Supported | |
Quantity of Tag Policies that can be Bound to a Single Master and Sub-account User | Maximum value 10 Pieces | Binding Tag Policy to Users is Not Allowed | Not supported. | - |
Quantity of Tag Keys in Valid Policies | Maximum value 50 | Tag keys that exceed the limit when generating effective policies will not be merged | Not supported. | - |
Maximum Character Count for a Single Tag Policy | Maximum value 4096 characters | Saving is not allowed when the characters are exceeded | Supported | Supports separate enhancement for master and sub-accounts |
Supports Resource Types
Supported Scenarios
Scenarios currently supported by Tag Policy:
Feature Name | Results before setting | Results after setting |
The effective range of Tag Policy can be selected freely | No policies, each user binds Tag by himself | 1. When binding to the root account, it can take effect on the root account 2. When binding to a certain sub-user, it can take effect on the sub-user alone 3. You can batch bind some sub-users as needed |
Automatic repair scenario | User settings are incorrect and not easy to find. You can only perform manual modifications after self-inspection | For existing resources that are not bound to a tag, if a sub-user adds a tag but it is inconsistent with the constraints in the tag policy, automatic repair can be supported |
Automatic Assignment Scenario | Users need to input, search, select, and remember which key-values to bind for each tag | For creating or editing tags for resources, if the system can help sub-users display the tag key or tag value by default, it can reduce the operation steps for sub-users or avoid omissions |
Forced Interception Scenario | User settings are incorrect and not noticed, need to be corrected after discovery | For editing tags for existing resources, if the key-value does not meet the constraints in the tag policies, the binding will be intercepted. For example, if a sub-user is required to bind Product: Product A , but the sub-user edits it to Product: Product B , it will be intercepted |
Tag policies Key-Value Restrict | Users need to search within the full key-values to find | After this feature is enabled, when setting the tag key for resources, the effective policy key will be displayed first. When setting the tag value, only the values agreed by the tag key in the effective policy can be selected, and all tag values cannot be selected. Including creating new resources or editing existing resources. |