跨订阅复制Azure VM：为何不直接复制托管磁盘快照？

Great question! Let's break this down clearly—first off, directly copying a snapshot to the target subscription and then creating a VM from it is absolutely a supported, streamlined approach (as you've seen in the official Microsoft scripts). So why do some guides still recommend the "snapshot → Blob copy → recreate VM" workflow? It boils down to historical context and specific use cases:

1. Historical Feature Limitations #

When managed disks first launched in Azure, cross-subscription snapshot replication wasn't a native feature. The only way to move disk content across subscriptions was to export the snapshot to a Blob storage account, copy that Blob to the target subscription's storage, then import it back as a snapshot or managed disk. Many older tutorials were written during this era and haven't been updated to reflect the newer, more efficient native snapshot copy capabilities.

2. Flexibility for Customization #

The Blob-based workflow shines if you need to modify the disk content before spinning up the new VM. For example:

• You might want to mount the VHD (from the Blob) to a temporary VM to clean up unused data, update drivers, or tweak configurations.
• You need to compress the VHD file or convert it between formats (though modern managed disks handle most of this natively now).
• You're using third-party tools that interact directly with Blob storage to process disk images.

3. Cross-Region + Cross-Subscription Edge Cases #

While modern snapshots support cross-region and cross-subscription replication in one step, there was a time when cross-region snapshot copies were restricted. The Blob workflow let you first copy the storage account to the target region, then handle the subscription transfer—this was a workaround that's now mostly obsolete.

So Which Should You Use? #

For most standard cross-subscription VM migrations with managed disks, the direct snapshot copy method is better—it's faster, has fewer steps, and leverages Azure's native managed disk features to avoid potential issues with Blob storage (like accidental VHD corruption or performance mismatches).

Here's a quick snippet of the core PowerShell commands to do this (building on the official scripts you referenced):

# Get the source snapshot
$sourceSnapshot = Get-AzSnapshot -ResourceGroupName "SourceRG" -SnapshotName "SourceSnapshot"

# Define target snapshot parameters (in target subscription/resource group)
$targetSnapshotConfig = New-AzSnapshotConfig `
    -SourceResourceId $sourceSnapshot.Id `
    -Location "eastus" `
    -CreateOption Copy

# Switch to target subscription (if not already logged in)
Set-AzContext -Subscription "TargetSubscriptionID"

# Create the copied snapshot in target subscription
New-AzSnapshot `
    -ResourceGroupName "TargetRG" `
    -SnapshotName "TargetSnapshot" `
    -Snapshot $targetSnapshotConfig

# Now create a VM from the target snapshot
# (Use the official script for full VM creation: attach snapshot as OS disk, add NIC, etc.)

In short, the Blob-based method is a legacy approach that still has niche uses, but the direct snapshot copy is the modern, recommended path for most scenarios.

内容的提问来源于stack exchange，提问作者Niklas Jern