Azure の Managed Disk のまとめ

以前の記事からかなり時間が経ってしまいましたが、そろそろナレッジも増えてきたため、大幅アップデートしました。

# ■概要
- ストレージは Azure 側で管理され、ストレージプールのような使い方が出来る
- 従来仮想マシンの作成で必須だったストレージ アカウントが不要に
- IOPS の制限がなくなる
- VMSS でも使える
- Managed Disk から VHD へエクスポートが可能
- イメージ・スナップショットの作成が可能
- さらにそのイメージ・スナップショットから仮想マシンの作成が可能
- RBACとも連携できる

# ■管理ディスクのメリット
## シンプル＆スケーラブル
何はともあれ、初めに管理ディスクを使った 仮想マシン の作り方を見てみましょう。
Azure ポータルからの作り方はとても簡単で、仮想マシン の作成画面のストレージの、[管理ディスクを使用]を**[はい]**にするだけです。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/76095035-1e27-ea58-eff1-6cef7795520e.png)

ちなみに、これを[いいえ]にすると、従来の ストレージ アカウント を使用しますので、
ストレージ アカウント を選択(もしくは新規作成)する画面が出てきます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/b4980bf8-de58-fa32-fe40-237017d76103.png)

Azure ポータルから仮想マシンを作成する方法だけ見ると、従来の 仮想マシン の作り方とほとんど変わらず、何が変わったのか分からないと思います。

実際に、管理ディスクのシンプルさ＆スケーラブルさを感じるのは、
**ARM テンプレートや PowerShell を使用し一度に複数台の仮想マシンを作るとき等の展開の場面**、また、**ディスクの容量を増やしたり種類を変えたりするとき等の運用の場面** といった、仮想マシンの展開や構築、運用をする場面です。

具体的にどのような点が便利になったのか見ていきましょう。

### :heavy_check_mark: ARM テンプレートで 管理ディスク を使った 仮想マシン を展開する
上で書いたとおり、従来では、ストレージ アカウントという概念が存在し、まずはストレージ アカウントを作ってから、その中に VHD を作成するという方法で実現されていました。
必然的に、ストレージ アカウントを作成するためのテンプレートが必要になり、resources の記載も複雑になります。

```Json:ストレージアカウントを使ったテンプレート
"resources": [
  /*******************************/
  /*始めにストレージアカウントを作る*/
  /*******************************/
  {
    "comments": "# Storage Account",
    "name": "[variables('StorageAccountName')]",
    "type": "Microsoft.Storage/storageAccounts",
    "location": "[resourceGroup().location]",
    "apiVersion": "2015-06-15",
    "dependsOn": [ ],
    "tags": {
      "displayName": "StorageAccount"
    },
    "properties": {
      "accountType": "[variables('StorageAccountType')]"
    }
  },
.
.
.
  /********************/
  /*仮想マシンのリソース*/
  /********************/
  {
    "comments": "# TRANSFER VM",
    "name": "[variables('vmNames')[0]]",
    "type": "Microsoft.Compute/virtualMachines",
    "location": "[resourceGroup().location]",
    "apiVersion": "2015-06-15",
    "dependsOn": [
      /*ストレージアカウントとの依存関係を定義*/
      "[concat('Microsoft.Storage/storageAccounts/', variables('storageAccountName'))]",
      "[concat('Microsoft.Network/networkInterfaces/', variables('vmNames')[0],'NIC')]"
    ],
    "imageReference": {
      "publisher": "[variables('imagePublisher')]",
      "offer": "[variables('imageOffer')]",
      "sku": "[variables('windowsOSVersion')]",
      "version": "latest"
    },
    "osDisk": {
      "name": "[concat(variables('vmNames')[0],'-osdisk')]",
      "vhd": {
      /*******************************************/
      /*ストレージアカウントの中にあるVDHのURLを指定*/
      /*******************************************/

      "uri": "[concat('http://', variables('storageAccountName'), '.blob.core.windows.net/', variables('vhdStorageAccountContainerName'), '/',variables('vmNames')[0],'-osdisk' , '.vhd')]"
      },
    "caching": "ReadWrite",
    "createOption": "FromImage"
  }
``` 

一方、管理ディスクを使った場合、**リソース タイプ**として `disk`を使った文字通りディスクが使えるようになるので、ストレージ アカウントの様な回りくどいことをしなくてよくなります。

管理ディスクを使ったテンプレートを見てみましょう。

```Json:ストレージアカウントを使ったテンプレート
/*仮想マシンの一部を抜粋*/
"storageProfile": {
  "imageReference": {
    "publisher": "MicrosoftWindowsServer",
    "offer": "WindowsServer",
    "sku": "[parameters('windowsOSVersion')]",
    "version": "latest"
  },
  "osDisk": {
    "createOption": "FromImage" //イメージから作る。これだけ。
  },
```

これまでは、オブジェクトストレージとして表面上に見えていたディスク(VHD)ですが、新たな `disk` として リソース タイプ が定義されたことによって、使いやすくシンプルになったものが **管理ディスク** です。

### :heavy_check_mark: ストレージ アカウントの制限がなくなる
上記で書いたように、管理ディスクは、これまでのストレージ アカウントの管理が不要になりました。
つまりそれは、**ストレージ アカウントの制限を受けなくなる**、という意味にもなります。
※制限が無くなるわけではありません。

ストレージ アカウントの制限でよくあるのは、**IOPS** です。
1つの ストレージ アカウント に複数の 仮想マシン の VHD を格納することはよくありますが、そこで注意しないといけないのは、<font color="red">**ストレージ アカウント の20000 IOPS という IOPSの上限**</font>です。

この上限があることで、例えば、高 IOPS を出すために、複数のデータディスクを束ねて使う場合、ストレージ アカウントも複数作成し、その中にある VHD を接続するという、管理面で面倒な方法をとらざるを得ませんでした。

管理ディスクにすることで、そのような ストレージ アカウントの制限を受けず、ディスクを接続したい場合に、管理ディスクを作って仮想マシンに接続、という非常にシンプルな操作で実現できるようになります。

ちなみに、管理ディスクでは、SSD(Premium)とHDD(Standard)でそれぞれリージョンごとに、10,000 個の上限(既定)があります。

### :heavy_check_mark: ディスクの容量変更と種類の変更
こちらはとても分かりやすいです。
これまで、ストレージ アカウントの種類(SSD/Premium、HDD/Standard)は、作成時に決めるものであり一度展開した後(仮想マシンを作った後)は、容易に切り替えることが出来ませんでした。切り替えには、別にストレージ アカウントを作り、AzCopy 等で VHD をコピーし、その VHD から仮想マシンを起動するという手順が必要でした。

管理ディスクを使うと、**SSD と HDD の切り替えがプルダウン一つで切り替えられます。**
※ただし、仮想マシンを停止しておく必要があります。また、仮想マシンのサイズによって、SSD しか使えないサイズ、HDD しか使えないサイズがあります。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/2a4c49cc-46c5-e79a-ae50-217b4b01c3c0.png)

また、サイズの変更も数字を変えるだけです。


### :speech_left: 補足 : リソース プロバイダー や リソース タイプ って？
シンプルさを実現しているのが、リソース タイプ として、管理ディスクを表現する`disk`が登場したことです。

少し Azure の中の話しになりますが、現在の Azure は、**ARM** という API を使用しています。
この **ARM** では、例えば 仮想マシン や、ディスク といったリソースを表す場合、**リソース プロバイダー** や **リソース タイプ**というもので表されます。

言葉だけ並べてもよくわからないと思うので、Azure ポータルの 仮想マシン の概要を表示している URL を見てみましょう。
実は、Azure のポータルでも、この ARM の API を垣間見ることが出来ます。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/8528891e-4a51-e86f-0e7d-61b2e1c805e4.png)

上の絵であるように、Azure のすべてのリソースの一意性は、**サブスクリプションID**、**リソース グループ名**、**リソース プロバイダー**、**リソース タイプ**、**リソース名** で保証されています。

そして、**ストレージ アカウント**(`Microsoft.Storage`。正確にはその中の`storageAccounts`タイプ) や **仮想マシン**(`Microsoft.Compute`) は、**リソース プロバイダー**として存在しており、**管理ディスク**は、**仮想マシンのリソースの1つ**(`Microsoft.Compute/disks`)として、存在しています。

ちなみに、どのリソース プロバイダーに、どういう リソース タイプ が存在するのかというのは、PowerShell や Azure CLI で見ることが出来ます。

```PowerShell:プロバイダーの一覧
PS C:\Users\tsunomur> Get-AzureRmResourceProvider -ProviderNamespace Microsoft.Compute | ft

ProviderNamespace RegistrationState ResourceTypes                                               Locations                                                        ZoneMappings
----------------- ----------------- -------------                                               ---------                                                        ------------
Microsoft.Compute Registered        {availabilitySets}                                          {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachines}                                           {East US, West US, North Central US, South Central US...}
Microsoft.Compute Registered        {virtualMachines/extensions}                                {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets}                                   {East US, West US, North Central US, South Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets/extensions}                        {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets/virtualMachines}                   {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets/networkInterfaces}                 {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets/virtualMachines/networkInterfaces} {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachineScaleSets/publicIPAddresses}                 {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations}                                                 {}
Microsoft.Compute Registered        {locations/operations}                                      {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations/vmSizes}                                         {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations/runCommands}                                     {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations/usages}                                          {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations/virtualMachines}                                 {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {locations/publishers}                                      {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {operations}                                                {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {restorePointCollections}                                   {Southeast Asia, East US 2, Central US, West Europe...}
Microsoft.Compute Registered        {restorePointCollections/restorePoints}                     {Southeast Asia, East US 2, Central US, West Europe...}
Microsoft.Compute Registered        {virtualMachines/diagnosticSettings}                        {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {virtualMachines/metricDefinitions}                         {East US, East US 2, West US, Central US...}
Microsoft.Compute Registered        {disks}                                                     {Southeast Asia, East US, North Central US, South Central US...}
# ----------------------------------   ↑この disks が管理ディスクです。  ----------------------------------
Microsoft.Compute Registered        {snapshots}                                                 {Southeast Asia, East US 2, Central US, West Europe...}
Microsoft.Compute Registered        {locations/diskoperations}                                  {Southeast Asia, East US 2, Central US, West Europe...}
Microsoft.Compute Registered        {images}                                                    {Southeast Asia, East US 2, Central US, West Europe...}
```



## 信頼性の向上
まず、従来のストレージ アカウントを利用した場合の、仮想マシンの可用性セットの関係です。
こちらのドキュメントに記載があります。

Azure Storage のレプリケーション
https://docs.microsoft.com/ja-jp/azure/storage/common/storage-redundancy

ポイントはこちらです。

- 1つのデータは、1つのストレージ スケール ユニット内でデータがレプリケート
- ストレージ スケール ユニットは、ストレージ ノードのコレクション
- ストレージ スケール ユニット内で、障害ドメインと更新ドメインが存在

仮想マシンとも関連させて、絵にするとこのような形です。

**ストレージ アカウント(非管理ディスク)の場合**
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/1b4d7187-9873-2676-2567-5b817dacb999.png)


一方で、管理ディスクを利用した場合です。

Azure VM を Azure Managed Disks に移行する
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/migrate-to-managed-disks

ポイントはこちらです。
- 可用性セットが分かれると、ストレージ スケール ユニットが分離

つまり、仮想マシンの可用性セットとの関係で、下の様になります。
**管理ディスクの場合**
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/752428e5-60c7-0446-5f80-c163302508d1.png)


つまり、**管理ディスクを使用することで、ストレージ アカウント(非管理ディスク)の場合と比べ、ストレージ部分の信頼性が向上する場合があります。**
<font color="red">※ここで、ストレージ アカウント(非管理ディスク)の信頼性が低い、と単純には言えません。
管理ディスクのストレージ スケール ユニットはリージョンによって数が異なったり、ストレージ アカウントには、管理ディスクにないGRS(地理冗長)の機能があります。</font>

## アクセス制御
ストレージ アカウントは、作成すると、自動的にエンドポイント(URL)が用意されます。
例えば、`domain1diag912`というストレージ アカウントを作った場合、以下の様に、`https://domain1diag912.blob.core.windows.net/`というURLが付与されます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/e4462542-93c4-70d2-6903-5c2bd1ac219d.png)

これは、ストレージ アカウントはクラウド上のオブジェクトストレージであり、アクセスできる方法を確保しないといけないため、必然といえます。
しかし、仮想マシンを作成する上では、逆にそれによって、セキュリティの懸念が持たれます。

もちろん、仮想マシンを作成して、VHDができたとしても、ストレージ アカウントのアクセス制御である Shared Access Signatures (SAS) により、誰でも VHD が外から見えるわけではありません。ただ、万が一アクセス制御の操作をあえて行い、誤った設定にした場合、VHD がインターネット上に晒されることになります。


ストレージ  アカウントのアクセス制御を絵にするとこんな感じです。

![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/cd1c65ce-d56e-be5c-97d7-e9bd5d257a48.png)

一方、管理ディスクでは、上記の通り **リソース タイプ の一つとして提供されるため、Azure の RBAC の機能によって、詳細にアクセス制御を行う**ことが出来ます。

つまりこうなります。

**管理ディスクのアクセス制御**
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/4578ce9a-cb28-394d-4df7-cb3c53f323ec.png)

あえて、エクスポート操作をしない限り、**管理ディスクがエンドポイントを持つことはありません。**

ちなみに、管理ディスクのメニューを見ると、ちゃんとアクセス制御のメニューが出てきます。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/71981751-b4bd-4d93-8836-c8ee368e2391.png)

# 価格と課金
管理ディスクの料金のポイントをまとめてみました。

- ストレージの種類
    - SSD(Premium) と HDD(Standard) で料金が異なる
- ディスク サイズ
    - SSD も HDD も、**使用している実容量ではなく、管理ディスクとして確保した(プロビジョニングされた)容量**で課金される
        - 非管理ディスクは、HDD に関しては実容量ベースで課金されていました
    - SKU 毎に定められた容量よりも小さい場合は、切り上げて課金される
        - 例えば、50 GB の SSD を作成した場合、P6(64 GB)として課金される
- トランザクション数
    - HDD は、容量の課金以外にも、トランザクション数に対しても課金されます
        - これは 非管理ディスク と同じです。また、SSD の 管理ディスク はトランザクション数への課金はありません
- 送信データ転送
    - Azure データセンターから送信方向に対するトラフィックに対して課金される
        - これも 非管理ディスク と同じです。
- 管理ディスク スナップショット
    - 管理ディスクではスナップショットが作れます。スナップショットに対しては、使用している容量のみに対する課金になります。


以下は東日本の 管理ディスク の料金表です。
<font color="red">**※12/20 時点での料金となります。また、料金についてはあくまで参考値としていただき、正式には料金のページをご確認ください。**</font>

**HDD(Standard)**
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/673069e1-32ec-320a-7373-14ffa206404b.png)
※これ以外に、トランザクション 10,000 回あたり ¥0.051 の料金がかかります。

また、次は参考までに、非管理ディスクを管理ディスクのSKUに当てはめた時の料金です。
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/25324cf0-5be6-6d4a-21af-ea78d5754821.png)
※あくまでも参考値としてください。

上記の通り、管理ディスクの SKU と同じ容量を使用すると、管理ディスクの方が安くなります。


Azure 非管理対象ディスク ストレージの価格
https://azure.microsoft.com/ja-jp/pricing/details/storage/unmanaged-disks/

**SSD(Premium)**
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/e3c0ad9e-2a0f-c3b0-7a6b-b0503572d2ad.png)

最新の料金はこちらをご覧ください。

料金 - Managed Disks
https://azure.microsoft.com/ja-jp/pricing/details/managed-disks/

# ■ スナップショット・イメージ
管理ディスクでは、**スナップショット** や **イメージ** の機能を使うことが出来ます。
また、既存の 非管理ディスク から、管理ディスクを作成することも出来ます。

## イメージ
- ストレージ アカウントに保存された VHD を **"イメージ"** リソースとして作成
- イメージは他のストレージアカウントをまたいで(ただし同じリージョン)作成可能
- データ ディスク をイメージ化することが可能
- イメージから仮想マシンが作成可能
    - ただしリソース グループはイメージが存在するリージョンにのみが作成可能
    - イメージ化後は元になったVHDを削除可能

### イメージの作成
#### 1. 新規作成で Image を選択
![image](https://qiita-image-store.s3.amazonaws.com/0/132347/d18e69d6-a8c7-9f65-bc3a-f92b7c83bd99.png)

#### 2. [イメージの作成]画面でイメージ化したいVHDを指定
![image](https://qiita-image-store.s3.amazonaws.com/0/132347/6071cb52-628b-97e7-d145-f764bde1f1ef.png)

#### 3. イメージ化が完了
![image](https://qiita-image-store.s3.amazonaws.com/0/132347/21ad22a5-a847-91c9-dc10-ec5614a420a7.png)

### 仮想マシンの作成
作成したイメージを選択し、[VM の作成] をクリック。
あとはいつも通り仮想マシンを作成する。
※リソース グループはイメージと同じリージョンの必要あり

![image](https://qiita-image-store.s3.amazonaws.com/0/132347/cfef7a1f-281c-d6b7-f36a-d2ee68a630b1.png)


## スナップショット
- 既存の Managed Disk から作成
- スナップショットは 1ディスクのみが対象
- 複数のディスクをストライピングしている場合とかは考慮されない

### スナップショットの作成

#### 1. 新規作成で Snapshot を選択
![image](https://qiita-image-store.s3.amazonaws.com/0/132347/70ec4958-d711-9188-35da-9ef0d4d379eb.png)

#### 2. [スナップショットの作成]画面でイメージ化したいVHDを指定
![image](https://qiita-image-store.s3.amazonaws.com/0/132347/5a0cb8db-21e8-aa30-99f1-1fef3ff116ae.png)

### 仮想マシンの作成
スナップショットからの仮想マシンの作成は、スナップショットからディスクを作成してから仮想マシンを作成します。
詳細な手順は、サポートチームのブログで紹介されています。

管理ディスク (Managed Disks) スナップショットより VM をデプロイする
https://blogs.technet.microsoft.com/jpaztech/2017/05/02/deployvmfromsnapshot/

# ■ 非管理ディスクからの移行
非管理ディスクを使用している仮想マシンを管理ディスクに移行(変換)することが出来ます。

移行する場合、仮想マシンが、可用性セット構成かどうかで手順が変わります。

## :heavy_check_mark: 可用性セットを使用していない場合
可用性セットを使っていない場合はとても簡単です。

1. 仮想マシンの停止
1. 管理ディスクへの変換
1. 仮想マシンの開始

だけで完了します。

詳細な手順はこちらをご覧ください。

単一インスタンスの VM を変換する
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/convert-unmanaged-to-managed-disks#convert-single-instance-vms

## :heavy_check_mark: 可用性セットを使用している場合
可用性セットを使っている場合、可用性セットの SKU を変更する必要があります。

1. 仮想マシンの停止
1. 可用性セットのSKUの変更
1. 管理ディスクへの変換
1. 仮想マシンの開始

最初の方で書いたとおり、管理ディスクを使った可用性セットは、ストレージ スケール ユニットに則した構成をとる必要があるため、可用性セットに対しても変更を行う必要があります。

詳細な手順はこちらをご覧ください。

可用性セットの VM を変換する
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/convert-unmanaged-to-managed-disks#convert-vms-in-an-availability-set

## :question: 結局、管理ディスクを使った方がいいの？
ここまで、機能や移行方法について紹介してきましたが、実際問題、新規で仮想マシンを作る場合や、既に仮想マシンを使っている場合にわざわざ移行をした方がいいのか、という点が疑問になると思います。
お客様からもその様なご質問を頂いたことがありました。

結論としては、今後は管理ディスクを積極的に使っていった方がいいと思っています。

その理由の一つとして、**新機能への対応** があります。
例えば、現在プレビュー中の **Availability Zone** ですが、この機能を使うためには、管理ディスクが前提になっています。

Overview of Availability Zones in Azure (Preview)
https://docs.microsoft.com/en-us/azure/availability-zones/az-overview
![image.png](https://qiita-image-store.s3.amazonaws.com/0/132347/c753ecfe-20da-7db8-a168-38d13c0d8df2.png)

今後も、管理ディスクを使用していることが前提となる機能が出てくる可能性も考えられます。
もちろん新機能を見据えた理由以外で、単純にストレージの可用性向上の観点としても有効です。

:exclamation:Availability Zone とは...
1つのリージョンに存在する複数のデータセンターを跨いでロード バランサーを組むことができるなど、これまでよりもさらに信頼性を向上出来る仕組み

# ■ 管理ディスクに関する参考リンク

## Azure のドキュメント
Azure Managed Disks の概要
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/managed-disks-overview
Azure VM を Azure Managed Disks に移行する
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/migrate-to-managed-disks
Azure IaaS VM ディスクと Premium 管理ディスクおよび非管理ディスクについてよく寄せられる質問
https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/faq-for-disks
Managed Disks pricing
https://azure.microsoft.com/ja-jp/pricing/details/managed-disks/
Azure Disk Storage の価格
https://azure.microsoft.com/ja-jp/pricing/details/storage/unmanaged-disks/

## サポートチームによるブログ
管理ディスク (Managed Disks) のサブスクリプション間やリソース グループ間の移行について
https://blogs.technet.microsoft.com/jpaztech/2017/08/17/export-managed-disks-to-vhd/
サブスクリプション間で「イメージ」リソースをコピーする
https://blogs.technet.microsoft.com/jpaztech/2017/08/25/howtocopyimagebetweensubscriptions/
管理ディスク (Managed Disks) の “イメージ” リソースを使用し、仮想マシンを複数台展開する
https://blogs.technet.microsoft.com/jpaztech/2017/05/10/deployvmsfrommanagedimage/
管理ディスクを用いたLinuxのOSディスクを他の仮想マシンのデータディスクとして接続する方法
https://blogs.technet.microsoft.com/jpaztech/2017/10/19/attach-mgmtosdisk-to-otherlinuxvm/
管理ディスク (Managed Disks) スナップショットより VM をデプロイする
https://blogs.technet.microsoft.com/jpaztech/2017/05/02/deployvmfromsnapshot/
既存の VHD を管理ディスク (Managed Disk) に変換し、VM をデプロイする
https://blogs.technet.microsoft.com/jpaztech/2017/05/01/convertvhdtomanageddiskdeployvm/
リソース マネージャー (ARM) 環境で既存の VM を既存の可用性セットに追加する方法[管理ディスク編]
https://blogs.technet.microsoft.com/jpaztech/2017/12/11/addavasetvmarm-mng/

# ■ 最後に
これまで見てきたように、管理ディスクを使うことで、仮想マシンのディスクの展開や管理が柔軟になります。

仮想マシンへの新しい機能追加や更新、ストレージの可用性向上への対応として、ぜひ管理ディスクの利用・移行をご検討ください。