We frequently are asked out in the field to help customers understand how tags should be used. Many organizations are worried that tags, being inherently unstructured, will cause confusion. As a result, we’ve come up with a structured way of thinking of and applying tags across your subscription. You can use Azure Resource Manager Policy to enforce this tagging philosophy.
What is a tag?
Tags provide a way to logically organize resources with properties that you define. Tags can be applied to resource groups or resources directly. Tags can then be used to select resources or resource groups from the console, web portal, PowerShell, or the API. Tags are also particularly useful when you need to organize resource for billing or management.
Key Info
- You can only apply tags to resources that support Resource Manager operations
- VMs, Virtual Networks and Storage created through the classic deployment model must be re-deployed through Resource Manager to support tagging
- A good way around this is to tage the resource group they belong too instead.
- All ARM resources support tagging
- VMs, Virtual Networks and Storage created through the classic deployment model must be re-deployed through Resource Manager to support tagging
- Each resource or resource group can have a maximum of 15 tags.
- Tags are key/value pairs, name is limited to 512 characters, value is limited to 256 characters
- Tags are free-form text so consistent correct spelling is very important
- Tags defined on Resource Groups exist only on the group object and do not flow down to the resources under them
- Through the relationship you can easily find resource by filtering by tagged resource group
- We recommend keeping the tags to the resource group unless they are resource specific.
- Each tag is automatically added to the subscription-wide taxonomy
- Application or resource specific tags will "pollute" the tag list for the entire subscription.
Best Practices
We think its important for a customer to leverage at least some of the tags in a structured way. Given the limit on number of tags we recommend tagging at the group level. We don't feel there is currently a need to set them on the resources as you can easily trace down from the Resource Group.
Primarily we recommend a Service/Application/Environment hierarchy along with an environment type, and a billing identifier be reflected in the tags. To do this we recommend spending the time to define an Application hierarchy that spans everything in your subscription. This hierarchy is a key component to both management and billing and allows you to organize the resource groups logically. Its also important that this hierarchy contain additional metadata about the application, like its importance to the organization and the contact in case there is some issue. By storing this outside the tag, say in a traditional CMDB structure, you cut down on the number of tags you need to use and the complexity of tag enforcement, and reduce the risk of tag drift.
Once a taxonomy is agreed on, create the tags for Service/Application and Environment and set them on each Resource Group. Then set a tag for Environment Type to Dev, Test, Production to allow you to target all Dev, all test, or all production later in policy and thru automation.
For the billing identifier, we recommend some type of internal charge code or order number that corresponds to a General Ledger (GL) line item to bill that resource group's usage to. Just these few tags would enable you to determine billing usage for VMs running in production for the finance department.
There are several ways to retrieve billing information and the corresponding tags. More information can be found here: https://azure.microsoft.com/en-us/documentation/articles/resource-group-using-tags/#tags-and-billing
Recommended Tags
To be prescriptive, we recommend these tags be set on each resource group:
|
Tag Name
|
State
|
Description
|
Tag Value
|
Example
|
|---|---|---|---|---|
| AppTaxonomy | Required | Provides information on who owns the resource group and what purpose it serves within their application | Org\App\Environment |
USOPS\Finance\Payroll\PayrollTestEnv1
|
| MaintenanceWindow | Optional | Provides a window during which patch and other impacting maintenance can be performed | Window in UTC "day:hour:minute-day:hour:minute" | Tue:04:00-Tue:04:30 |
| EnvironmentType | Required | Provides information on what the resource group is used for (useful for maintenance, policy enforcement, chargeback, etc.) | Dev, Test, UAT, Prod | Test |
| BillingIdentifier | Required | Provides a charge code or cost center to attribute the bill for the resources too | Costcenter | 34821 |
| ExpirationDate | Optional | Provides a date when the environment is expected to be removed by so that reporting can be done to confirm if an environment is still needed | Expiration Date in UTC | 2016-06-15T00:0 |
Over time we’ll have additional posts, scripts and other items that will build on this tagging structure.
New! You may find this post with a PowerShell script useful for reporting on resource group tags