Have you ever accidentally deleted a resource to then find out you can’t recover it? Resource deletion in many cases is permanent in Azure so it’s key to triple check the resource before deleting it.
Besides the ‘are you sure’-dialog in the Azure Portal when you want to delete a resource, there is an extra way to make sure you have to jump through some hoops before you can delete a certain resource. When dealing with business critical data or resources, multiple Azure administrators, programmatic deletion via PowerShell, this feature might save your day.
Resource locks to protect against accidental deletion
So what is this feature I’m talking about? It’s called a ‘Resource lock‘ and is applicable to virtually all Azure resources from storage accounts to virtual machines and resource groups. Using Resource Locks you can essentially downgrade your user/role-rights on a specific resource without changing your role. This comes in handy when you have the Owner-role which allows you to delete resources with no questions asked.
The nice thing about Resource Locks is that a lock applies to all child resources as well, so if you place a lock on your resource group, all (existing and new) resources in that group will be protected.
How to enable Resource Locks in the Azure Portal
Virtually all resources in the Azure Portal will have the Lock-setting in the navigation sidebar.
You can select between two different types of locks, either Delete or Read-only. Delete simply means that the resources can still be modified, just not deleted and Read-only means that the resources can not be modified or deleted. Which is similar to the Reader-role in Azure.
After applying the lock you will find that all child-resources will inherit the lock and are prevented from deletion until you release (delete) the lock. You can not release a parent-created lock on a child-level specifically for that child, meaning you have the lift the original lock and therefor free all its inherit child resources even if you only want to delete one specific resource.
Best use for Resource Locks: Inactive resources and Storage Accounts with Soft Delete enabled
Configuring a lock on you subscription will prevent you or anyone from deleting any resources in your subscription, however, every time you want to delete a resource, you need to lift the lock and eventually reinstate the lock again. I would suggest enabling a Resource Lock on high level items like subscriptions and resource groups only if the item is finalized and no maintenance deletions are taking place on a frequent basis. Lifting and reinstating the lock frequently is cumbersome and you might forget reinstating the lock leaving your resources vulnerable.
Because of that, I suggest enabling locks on specific resources that are vulnerable to unrecoverable deletion, like Storage Accounts and its containers. With Azure Storage Accounts you can enable ‘Soft Delete‘ (which I recommend doing), but this does not save you if you delete the entire Storage Account or Container.
By enabling a Resource Lock on your Storage Account, you create an extra safety net for accidental deletion on both the Account as the Containers in it. You can still delete Blobs within the container as usual when you have a Lock in place, but those are protected (when enabled) by Soft Delete.
Additionally, if you have your Storage Account registered in the Azure Recovery Services vault, Azure will automatically create a delete-lock on that Storage Account.
In regards to backups and retention
If you apply a resource lock to resources that are systematically back-upped and cleaned up, keep in mind that the resources can not be deleted after the retention period expires when the lock is in place, possibly creating issues with your backup procedures.