Tagging is a feature that has been introduced into the Azure Resource Manager model (ARM). They can be used to Logically group and track resources. The old (Classic) version of Azure was Azure Service Manager.
Azure tagging can be done using Azure Portal, Azure Powershell, CLI (Command Line User Interface) or ARM (Azure Resource Manager) JSON templates
Tags can then be used to select resources or Resource Groups and are useful when you need to organize resources for billing or management
You apply tags to your Azure resources giving metadata to logically organize them into a taxonomy.
Each tag consists of a name and a value pair. For example, you can apply the name “Environment” and the value “Production” to all the resources in production.
- 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 tag the resource group they belong to instead.
- All ARM resources 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 Its recommended 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.
Issues with Tags
Using the recommended Tag procedure of tagging at resource group level causes issues because the Tags dont get inherited at Resource level.
The hope was that any tags that you apply at one level of the hierarchy will be inherited by the lower levels within the hierarchy and this doesnt happen.
You need to be careful that your tags stay Logical and don’t differ from higher levels. It may well be preferable to do this via Powershell Scrips that manually to ensure correct logic is maintained between resources and Resource Groups.
- The underlying technology that powers resource groups is the Azure Resource Manager (ARM).
- ARM was built by Microsoft in response to the shortcomings of the old Azure Service Manager (ASM)
- ARM requires that resources be placed in resource groups, which allows for logical grouping of related resources.
- Although creating a resource group requires specifying a region for it to be stored in, the resources in that resource group could span multiple regions.
- In the ARM architecture, resource groups not only become units of deployment, but also units of management of related resources.
- It allows role-based access control (RBAC) at the resource group level, making it much easier to manage user access to the resources in the group.
- When users log into the Azure Portal, they will only see resource groups they have access to and not others within the subscription. u Administrators will still be able to assign access control for users to individual resources within the resource group based on their roles. This is great to see costs associated with Each Resource Group
Successful Azure Resource Groups
If an application requires different resources that need to be updated together, such as having a SQL database, a web app, a mobile app, etc. then it makes sense to group these resource in the same resource group.
Use different resource groups for dev/test, staging, or production, as the resources in these groups have different lifecycles.
All the resources in the group should share the same environment (Dev, Test etc) because you deploy, update and delete together
If you have for example the marketing analytics database in one Resource Group and a demo database in another resource group, Each resource group needs its own server
You cant Rename a resource Group
A good naming convention to use is rg-projectorapp-subprojectorapp-dev or projectorapp-subprojectorapp-dev-rg
Examples of Resource groups
Now you have logical resource Groups set up we can set up tags which are good for larger organisations.
- Cost centre
- Responsible Person or Party
- Application Name
- Data Profile
- Power Off
- Maintenance Window
|costCenter||12345||This is your internal billing code||Business|
|managedByemail@example.com||Name or email address||Business|
|applicationName||myapp||name of the Project||Business|
|environment||<production, Staging, QA>||Identifies the environment||Business|
|dataProfile||<Public, Confidential, Restricted, Internal>||Data Sensitivity. Public: This information is public information, and can be openly shared on your website|
Internal: Internal information is company-wide and should be protected with limited controls.
Confidential: Confidential information is team-wide and its use should be contained within the business.
Restricted: Restricted information is highly sensitive and its use should be limited on a need-to-know basis.
|powerOff||yes, no||Can this resource be shut down at 7pm||Automation|
Looking at this example, the Tagging has been added to the resource Groups. However if you look at a resource, you wont see the tags.
We need to look at a way of ensuring that the Tags applied to the resource group are also applied for each resource.
Policies for Tags
- Azure Policy is a service in Azure that you use to create, assign and, manage policies.
- These policies enforce different rules and effects over your resources, so those resources stay compliant with your corporate standards and service level agreements https://docs.microsoft.com/en-us/azure/governance/policy/samples/apply-tag-default-value
- Microsoft provides sample JSON scripts to create the tagging policies
- JSON scripts can be deployed in the Azure Portal, Azure Powershell, Azure CLI or REST API.
- When you create resource groups and Resources you should always apply tags and the default value for that tag.
- There are Billing tags policy initiatives you can apply
- You can also enforce tags and value via Policies on resource groups or Resources
As an administrator, you may need to lock a subscription, resource group, or resource to prevent other users in your organization from accidentally deleting or modifying critical resources.
You can set the lock level to CanNotDelete or ReadOnly. In the portal, the locks are called Delete and Read-only respectively. it may be useful to add a tag for this
LockLevel <CanNotDelete, ReadOnly, NA>
We will look at tagging in more detail in other posts. What Policies you can apply. tagging via Powershell, CLI and ARM JSON Templates. How to manage and enforce good Tagging Logic.
We will also look at ways to use your tags