A virtual machine contains business data on its managed disks, some cached disk data on the host, and often temporary data that does not behave like persistent storage. An administrator sees that Azure encrypts managed disks by default and assumes every part of the workload has the same protection. Another administrator wants to move that VM to a new resource group and assumes the result will also change its region. Both assumptions confuse boundaries that Azure treats differently.
Encryption at host and virtual-machine moves belong to different operations, but both require a precise model of the VM’s dependencies. The first asks where data is encrypted and which guest or host components are covered. The second asks which resource IDs, networks, storage, identities, quotas, and recovery arrangements are affected when a VM is reorganized or relocated.
Identify which storage encryption layer protects the data
Azure managed disk server-side encryption (SSE) protects persistent data on managed OS and data disks when it is stored in Azure Storage. It is enabled by default and usually uses platform-managed keys; supported scenarios can use customer-managed keys with a disk encryption set. SSE alone is not equivalent to encryption at host because temporary disks and OS/data disk caches on a host have different protection boundaries.
Encryption at host covers temporary disks and caches at rest and encrypts data as it moves toward the storage service. For disks protected by customer-managed keys, the relevant cache follows the chosen key-management configuration; temporary disks and ephemeral OS disks use platform-managed keys for this host-encryption model. Administrators should read current configuration rather than infer an effective protection state from the word “encrypted” on a general disk overview.
The official Microsoft AZ-104 compute objectives distinguish configuring host encryption from VM disks, sizing, and moving machines across scopes or regions. The exam’s distinct topics reflect real operational responsibilities, not three names for the same virtual-machine setting.
| Control | What it addresses | What not to assume |
|---|---|---|
| Managed disk SSE | Persistent OS and data disk encryption at rest in Azure Storage | It does not by itself prove temporary disk or host-cache protection |
| Encryption at host | Temporary disk and cache encryption on the VM host and encrypted flow toward storage | It is not a VM backup, confidentiality guarantee for running guest memory, or a resource-move feature |
| Azure Disk Encryption (ADE) | Legacy guest-level OS/data volume-encryption approach | It is not the same control as host encryption and has an announced retirement |
| Customer-managed key with a disk encryption set | Control over encryption key lifecycle for supported managed disks | It does not create or grant key access automatically after a move |
Do not confuse legacy Azure Disk Encryption with host encryption
Microsoft’s current security documentation states that Azure Disk Encryption is scheduled for retirement on September 15, 2028. It advises using encryption at host for new VMs or assessing appropriate confidential-VM options, and planning migration of existing ADE workloads before their lifecycle limit. The retirement timing is a first-party program fact to recheck against Microsoft before a production migration because platform support dates can change.
Azure Disk Encryption and encryption at host are not interchangeable toggles. Microsoft’s host-encryption restrictions exclude VMs or VM scale sets that currently have or previously had ADE enabled, and Azure Disk Encryption cannot be enabled on disks with host encryption. For a legacy ADE machine, develop a supported migration path and restore test rather than attempting to activate incompatible features together.
Do not interpret a simple “encryption at rest: enabled” observation as enough evidence that a machine satisfies its security policy. Look at the actual VM encryption-at-host property, managed-disk key configuration, OS and data disks, temporary disks, and any supported compliance assessment evidence. Recording which precise control is enabled makes an audit or recovery much more meaningful.
Plan encryption at host before changing a running VM
Microsoft documents subscription and feature prerequisites, region and VM-size support, and restrictions for particular disk types. A compatible VM family in one region is not proof that the same capability is supported for every older size or destination region. Verify the subscription’s feature state and the supported VM size before scheduling changes.
For an existing VM, host-encryption changes can require deallocation and reallocation. That interrupts the guest workload. In a VM scale set, enabling the feature may apply automatically only to newly created instances; existing instances require separate planning. A correctly applied configuration across one newly built test VM should not be reported as validation across every older scale-set instance.
Where customer-managed keys are required, the associated disk encryption set and the Key Vault or Managed HSM permissions become service dependencies. Confirm the key’s availability, access model, rotation policy, soft-delete and purge-protection constraints before treating a VM’s encryption state as independent of its key service. A broken key-access path can cause operational failures even when the disk itself exists.
Inspect encryption at host on an existing VM
Microsoft documents the Azure CLI property securityProfile.encryptionAtHost for checking the relevant VM setting. A read-only query is more useful than assuming the storage account’s disk encryption status covers every host component:
az vm show -g example-rg -n example-vm --query 'securityProfile.encryptionAtHost' -o tsvReplace the example names with a permitted test resource. A returned configuration value does not itself validate key recovery, guest health, or the protection of all related services. Confirm the supported region, SKU and disk restrictions and record the current policy before making changes.
Enabling host encryption on an existing VM can require deallocation and reallocation, which interrupts the workload. A responsible change request identifies the downtime, backup/recovery evidence, dependent services, disk support, key permissions, and the test that will establish service health afterward. A feature switch is not a substitute for an application-level recovery check.
Disk sizing and encryption solve different problems
Choosing an OS disk, data disk, storage type, caching mode or VM size is a performance and capacity decision. The existing Azure data disk management article covers attaching and preparing disks, while Azure VM sizing addresses workload resource needs. Encryption must be evaluated alongside those choices rather than mistaken for a replacement.
A VM size upgrade may be blocked when the new size does not support the encryption-at-host feature. Certain Ultra Disk or Premium SSD v2 configurations have additional conditions. A disk that meets a security requirement can still be too slow for an application; a high-performance disk with an intact backup may still lack the requested host-cache encryption. Test the actual combination in its intended region.
A same-region resource move changes ownership, not location
Azure Resource Manager supports moving eligible resources between resource groups within a subscription. It may also support moving them across subscriptions in the same Microsoft Entra tenant. Such a move changes the Azure resource ID path where the subscription or resource-group portion changes; it does not relocate a VM to a different Azure region.
During a supported move, the source and destination resource groups are locked against relevant create, update and delete actions. Microsoft documents that this temporary lock can persist for up to four hours; existing services can remain operational in applicable scenarios. Do not schedule an unrelated deployment or role change against the same group during that window.
Automation that stores complete resource IDs may break after the move. Inventory dashboards, monitoring assignments, diagnostic destinations, policy and RBAC inheritance, release scripts and backup integrations before changing resource groups. A portal success notification is weaker evidence than proving those consumers still target the correct new resource IDs.
Inventory linked resources before moving a virtual machine
Start with the VM resource and its attached disks, network interface, virtual network, public IPs, load-balancing associations, managed identities, diagnostic settings and recovery policies. Not every linked service resource moves as a child of the VM, and resource providers have their own restrictions. Microsoft’s Resource Manager guidance recommends validating all resources and dependencies rather than attempting an arbitrary collection of moves.
Confirm the intended source and destination scope, supported resource types, permissions, resource locks and management-group policies. Moving an application into a different subscription may change inherited role assignments and governance controls. The distinction between RBAC scopes and inheritance becomes practical when a VM operator who had access before the move finds that their rights no longer apply to the destination.
A Read-only lock on the source or target resource group or subscription can block the move. Do not delete the lock reflexively; document who applied it, what it protects, whether temporary removal is authorized and how the original guardrail will be restored. Check role assignments after the change instead of assuming the new location gives exactly the same permissions.
Moving to another region requires a relocation workflow
The normal Azure Resource Manager move API does not move a resource into a different physical region. Microsoft documents Azure Resource Mover for supported cross-region virtual-machine and dependent-resource relocation. Azure Site Recovery can also be part of a planned migration or recovery strategy, but the two services should be chosen for their supported scenarios rather than described as interchangeable buttons.
A regional relocation must account for destination-region quota, supported VM and disk types, network resources, permissions, guest requirements, outbound connectivity, replication state and cutover effects. Resource Mover supports preparing a set of linked resources, resolving dependencies, initiating a move, and then committing or discarding it according to the documented process. The target configuration must be reviewed independently of the source.
Plan the recovery posture for the interval before cutover. Some source workloads can remain active while data is replicated, but moving the production endpoint, dependency order and DNS/connection paths may create a service interruption. The project’s uptime goal and the actual move method determine which steps require an approved maintenance window.
A VM protected by availability sets or zones may need a different target placement strategy. A region change can affect capacity, permitted VM sizes, storage redundancy, private endpoints, IP addresses, recovery dependencies and monitored resource IDs. Validate the application path from the user’s perspective rather than declaring the move complete when the target VM first starts.
Use an explicit decision table before selecting a move method
| Change requested | Expected approach | Risk to verify |
|---|---|---|
| Same-region change of resource group | Supported Azure Resource Manager resource move | Dependencies, changed resource IDs, lock window and RBAC scope |
| Subscription change in the same tenant | Supported cross-subscription resource move | Resource-provider constraints, policy, billing and permission differences |
| Relocate a VM to a different region | Azure Resource Mover or another supported migration workflow | Replication, target quotas, network and downtime/cutover |
| Change a VM to another virtual network | Assess rebuild or other supported network migration path | VM/NIC dependencies, IP changes and application connectivity |
| Turn on host encryption on an eligible existing VM | Supported per-VM encryption configuration change | Deallocation, guest downtime, encryption prerequisites and disk support |
Moving a resource does not automatically prove that its guest OS, customer-managed key, backup application or monitoring service is ready at the destination. A team should define the intended final state and the evidence required for every relevant dependency before it selects the method.
Review a realistic production change request
Imagine a team with a Windows VM used by an internal application. It has managed disks and nightly backup. Security wants encryption at host enabled, finance wants the machine in a different subscription, and the application owner proposes relocating it to another region during the same weekend.
These are three separate decisions. First verify the VM’s current encryption model and whether it has ever used legacy Azure Disk Encryption. Next inspect management scope, role assignments and dependencies for a subscription move. Finally assess the supported regional migration method, network cutover and destination capacity. Combining all three changes without staging hides which operation could break the service.
- Record the current VM resource ID, region, SKU, disks, encryption state, roles, backups and application dependencies.
- Check feature registration, disk and VM-size support, key management and incompatibilities before enabling host encryption.
- For a resource-group or subscription move, validate supported resource types, relevant locks, changed IDs and target-policy inheritance.
- For a regional migration, plan replication, networking, DNS, quotas and the supported cutover procedure separately.
- Stage tests, approve expected outages and record who can pause or reverse a failed operation.
- Verify the resulting encryption state, application access, monitoring, disk attachment and actual service recovery after each change.
This is an example runbook based on current Microsoft guidance, not a record of a migration or encryption operation actually performed in Azure. Operators must validate the instructions against their own supported service configuration.
Diagnose a failed change by its boundary
If host encryption cannot be enabled, check feature support, the region, the VM size, disk restrictions and legacy ADE history before widening permissions. A subscription role cannot make an unsupported VM family eligible for host encryption.
If a move between resource groups fails, examine provider dependencies, active read-only locks, tenant or subscription limitations and any partially completed resource operations. If an automated job fails only after an apparently successful move, it may still be using an old full resource ID. Correcting that reference can be safer than attempting the move again.
If the new region’s VM starts but the business application remains unavailable, inspect DNS, routes, load balancing, private access, managed identity, keys and application dependencies. A Site Recovery failover design shows why copying disk contents does not by itself demonstrate complete application recovery.
Make acceptance criteria observable and reversible
A configuration change can be technically successful while still failing its operational purpose. Encryption at host may be enabled for newly created scale-set instances while older ones still need attention. A VM may be running under the target resource group while access roles or monitoring assignments refer to the original scope. A regional migration may have copied disk data while the application points to a database or authentication provider that remains in the old region.
Define the expected outcome before implementation. Check the VM’s actual encryption property and supported key arrangement. Record its intended new resource ID and region. Verify user connectivity and the correct application data, then confirm monitoring, backup and recovery responsibility. Keep a supported recovery or rebuild path for each distinct change, together with the evidence needed to decide whether the operation should be considered complete.
A change record should name the workload owner, desired scope, relevant dates, approved interruption, tested dependencies and any exceptions to policy. The checks must be repeatable by someone other than the person who performed the move. Security approval that depends only on a portal screenshot is weaker than observing that the intended encryption control is configured and that the system can still provide its required service.
VM host encryption, persistent disk management and resource moves are related because they affect the same workload, but they protect different boundaries. A sound Azure administrator can explain where the data is protected, which resource path changed, which dependencies must be rebuilt or reauthorized, and what evidence proves that the application is healthy afterward.
