It probably never happened to you, but how do you prevent accidental deletions of Azure resources by you or your co-workers?
 |
| Oops deleting the wrong resource :-( |
Solution
Accidental deletions of Azure resources (for example by clicking on the wrong button) are probably very rare because you have to confirm the deletion by typing the name of the resource. Deleting the wrong resource (for example a resource with the same name in a different resource group) is more likely.
Microsoft added a very simple, but also very effective solution for this with the Locks option. You can add locks on Subscription level, Resource Group level and Resource level. There are two different type of locks:
- Read-only: Authorized users can't change a thing and therefor they also can't delete the resource
- Delete: Authorized users can change the resource, but they can't delete the resource
Note: although you might be a contributor or owner for the resource. A lock overrides that authorization.
1) Determine level and lock type
First step is to determine which resource(s) you want to protect and where you want to add the lock. On the Subscription level is probably a bit too protective in most cases and on individual resources might be too much work. Resource group is the most likely choice. Next step is to decide which lock you want to add: read-only or delete. If you want to exaggerate you could even add multiple locks on the same level or on different levels.
2) Add lock
Now it's time to add the actual lock for preventing an unwanted delete.
- Go to the Subscription, Resource Group or Resource and click in the left menu on Locks. On Subscription level it is called 'Resource locks'.
- Click on the + Add button
- Enter the Lock name. E.g. 'Prevent Accidental Deletes'
- Choose the lock type: read-only or delete
- Enter a note why you have added this lock and hit the OK button
 |
| Add a delete lock |
Note: Removing a lock can be done in the same spot.
3) Testing
To test this you probably want to create a dummy resource and then try to delete it. When you delete the resource it initially looks like you will succeed, but then you will get the following error message (it also shows where you can find the lock).Failed to delete logic app AWS. The scope '/subscriptions/1x1111x1-1x1x-1111-xx11-1x1111x1x11x/resourceGroups/Joost_van_Rossum/providers/Microsoft.Logic/workflows/AWS' cannot perform delete operation because following scope(s) are locked: '/subscriptions/1x1111x1-1x1x-1111-xx11-1x1111x1x11x/resourceGroups/Joost_van_Rossum'. Please remove the lock and try again.
 |
| Try to delete resource with lock |
Summary
In this post you saw how to use locks for (accidental) delete prevention of Azure resources. Probably most useful for mixed environments to protect the production resources. There are a few considerations when using locks:
To add or remove a Lock you need to have the role Owner or User Access Administrator. This means you can also use a deletion Lock to really prevent deletions by people with the Contributer role. They can still edit the resource, but are not allowed to delete the resource.
If you have Azure Automation runbooks scheduled to upscale or downscale a resource with a read-only lock then you first have to remove the lock in the PowerShell script before making the changes. Same applies to Azure DevOps when your deployment changes a resource in Azure with a lock.
The locks only prevents 'Azure changes'. However it does not prevent deletions or changes within for example an Azure SQL database.
