Azure Resource Groups – Preventing Accidental Deletion with Resource Locks


Did you know that when you delete an Azure Resource Group, it deletes all the resources in that group?


You have built a Resource Group in Azure that contains your infrastructure resources including:

  • Virtual Network
  • Subnets
  • Network Security Groups (NSG)
  • Storage account to hold diagnostic logging for the NSGs

The subnets may host your IaaS Virtual Machines, maybe define your DMZ and your reverse proxy. So questions around risk need to be asked including:

  • How easy is it to delete a Resource Group?
  • Who can delete a Resource Group?
  • What can be done to protect a Resource Group?

How easy is it to delete a Resource Group?


Through the Portal:

  • Select Resource Groups
  • Click on the Resource Group to delete
  • Click Delete
  • Type in the name of the Resource Group. If it matches the name, the delete button activates
  • Click Delete

Using PowerShell:

Remove-AzureRMResourceGroup -Name <Name> -Force

Who can delete a Resource Group?

Owners and Contributors.

This probably describes the level of access granted to most admin staff (Similar to how everyone seems to be a Domain Admin in Active Directory!)

What can be done to protect a Resource Group?

Resource Locks!

Hidden away in the Azure documentation, are PowerShell commands for locking Resources to prevent accidental deletion.

A Resource Lock can be applied to a Resource Group – All resources in that group inherit the lock. It is similar to using the Do Not Delete flag on an OU in Active Directory.

To lock a Resource Group run:

New-AzureRMResourceLock -LockName <Name> -LockLevel CanNotDelete -ResourceGroupName <Resource Group Name>

Principle of Least Privilege (PoLP)

Assign all staff the privilege that they require to do their job. No more.

The entire IT department do not need full unfettered access to Azure. Look in depth at the features of Role Based Access Control within the Azure documentation.

Map out who needs access to which resources. For instance, does a server administrator really require access to change your Virtual Network? Do they need to be able to create Subnets?

Change Control

Ensuring that changes to the environment only occur by agreement, and within a fixed time frame can go a long way to prevent disasters.

Some organizations go so far as to only allow the administrator access to a high level of privilege during a change window. After the change window, the extended permissions are revoked.

End Note

Planning is the key to preventing mishap (or malicious damage) to your Azure environment. It is worth taking the time to work out who will use Azure, what privileges they require to perform their roles, and when and how these extended privileges are to be granted.

Join the Insentra Community with the Insentragram Newsletter

Hungry for more?

[Cloud and Modern Data Center]

How to Move to the Cloud

Previously we explored the question of “why the cloud”, discussing the high level benefits as being Agility, Productivity and Cost Reduction and the things that influence what can be moved to the cloud. This time we will look at the key business considerations in “how” to move to the cloud.

[Cloud and Modern Data Center]

Veritas Guarantees Cloud Data Will Stay in Australia

By [Ronnie Altit]

Veritas has announced a “multimillion-dollar” deal with Equinix for “dedicated” Sydney and Melbourne data centres to serve its cloud archiving service