Welcome to Data
#3’s five-part series focusing on the detail outlined in
our recent blog, which covers our top five tips for the long-term success for Microsoft Azure-hosted infrastructure in your organisation. Data
#3 have delivered over 100 Azure Health Checks for customers in the past two years and consistently have found the
same problems.
This episode is all about tagging and how you can benefit in many ways by appropriately tagging your resources. It covers both technical and organisation benefits for tagging, and this is a must-read for all audiences.
What is Tagging?
Tagging in the context of Azure is the application of metadata to each resource to identify essential information that will assist with long-term operational and management excellence. Nearly every resource type in Azure supports tagging, and Microsoft provides a detailed list on all the resource types that support tags.
Critical information for tags:
- To date, the maximum number of tags supported for resources is 50, with the support to extend this limit by chaining multiple tags in a single JSON string.
- Tag key (the name of the tag) is limited to 512 characters, with the value supporting 256 characters.
- Azure Service Management (ASM) or Classic resources do not support tagging at the resource level; however, a workaround exists where the resource group containing the resources can be tagged.
Special note; although a workaround is available, if you have classic resources in your environment, you should talk to us about migrating those resources to the modern Azure Resource Manager deployment model.
- You cannot use the following characters in either the tag Key or Value: < > % $ ? / (also, certain resource types such as Traffic Manager and DNS zones do not support a space).
- Generally these limitations are not a major concern when we effectively apply tags, as simplicity is key.
I recommend using a basic schema for tags and then extending the schema depending on service usage and advanced functionality/reporting requirements. If you over-complicate your schema from the outset, then you may encounter operations fatigue while deploying and maintaining tags.
How do I benefit from Tagging?
Different roles within the organisation greatly benefit from tagging from different perspectives. Below are some examples:
- Finance team – Tags allow for fine-grained cost control, forecasting and accountability. A well designed and applied tag schema allows your finance team to accurately cross charge individuals, departments, sub-organisations and project future costs for different workloads.
- Operations team – This team will benefit the most from a well-defined tag schema, creating priority alerts based on the business system. Its status using the ITIL framework is also an essential requirement to maintain systems. With detailed tags, we can apply different ITSM priorities based on the system. Accountability also factors in with this team. Questions like ‘what is this?’ ‘who built it?’ and ‘whom do we notify for an outage?’, are easily answered by looking at the tag metadata for the affected system.
- Projects team – This is the essential team that generally builds the systems in Azure, often starting with prototype, test and development versions of a system before deploying in a production capacity. Tagging with this team is critical as here is the potential for runaway cost and orphaned resources.
But doesn’t tagging add effort?
Correct. However, the measure of the effort to apply tags during deployment is dramatically less than the effort required to manage a resource that is not tagged. If we are using programmatic deployment methods, then tags can be applied during creation. We are only adding seconds to a deployment and minutes to the thought process for pre-deployment. Compare that to hours of investigation and manual filtering of consumption information to break down cost or attribute a resource to an owner, for example.
Most resource types support tagging on creation within the Azure portal now as per the create Virtual Machine process below.
So how should I tag resources?
First, ask what future questions you would like to negate from an audit, cost management, accountability, ownership and incident management perspective. Below is the suggested minimum standard, which should be used as a baseline. Applying these tags greatly enhances your cost management and overall accountability, as well as your change management capability.
- Who built it?
- Who owns it?
- Who is going to pay for it?
- What is its purpose?
- What is its status?
After you define the questions you want to negate, then design the schema choosing a global standard of Keys and the type of data that should be used for Values. An example based on the above would be:
