Getting Azure tagging fundamentals right


Tagging is a convenient way to organize resources and manage workloads in Microsoft Azure. While it can be a helpful tool, tagging has its limits and special quirks that must be addressed.

What is Azure tagging? It permits you to take resources that have a logical connection, such as their lifetime allocation, and assign metadata to link them together. Doing so allows you to track, at a higher level, entities such as lifetime and billing information.

A tag is simply a name/value pair. For example, you can assign the name “Environment” and the value “Development“ to all the resources in the development environment to track development spending or resource allocation during development.

Each resource or resource group can have a maximum of 15 tag name/value pairs. This limitation applies only to tags directly applied to the resource group or resource. That means you can, in turn, have additional resources that each can have up to the maximum name/value pairs.

It is important to understand that setting a tag on a resource group does NOT filter down to its resources. But when creating resource (such as a VM) you can select all/some of its resources to use the same name via a drop-down list box (NSG, IP, Availability set, network interface, etc.).

There is a fundamental difference between the usage of resource groups and tags.

  • In the Azure Resource Manager (ARM) model, resource groups provide a functionality to group together resources that share the same lifecycle. That means they typically are allocated and released in the same cycle. Resource groups provide a tightly coupled container structure to manage your resources, starting from provisioning to lifecycle management. For instance, you can delete an entire set of commonly grouped resources by just deleting their resource group.
  • By contrast, tags are a loosely coupled form of grouping. They can be associated with resources from multiple resource groups. You can associate the same tag with any resource within the scope of one subscription to make management and visibility easier. Tags do not have scope outside of their subscription.
  • After you apply tags, you can view all the resources in your subscription with that tag name and value. Loosely coupled tags enable you to retrieve related resources from across different tightly coupled resource groups. This approach is helpful when you need to organize resources for billing or management.

Here are a few of the field restrictions around tagging.

  • The tag name is typically limited to 512 characters, and the tag value itself is limited to 256 characters.

Some fields have slightly different limits on tagging, such as:

  • For storage accounts, the tag name is limited to 128 characters, and the tag value is limited to 256 characters.
  • Virtual machines are limited to a total of 2048 characters for all tag names and values.

Tags can’t be applied to classic resources provisioned under the ASM (Azure Service Management) model. Only resources that have been deployed using the newer Azure Resource Manager (ARM) model will be able to use tagging.

There are some special characters that are NOT allowed in tag names: %,?, &, \,  /, < and >.

Write access is required to connect a tag with a resource:

  • To apply tags to all resource types, use the Contributor
  • To apply tags to only one resource type, use the contributor role for that specific resource. For example, to apply tags to virtual machines, use the Virtual Machine Contributor

An example of using tags is to sort your resources in the Azure portal to get a quick view of all the resources that come under your Development, QA, and Production environments.  Here’s how you may possibly carry out such a search:

  • Search bar type in “tag” and select “Services / Tags”
  • Click the tag of “Environment” with the Value set to “Development”
  • Shows all the resources tagged with this name value pair. If you had other environments, such as Pre-Prod or Prod or Test, you would see those as well.
  • Click on a resource and view its tag field.

There are many types of policies in Azure that enable you to maintain standards across your resources and ensure they stay compliant. This can occur at initial provisioning, such as ensuring no virtual machines (VMs) are allocated outside of a certain range of VMs to manage your costs. And when a policy is implemented, existing resources are flagged that violate its rules.

Here we will focus on Azure policies to enforce corporate governance over your Azure resources around tagging. You can use a built-in Azure tagging policy so if a resource is deployed and does not have a tag and associated value, Azure will apply a default tag/value to the resource. This helps you maintain compliance over the naming of all provisioned resources to comply with governance requirements.

There are built-in tagging policy definitions you can use to ensure you maintain a uniform naming compliance.

Enforce tag and its value

– Enforces a required tag and its value. Does not apply to resource groups.

Apply tag and its default value

– Applies a required tag and its default value if it is not specified by the user. Does not apply to resource groups.

Apply tag and its default value to resource groups

– Applies a required tag and its default value to one or more resource groups if it is not specified by the user.

Enforce tag and its value on resource groups

– Enforces a required tag and its value on one or more resource groups.

There is one policy effect that dictates what happens when a policy is evaluates to a match. If the resource is existing or new, or even recently changed, the effects behave differently. Here are the effects that are supported in a policy definition. Effects are evaluated in an ordered precedence process.

  1. Disabled – Decide if the policy rule should be evaluated or not.
  2. Append – Add additional fields to a resource when it is updated such as a specific runtime value that is not available at creation time.
  3. Deny – This is used when a request does not meet defined policy definition and thus the resource allocation request fails.
  4. Audit – This logs the request before it does to the resource provider. It a non-compliant resource is evaluated a warning event is logged in the actively log but does not stop the request. Deny would have done that if needed before Audit was evaluated.
  5. If a Resource Provider returns a success code, AuditIfNotExists and DeployIfNotExists are evaluated to determine if additional action or logging must occur.

Any requests to Azure Resource Manager are evaluated by the applied policy first. The policy will first take a resource and create a list of all applicable assignments that apply to it.  Several of the effects are evaluated before handing the modification or creation request to the specific resource provider. This avoids having to contact the resource provider when a given resource to be allocated or change does not conform to a policy.

For more information on Azure Policies, refer to:

For more information on how to assign a policy in the Azure portal, refer to:

Mike-McKeown-headshotMike McKeown is an Azure solutions architect for DXC Technology and is a member of the DXC Azure Center of Excellence team. Mike spent 20+ years with Microsoft and has been working with Azure since 2011. He published a book on Azure Automation (MS Press), developed four Azure courses with Pluralsight, written a number of whitepapers and articles for MSDN, and has spoken at many conferences about Azure. Connect with Mike on LinkedIn.

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.