Microsoft Ignite 2025 に参加したので、その中で発表された Azure 系のアップデートについて、内容を補足・確認してみようと思います。
TL;DR
- Ultra Disk/Premium SSD v2 でもスナップショット取得直後から、ディスクの作成ができるようになった(今まではディスクからスナップショットへのデータコピーを待つ必要があった)
- 今回の発表内容は、既に Premium SSD/Standard SSD/Standard HDDに合った機能を Ultra Disk/Premium SSD v2 に拡張したもの
- 実際に機能の有り/無しで比較したら、機能無しの場合、一時間程度待つ必要があった
- (余談) ドキュメントの不備があった場合は、ぜひフィードバックしていきましょう
Instant Access Snapshot for Azure managed Disk とは
Azure Managed Disk のスナップショットは、データのバックアップや、環境のコピー等、色々なことで利用されているかと思います。
私も、VM のコピーをしたい時などに、よくお世話になっています。
多くの場合において、スナップショットを利用する場合は、以下の図のように、まず Managed Disk からスナップショットを作成 (図中①の操作) し、 その後、スナップショットから Managed Disk を作成 (図中②の操作) したうえで、VM にデータディスクとしてアタッチする、 コピーしたディスクを OS ディスクとして、VM を作成するなどをしているかと思います。
今回の発表の「インスタント アクセス スナップショット」の機能は、この①の操作の後すぐに、②の操作や、スナップショットからVHD ファイルのダウンロードが可能になるという発表になります。
今回のUpdate範囲
上記の内容に関して、Azure VM や、Azure Virtual Desktop 等で、Managed Disk をよく利用している方は、「あれ?」と思ったかもしれません。
実はこの機能は、 Premium SSD/Standard SSD/Standard HDD のディスクでは既に既定で使えていました。
そのため、多くの人があまり気にせず使っていた機能かと思います。
今回の発表では、この適用範囲が、「Ultra Disk や Premium SSD v2 にも拡張されて利用できるようになります(Ignite 発表時点ではプレビュー機能) 」というものとなります。
補足: 実際の Update の範囲について
実際の Update に関しては、スナップショットから Managed Disk を作成する際にかかるデータコピーの時間 (ハイドレーションのスピード) が 10 倍早くなったこと、ハイドレーション中は IO のレイテンシーが高くなることがあるのですが、この読み込みのレイテンシが 90% 小さくなったことが記載されています。こちらに関しても検証してみましたが、Disk のサイズが小さいからか、目に見えた差が出なかったので、まとめからは省いています。
これが既定値になってしまうと、有難さが分からなくなってしまいますし、せっかくのいい機会なので、どれくらい便利かを試してみました。
実際に試してみる
今回の検証では、スナップショットからのディスク作成直後の状態での IO パフォーマンスも試してみたかったので、以下の構成で検証を実施しました。
-
Azure CLI: ver.2.81.0
-
VM
- サイズ: Standard L8s v3 (8 vCPUs, 64 GiB memory)
-
Ultra Disk
- サイズ:1024 GB
- IOPS: 20000
- Throughput: 400 MB/s
Instant Access Snapshot 無しの場合
以下のコマンドで、Ultra Disk のスナップショットを作成しました。
コマンドの実行結果の抜粋から、"timeCreated": "2025-12-05T10:05:08.5946409+00:00" となっているので、検証を行った 2025/12/05 19:05 ごろ JST のお時間であることが分かります。(表記は UTC なので、JST は +9 時間となります)
# Instant Access Snapshotの機能無しでスナップショットを作成
az snapshot create -g instant-snapshot -n ultradisksnapshot --source <Managed Disk のリソースID> --incremental true --location japaneast --sku Standard_ZRS
# 実行結果(抜粋)
{
"completionPercent": 0.0,
<省略>
"provisioningState": "Succeeded",
"publicNetworkAccess": "Enabled",
"snapshotAccessState": "Pending",
"timeCreated": "2025-12-05T10:05:08.5946409+00:00", 補足:この時間は UTC なので、 JST では 2025-12-05 19:05:08 となります
"type": "Microsoft.Compute/snapshots",
}
その後すぐに、スナップショットからディスクの作成を試みるとエラーとなりました。
# コマンド
az disk create -g instant-snapshot -n disk-from-snap --location japaneast --sku UltraSSD_LRS --source <スナップショットのリソースID> --size-gb 1024
# 実行結果
(Conflict) Source incremental snapshot ultradisksnapshot copy is still in progress. Please retry after source snapshot's copy has completed.
Code: Conflict
Message: Source incremental snapshot ultradisksnapshot copy is still in progress. Please retry after source snapshot's copy has completed.
エラーメッセージからも、コピーが実行中で、もうちょっと待って再トライするようにということが分かります。
では、どれくらい待つ必要があるかを確認しますが、しばらく待っても作成可能にならなかったので、GitHub Copilot 先生に以下のような、監視スクリプトを書いてもらって完了を監視します。
内容としては、ドキュメント内に、スナップショット アクセスの状態を確認する方法の記載がありますので、単純に、az コマンドを実施して、ステータスを監視し、完了した時間をdate コマンドで出力するものです。
#!/usr/bin/env bash
set -euo pipefail
INTERVAL=10
SNAP_ID="<スナップショットのリソースID>"
while true; do
state=$(az resource show --ids "$SNAP_ID" --query "properties.snapshotAccessState" -o tsv)
date
echo "$state"
if [[ "$state" != "Pending" ]]; then
echo "Snapshot state is $state; exiting."
break
fi
sleep "$INTERVAL"
done
結果として完了した時間は以下の通りで、20:07 までかかっていたので、約 1 時間かかった計算となります。
Fri Dec 5 20:07:40 JST 2025 → JSTとUTCが入り混じっているが、大体1時間くらいかかった
Available
Snapshot state is Available; exiting.
当然ですが、コピーが完了後であれば、スナップショットからディスクの作成が可能でした。
# コマンド
az disk create -g instant-snapshot -n disk-from-snap --location japaneast --sku UltraSSD_LRS --source "<スナップショットのリソースID>" --size-gb 1024
# 実行結果
{
"completionPercent": 0.0,
<省略>
"diskIOPSReadOnly": 1024,
"diskIOPSReadWrite": 1024,
"diskMBpsReadOnly": 130,
"diskMBpsReadWrite": 130,
"diskSizeBytes": 1099511627776,
"diskSizeGB": 1024,
"diskState": "Unattached",
<省略>
"sku": {
"name": "UltraSSD_LRS",
"tier": "Ultra"
},
"tags": {},
"timeCreated": "2025-12-05T11:20:38.9357329+00:00",
"type": "Microsoft.Compute/disks",
"uniqueId": "91997c08-4bdd-4b13-9c2e-e8d1d8b149b5"
}
なお、スナップショット取得時のデータコピーにかかる時間は明示がありませんので、今回 1 時間で完了しましたが、もっとかかる場合も、もう少し早く終わる場合もあるかとは思います。
Instant Access Snapshot を利用した場合
結論から書きますと、こちらはサクッと作成できます。
以下コマンドと結果です。
まず、スナップショットをインスタント アクセス スナップショットで作成します。
前回との差は、--ia-duration オプションを利用するかどうかです。
このオプションを利用すると、実際に Azure Resource Manager にリクエストを送付する際のパラメータである、 instantAccessDurationMinutes に値がセットされますので、インスタント アクセス スナップショットになります。
また、ドキュメント の記載によるとinstantAccessDurationMinutes と 5 時間の短い方の時間の間(最少は60分)、インスタント アクセス スナップショット の状態となるようです。
# コマンド
az snapshot create -g instant-snapshot -n ultradisksnapshot --source <DiskのリソースID> --incremental true --location japaneast --sku Standard_ZRS --ia-duration 300
# 実行結果
{
"completionPercent": 0.0,
<省略>
"provisioningState": "Succeeded",
"publicNetworkAccess": "Enabled",
"resourceGroup": "instant-snapshot",
<省略>
"timeCreated": "2025-12-05T11:40:56+00:00", # 補足:この時間は UTC なので、 JST では 2025-12-05 20:40:56 となります
"type": "Microsoft.Compute/snapshots",
}
結果から、スナップショットを 2025/12/05 20:40 ごろ JST に作成したことが分かります。
作成が完了したので、そのまま、Diskの作成に移ります。
こちらも、特に変なことはせずに、普通にディスク作成のコマンドを実行します。
# コマンド
az disk create -g instant-snapshot -n disk-from-snap --location japaneast --sku UltraSSD_LRS --source "<スナップショットのリソースID>" --size-gb 1024 --zone 1
# 実行結果
{
"completionPercent": 0.0,
<省略>
"diskIOPSReadOnly": 1024,
"diskIOPSReadWrite": 1024,
"diskMBpsReadOnly": 130,
"diskMBpsReadWrite": 130,
"diskSizeBytes": 1099511627776,
"diskSizeGB": 1024,
"diskState": "Unattached",
<省略>
"timeCreated": "2025-12-05T11:41:59.0217296+00:00", # 補足:この時間は UTC なので、 JST では 2025-12-05 20:41:59 となります
"type": "Microsoft.Compute/disks",
<省略>
}
結果から、2025/12/05 20:41 ごろ JST に、すなわち、スナップショット作成から約 1 分後に既にスナップショットからディスクが作成できたことになります。
圧倒的に、こちらの方が高速ですね。
結論
今後、インスタント アクセス スナップショットが既定値になると、こんなことは気にしなくなるのだと想像します。
一方で、現時点においては、Ultra Disk と Premium SSD v2 に関しては、インスタント アクセス スナップショットが既定で有効ではないので、この機能を使わないと、やはりそれなりに (検証時で一時間程度) スナップショット から ディスク を作成可能になるまでに時間がかかるという状況でした。
余談: ドキュメントの修正リクエストについて
今回の検証を実施しているときに、Instant access snapshots for Azure managed disks のドキュメント中で、Azure CLI のコマンドの誤植を見つけました。
こういった場合、以下の手順でドキュメントのフィードバックをすることが可能です。
今後自分が困らないためにも、ドキュメントの問題は随時、修正してもらいたいので、私はフィードバックを実施いたしました。
小さなミスでもフィードバックすることで、今後の自分のためにもなりますので、ぜひフィードバックを続けていきたいものです。
フィードバック手順
- 修正の提案をする
ドキュメントの右側にある、サムアップ、サムダウンのボタンから、修正を提案することができますので、これをクリックします。
※修正の提案は、英語ページからしかできませんので、英語ページからやりましょうよく見たら日本語ページでもできそうでした
- フィードバックの理由と詳細を記入
選択肢でフィードバックの理由が選択できますので、フィードバックしたい内容に合わせて選択肢を選択したうえで、詳細をフリーフォーマットに記載します。
私の場合は、ドキュメント中の Azure CLI のコマンドの一部が不足していたので、その旨を追加しました。
うまくフィードバックが送信できたら、以下のようにフィードバックに感謝する旨が記載されます。
なお、記載にもありますが、残念ながらフィードバックに関するレスポンスはもらえません。
とはいえ、フィードバックすると順次修正してもらえるかと思いますので、ドキュメントの問題を見つけたら、ぜひフィードバックしてみることをお勧めしたいです。



