Azure locks and tags copyThere are two problems that most people have with Azure, but they are also the easiest to overcome. The first issue is organization, which is due to the one-level nature of Resource Groups. The second is the accidental modification or deletion of a resource, because it is too easy to do. So how should an organization handle these?

Azure Resource Manager (RM) differs from Azure Classic in one important point: everything in Azure RM has to live in one, and only one, resource group (RG). While this is great for small deployments, it can quickly become a huge organizational nightmare. It is better to think of RGs as security groups, where everything in it inherits the permissions, as opposed to thinking of them as organizational devices. In this setup you can split resources into common and lifecycle groups, so you might have a networking resource group, a development resource group, a database resource group, a production resource group, etc.

What about organizing and finding everything you need? Well, Tags are a wonderful tool designed for this job! Every resource can have 15 tags, with the name being a maximum of 512 characters long and values limited to 256 characters. Keep in mind that storage accounts can only have tag names with a maximum of 128 characters, though they can contain almost any character, except
<, >, %, &, \, ?, /, which is enough for complex sentences and also JSON data. Yes, you can include JSON data into tags!

Tags are also searchable, so you can use the PowerShell command
(Get-AzureRmResource -Tag @{ Dept="Finance"}).Name to find any resource with the Dept tag having the value “Finance” or pin it to the portal dashboard for easy access. Additionally, Tags are also integrated into reports, so you can separate costs based on a specific tag name.

Unfortunately, Tags are not inherited from a Resource Group, so every resource must have its tags applied individually. On the plus side, you can add Tags via ARM Templates, which can contain either static or programmed values. This gives you many possibilities to customize them per your preference.

The other issue has a simpler solution, although most people fail to implement it.  Resource Locks can be applied to any resource or resource group to prevent modification or deletion, regardless of permissions. This means even someone with the Owner role cannot delete or modify the resource without removing the Lock. If applied to a resource group, this applies to everything within it as Locks are inherited.

There are only two different types of Lock:
CanNotDelete and ReadOnly. As you can guess, CanNotDelete simply blocks the resource from being deleted while still allowing all modifications to happen and ReadOnly prevents all modifications as well as deletions. There can be an issue with applying ReadOnly Locks, as this can have unexpected results. One example is when some operations appear to be read-only and are actually write-enabled. Make sure you apply ReadOnly Locks only after testing.

It is important to note that Resource Locks only apply to the management plane, and do not interfere with data. Or to put it another way, applying a
ReadOnly Resource Lock to a Virtual Machine will not affect the running of the machine, but will prevent anyone from modifying the disks on the machine. To put it one other way, applying a ReadOnly Lock to a virtual network will prevent changes to the IP ranges on the subnets, but still allow data to flow as normal.

To apply and remove a Lock, the user must have either the Owner or User Access Administrator roles on the resources, and if you apply the Lock to a Resource Group, it is applied to all resources in the group. In the event that a resource already has a Lock, the most restrictive Lock applies.

Using both Tags and Locks enables an organization to get a handle on all the resources Azure creates, and prevents accidental modifications and deletions to the resources that matter. Ignore these two simple but effective features at your peril!

To learn more about this topic, check out INE’s Introduction to Azure Design and Implementation course. 


Jonathan Weekes
About Jonathan Weekes

Jonathan started in the electronics field and moved into the IT field after relocating to the U.S., he has worked as an IT generalist for the past 20 years. Jonathan has earned several certifications including: CISSP, MCSA: Windows 2012 R2, MCSE: Cloud Platform and Infrastructure 2017, Microsoft Azure, and Cisco CCNA. Currently, Jonathan works as a Windows Server and Azure Infrastructure Engineer for New Signature, a cloud-first, full-service Microsoft solution provider and Microsoft Gold Partner. He is also a Microsoft P-CSA (Cloud Solution Architect), which provides advanced notification and testing of new Azure changes. Jonathan uses his experience in Windows, security, databases, and other systems to help clients with their move to the cloud, and to help them understand the changes involved in this process. Jonathan's past positions include working for the state of South Carolina Department of Social Services, in the Security Department, working as an IT manger for Southland Log Homes, and a Senior Windows Administrator for QualServ Corp.

Subscribe to INE Blog Updates

New Blog Posts!