AZURE VM LOCK

Question

I am trying to understand read only lock in Azure VM setup , if I enabled lock to a critical vm server so that stop and restart start is restricted and then we can actually be safer right and then if we enable the lock will it be affecting the backup process log diagnose problem or not then what is suitable vm centric lock for critical vm.

Answer 1

As currently suggested by kagiyama and adding more on this:

A ReadOnly lock restricts all authorized users to effectively Reader-level permissions on that resource. It allows read operations, but blocks delete and update (PUT/POST) operations on the management (control) plane. - https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json

Important point :

VM start, stop, and restart are POST actions on the control plane, so a ReadOnly lock will block these operations which matches your goal of preventing accidental stop/restart of a critical VM.

However, the same restriction also blocks legitimate operations such as:

1. Resizing, reconfiguring, or updating the VM
2. Installing/updating VM extensions
3. Updating diagnostics settings (these are management-plane writes)

Locks apply only to control-plane operations (https://management.azure.com), not data-plane operations. So, in-guest OS logging, event logs, and applications writing to disk are not affected.

Azure Backup is a control-plane service that must manage restore points and related resources.

A Read-only lock can interfere with backup/extension/diagnostics operations that require write (PUT/POST) calls, and a Cannot Delete lock on the system-created AzureBackupRG_* resource group can cause backups to fail, because the service can't clean up old restore point collections once it hits its limit. - https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/control-plane-and-data-plane

So, a Read-only lock on the VM (or its resource group) is more likely to cause operational/backup side effects than to help.

For most production-critical VMs, the recommended approach is:

1. Use a Cannot Delete (Delete) lock on the VM (and optionally its disks). This protects against accidental deletion while still allowing start/stop/restart, resizing, extensions, monitoring, and backups to work normally.
2. To specifically restrict stop/restart, use Azure RBAC / a custom role to deny Microsoft.Compute/virtualMachines/powerOff/action, /restart/action, and /deallocate/action for operators. This is the cleaner, targeted way to prevent power actions without the broad side effects of ReadOnly. - https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json
3. Do not place any lock on the AzureBackupRG_* resource group, as it can break restore point cleanup and cause backup failures

Answer 2

I think CanNotDelete is basically a “delete‑only” lock, and Azure doesn’t mention any VM‑backup impact as long as the Backup Resource Group isn’t locked. For a critical VM, CanNotDelete makes sense because it blocks delete but still allows updates.

Answer 3

A management lock on an Azure VM protects it only at the control plane (management operations), not the data plane (what runs inside the VM).

Key behaviors of VM locks

1. Lock types
   • CanNotDelete (Delete lock)
     • Allows read and update operations.
     • Blocks delete operations on the VM (and any other locked resource).
   • ReadOnly (Read-only lock)
     • Allows only read operations.
     • Blocks all update and delete operations.
     • Equivalent to forcing everyone to have only Reader permissions on that resource.
2. Scope and effect
   • Locks apply to control plane operations only (calls to https://management.azure.com).
   • They do not affect data plane operations (for example, the VM’s OS doing I/O, apps writing to disk, etc.).
   • Example from the docs: a ReadOnly lock on an SQL logical server still allows normal data transactions in the databases because those are data plane operations.
3. Read-only lock on a VM or its resource group
   • A ReadOnly lock on a resource group that contains a virtual machine:
     • Prevents starting or restarting the VM from Azure (these are POST control-plane operations).
   • A ReadOnly lock directly on the VM has the same effect for that VM: no start, restart, resize, reconfigure, etc., from the control plane.
   • This matches the intent of “no one can stop/restart this critical VM from the portal/CLI/ARM.”
4. Impact on backups and diagnostics
   • Azure Backup is a control-plane service that must manage restore points and related resources.
   • A CanNotDelete lock on the resource group created by Azure Backup Service causes backups to fail, because the service cannot clean up old restore points once it reaches its limit.
   • For the VM itself:
     • A ReadOnly lock blocks updates to the VM resource (for example, changing extensions, configuration, or anything that requires a PUT/POST on the VM resource).
     • Backup operations that require updating or managing related resources under a locked resource group can fail if those resources are under a CanNotDelete lock that prevents cleanup.
   • Locks do not affect data-plane logging inside the OS (event logs, application logs), but they can affect Azure-side diagnostics if those diagnostics require updating or creating resources under a locked scope.

Recommended lock strategy for a critical VM

1. For day-to-day protection against accidental deletion
   • Use CanNotDelete (Delete) lock on the VM (and optionally its disks) or on the resource group that contains the VM.
   • This prevents accidental deletion while still allowing:
     • Start/stop/restart
     • Resize and configuration changes
     • Backup services to manage related resources (as long as the backup resource group itself is not locked in a way that blocks cleanup).
2. For strict protection against operational changes (including start/stop)
   • Use ReadOnly lock on the VM or on the resource group containing the VM.
   • This will:
     • Prevent start/restart/stop from Azure control plane.
     • Prevent configuration changes.
   • However, this can interfere with:
     • Operational tasks (patching, scaling, extension updates).
     • Some management operations that backup or monitoring services might need at the control plane.
3. Practical guidance
   • For a “critical VM” where availability and manageability are both important:
     • Prefer CanNotDelete on the VM or its resource group to avoid accidental deletion while keeping normal operations and backups working.
   • Use ReadOnly only in very controlled scenarios and test:
     • VM backup jobs (Azure Backup) still succeed.
     • Required diagnostics and management operations are not blocked.

Summary

• ReadOnly lock will block start/restart/stop and any configuration changes via Azure management APIs, which can help prevent accidental operational actions but may interfere with some management/backup operations.
• CanNotDelete lock is generally the more suitable “VM-centric” lock for critical VMs because it protects against deletion while allowing backups and normal management operations to continue.

---

References:

• Lock your Azure resources to protect your infrastructure
• Run a Linux VM on Azure
• Run a Windows VM on Azure
• An overview of Azure VM backup