Azure VM を立てたとき、ディスクの設定をとりあえず「デフォルト」のまま進めてしまった経験はないでしょうか。オンプレ時代は「物理ディスクは買えばそのまま使う」が当たり前でしたが、Azureでは同じ感覚のままだとパフォーマンス不足やコストの無駄遣いにハマることがあります。
実際、Premium SSD と Standard SSD を混同したまま運用してコストが想定の3倍になったり、スナップショットとバックアップの違いを理解せずに「データが消えた」と焦るケースは珍しくありません。
この記事では、Azure Managed Disks（マネージドディスク）の基本構造・ディスクタイプの選び方・スナップショット運用・コスト設計のポイントを、オンプレ経験者にもわかりやすく解説します。
Azure Managed Disksとは？アンマネージドディスクとの違い
Azure仮想マシンのストレージには、大きく分けて「アンマネージドディスク」と「マネージドディスク」の2世代があります。現在、新規VMでアンマネージドディスクを選ぶ理由はほぼないので、実質的にManaged Disksが標準です。
1. アンマネージドディスク（旧世代）の問題
アンマネージドディスクは、内部的にAzure Blob Storage（ページBLOB）上にVHDファイルとして配置されます。ストレージアカウントを自分で作成・管理しなければならず、アカウントあたりのIOPS上限に引っかかるリスクがありました。複数VMを運用するとストレージアカウントを何個も作る羽目になり、管理が煩雑になるのが悩みの種でした。
オンプレに例えると、共有SANストレージのポートをVMごとに自分で割り当てていたようなイメージです。
2. Managed Disksで何が変わったか
Managed Disksでは、ストレージアカウントの管理がMicrosoft側に完全に隠蔽されます。エンジニアはディスクをひとつのAzureリソースとして扱うだけです。
・可用性セット（Availability Set）との統合: 同一可用性セット内のVMのディスクが自動的に異なるストレージスタンプに配置され、単一障害点を排除します
・スナップショットのシンプル化: BLOBレベルの操作なしに、APIでスナップショットが取れます
・RBAC対応: ディスクリソースそのものにIAMロールを設定できるため、権限管理がAzure全体で統一されます
・暗号化のデフォルト化: Azure Storage Service Encryption（SSE）が標準で有効で、追加作業なしに保管データが暗号化されます
ディスクタイプの選び方｜4種類を現場目線で比較する
Managed Disksには現在4つのタイプがあります。選択を間違えると「遅すぎてアプリが重い」か「速すぎてコストが無駄」かのどちらかに陥ります。
| ディスクタイプ | 最大IOPS（ディスク単体） | 最大スループット | 主なユースケース |
|---|---|---|---|
| Ultra Disk | 160,000 IOPS | 2,000 MB/s | SAP HANA、最高性能DB |
| Premium SSD v2 | 80,000 IOPS（設定可変） | 1,200 MB/s（設定可変） | 本番DB、IO集約型ワークロード |
| Premium SSD（v1） | 20,000 IOPS | 900 MB/s | 本番Webサーバー、中規模DB |
| Standard SSD | 6,000 IOPS | 750 MB/s | 開発・テスト環境、低負荷Webサーバー |
| Standard HDD | 500 IOPS | 60 MB/s | アーカイブ、バックアップ保管、開発用非起動ディスク |
1. 現場でよくある選択パターン
本番Webサーバーや中規模DB（MySQL、PostgreSQL等）はPremium SSD（v1）が定番です。ディスクサイズによってIOPSとスループットが自動で決まるシンプルさが魅力です。たとえばP30（1TB）なら5,000 IOPS・200 MB/sが保証されます。
高IOPS要件のOLTPや分析DBにはPremium SSD v2が向いています。IOPSとスループットをサイズと切り離して個別に設定できるため、「200GBのディスクに10,000 IOPS」という細かいチューニングが可能です。オンプレでSANのLUN単位にQoSをかけていた感覚に近いです。
Ultra DiskはSAP HANAやOracle Exadataクラスの要件向けで、ほとんどの現場では不要です。Ultra Diskを使えるリージョン・VMシリーズも限定されている点に注意してください。
開発・テスト環境はStandard SSDで十分です。Standard HDDはほぼアーカイブ専用と考えてください。
2. オンプレのディスク選定との比較
オンプレでは「SAS/SATA、RAID構成、回転数」を気にしていましたが、Azureでは物理的な詳細は見えません。代わりに「IOPSとスループットの上限値」に焦点を絞った選定になります。
注意点は、VMシリーズ側にもIOPS/スループットの上限があることです。たとえばStandard_D4s_v5（4 vCPU）はキャッシュなしで最大12,800 IOPS・192 MB/sの制限があります。いくら高性能なディスクを選んでも、VM側の天井を超えることはできません。ディスクとVMのスペックをセットで確認することが必要です。
Azureポータルとコマンドラインでのディスク操作
1. VMへのデータディスク追加（Azureポータル）
既存VMへのデータディスク追加は、Azureポータルから数クリックで完了します。
・[仮想マシン] → 対象VM → [ディスク] → [データディスクの追加] をクリック
・[新しいディスクを作成] でディスクタイプとサイズを指定
・[保存] でディスクがホットアタッチされます（ほとんどのVMシリーズで停止不要）
ディスクをアタッチしただけではOS側では認識されていません。Linux VMならパーティション作成・フォーマット・マウントの手順が必要です。
# Azure CLI でデータディスクを作成してVMにアタッチする例 # ディスクを作成 az disk create \ --resource-group myResourceGroup \ --name myDataDisk \ --size-gb 128 \ --sku Premium_LRS \ --location japaneast # VMにアタッチ az vm disk attach \ --resource-group myResourceGroup \ --vm-name myVM \ --name myDataDisk # Linux VM内でパーティションを確認 lsblk
2. ディスクタイプの変更（SKU変更）
Standard SSDで構築した環境を本番昇格するタイミングでPremium SSDに切り替えたい、というケースは実際に多いです。VMを停止せずにオンラインで変更できるディスクタイプもありますが、Ultra DiskやPremium SSD v2への変更はVM停止が必要な場合があります。
# Azure CLI でディスクタイプをStandard SSDからPremium SSDに変更する # 変更前に対象ディスク名を確認する az disk list \ --resource-group myResourceGroup \ --query "[].{Name:name, Sku:sku.name}" \ --output table # SKUを変更（VMが停止している場合は --no-wait を外してもよい） az disk update \ --resource-group myResourceGroup \ --name myDataDisk \ --sku Premium_LRS
3. 管理ディスクのスナップショット作成
スナップショットは「ある時点のディスク全体のコピー」です。Azureポータルからは対象ディスクのメニューで [スナップショットの作成] をクリックするだけで取得できます。
# Azure CLI でスナップショットを作成する az snapshot create \ --resource-group myResourceGroup \ --name myDiskSnapshot \ --source myDataDisk \ --location japaneast \ --sku Standard_LRS
スナップショットのSKUは Standard_LRS が最もコスト効率が高く、バックアップ用途ならこれで十分です。ZRS（ゾーン冗長）にしたい場合は Standard_ZRS を指定します。
スナップショットとAzure Backupの使い分け
「スナップショットとバックアップ、どっちを使えばいいのか」という質問はよく聞きます。整理すると次のように考えると判断しやすいです。
| 観点 | スナップショット | Azure Backup |
|---|---|---|
| 主な用途 | 変更前の一時退避、テスト用クローン | 定期的なデータ保護、長期保管 |
| 管理の手間 | 手動または自動化スクリプトが必要 | ポリシーで自動スケジュール管理 |
| 世代管理 | 自分で削除・ローテーション管理が必要 | 保持期間・世代数をポリシーで設定 |
| ソフト削除対応 | なし | あり（誤削除防止） |
| コスト | ディスク使用量に応じた従量課金 | ストレージ＋保護インスタンス料金 |
スナップショットは「ミドルウェアのバージョンアップ前に退避する」「開発用に本番ディスクのクローンを作る」といった一時的な用途に向いています。一方、定期バックアップと長期保管はAzure Backupに任せるのが運用コストを考えると現実的です。
注意点: スナップショットを放置するとコストが積み上がります。用途が終わったら即削除する習慣と、スナップショット一覧を定期的にAzure Resource Graphで棚卸しするツール化を組み合わせるのがおすすめです。
料金の仕組み（コスト感覚を身につける）
Azure Managed Disksの料金は主に「ディスクタイプ×プロビジョニングサイズ」の月額固定課金です。AWSのEBSと同様に、使用量ではなく確保したサイズに対して課金される点を最初に押さえておきます。
Premium SSD（東日本リージョン、2026年6月時点・税別）の料金例
・P10（128 GB）: 約$20/月
・P20（512 GB）: 約$74/月
・P30（1 TB）: 約$135/月
実際の価格はAzure料金計算ツールや公式料金ページで最新値を確認してください。為替や料金改定の影響を受けるため、見積もり時点での確認が必須です。
コストを削減するための主なポイント
・サイズの過剰プロビジョニングを避ける: 「将来のために大きいサイズにしておこう」という発想は、クラウドでは月額コストに直結します。実際の使用量＋20%程度を目安に選び、必要に応じてオンラインでサイズ拡張する運用が最適です
・停止したVMのディスクに注意: VMを停止（割り当て解除）しても、マネージドディスクの課金は継続します。長期不要なVMはディスクのスナップショットを取って本体ディスクを削除し、必要時に復元する形が最もコストを抑えられます
・スナップショットはStandard_LRSで保管: Premium SSDのスナップショットをPremium SKUで保管する必要はありません。Standard LRSに落とすだけで保管コストを大幅に削減できます
・Azure Reservationsは対象外: Managed Disksそのものにはリザーブドインスタンスの仕組みはありません。ただしVMのリザーブドインスタンス（Reserved VM Instances）を使うとコンピュート費用が最大72%削減できるため、ディスクより先にVM側から最適化を検討するのが優先順位として正しいです
応用・実務Tips
1. 共有ディスク（Shared Disk）で複数VMからの同時アクセス
Premium SSD と Ultra Diskには「共有ディスク」機能があります。複数VMから同一ディスクにマウントでき、Windows Server FailoverクラスタリングやLinux Pacemakerクラスタのクォーラムディスクとして使えます。オンプレでSAN共有ボリュームを使ってクラスタを組んでいた構成のAzure版です。
同時書き込み時の排他制御はアプリ側の責任で行う必要があり、Azure側はブロックレベルの同時マウントを許可するだけです。スクリブルアービトレーション（ファイルシステムではなくアプリがロックを制御）が前提の構成向けです。
2. ディスクバーストでIOPSの一時的な上振れに対応
Premium SSD（P20以下）とStandard SSDには「バースト（Bursting）」機能があります。通常時のIOPS上限を一時的に超えて処理できる仕組みで、OSの起動時やアプリの初回読み込みなどの短時間スパイクに対応します。
バーストには「クレジット」の概念があり、IOPS上限以下で動いている間にクレジットを蓄積し、スパイク時に消費する形です。常時高IOPSが必要なDBワークロードには効果がないため、バーストに期待してサイズを小さくする選択は危険です。
3. ディスク暗号化の選択肢
Managed Disksには複数の暗号化オプションがあります。
・Azure Storage Service Encryption（SSE）: デフォルトで有効。Microsoftが鍵管理するサーバーサイド暗号化
・顧客管理キー（CMK）: Azure Key Vaultに自分の鍵を保管してSSEに使用。鍵のローテーションと失効管理が自分の責任になる
・Azure Disk Encryption（ADE）: OS内部でBitLocker（Windows）またはDM-Crypt（Linux）を有効化。二重暗号化になるが、起動時間が遅くなる場合がある
コンプライアンス要件で「顧客管理キー必須」と指定されていなければ、SSE（デフォルト）で十分なケースがほとんどです。
よくあるトラブルと対処法
【トラブル1】ディスクをアタッチしたがLinuxから見えない
Azure側でアタッチしてもLinux OS内でパーティションとファイルシステムを作成するまでは使えません。`lsblk` でデバイス名（/dev/sdc 等）を確認し、`fdisk` または `parted` でパーティション作成→`mkfs.xfs`（または`mkfs.ext4`）でフォーマット→`/etc/fstab` に追記してマウントする手順が必要です。`/etc/fstab` には UUID 指定で記載しないと、デバイス名の変動でマウント失敗することがあります。
【トラブル2】ディスクサイズを拡張したがOS側に反映されない
Azureポータルでディスクのサイズを拡張しても、OS側のパーティションとファイルシステムは自動では広がりません。Linuxであれば `growpart` でパーティションを拡張後、`resize2fs`（ext4）または `xfs_growfs`（xfs）でファイルシステムを拡張する手順が必要です。ディスクのオンライン拡張はほとんどのケースでVMの再起動なしに完了しますが、OSディスク（sda）の拡張は再起動が必要なケースもあります。
【トラブル3】スナップショットからディスクを復元したら起動しない
スナップショットからOSディスクを復元してVMにアタッチした際、元のVMのSAS（Shared Access Signature）やBitLockerキーが関連づいていた場合に起動に失敗するケースがあります。まずスナップショットから新しいディスクを作成し、そのディスクを別の正常稼働VMにデータディスクとしてアタッチしてデータを救出する方法が安全です。
【トラブル4】Premium SSDにしたのにパフォーマンスが出ない
前述のとおり、VMシリーズ自体にIOPS上限があります。たとえばStandard_D2s_v3は非キャッシュディスクで6,400 IOPSが上限のため、P30（5,000 IOPS）の能力を引き出せても、そのVMでP40（7,500 IOPS）にしても無意味です。Azure Monitorの「ディスクOPS消費比率」や「VMキャッシュ帯域幅消費比率」メトリクスを確認し、ボトルネックがディスクかVMかを切り分けることが先決です。
姉妹サイトLinuxMaster.JPでは、LinuxサーバーのディスクIO監視コマンドやiostatlによるパフォーマンス分析の手順を詳しく解説しています。Azureのメトリクスと組み合わせて活用してください。
本記事のまとめ
Azure Managed Disksの要点を整理します。
・アンマネージドディスクは事実上廃止: 新規VMは必ずManaged Disksを使う
・ディスクタイプの選定基準: 本番DB・高負荷=Premium SSD（v1/v2）、開発・テスト=Standard SSD、アーカイブ=Standard HDD
・VMのIOPS上限を先に確認: ディスクを高性能にしてもVMが瓶首になる
・スナップショットは一時退避・クローン用途: 定期バックアップはAzure Backupに任せる
・コスト最適化の優先順位: 過剰サイズを避ける→停止中VMのディスク整理→スナップショットをStandard LRSで保管
・暗号化はデフォルトのSSEで大半の要件を満たす: CMKが必要かどうかをコンプライアンス要件から逆算する
オンプレのSAN設計と比べると、Azureのディスク管理は仕様がシンプルになった反面、「VMとディスクの組み合わせ依存関係」「課金の常時発生」「OS側の拡張手順」など、知らないとはまるポイントがいくつかあります。この記事で紹介した内容を押さえておけば、Azure VMのディスク設計で大きな失敗は避けられるはずです。
Azureのディスク設計、もっと深く理解したいですか？
クラウド実務に役立つ「Azure Basics」カテゴリの記事を他にもまとめています。あわせて読みたい関連記事はこちらからどうぞ。
