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]

Securing and Optimising Access to Azure Storage Accounts with Azure Endpoints

By [James Kindon]

When working with Azure files, it is important to ensure that traffic destined for your files shares is both secured and routed in an optimal fashion.

[Cloud and Modern Data Center]

Automating Active Directory Domain Join for Azure Storage Accounts with Container Workloads

By [James Kindon]

Having the ability to Active Directory Domain Join (ADDS) an Azure Storage account has changed the game for many organisations deploying file service into Azure.

[Cloud and Modern Data Center]

Impacts of CVAD 2003 Support Changes and LTSR 1912 Relevance

By [James Kindon]

A significant number of changes on support stances are being introduced with Citrix Virtual Apps and Desktops 2003 Current Release.