Azureの仮想マシンを削除する(ARM, 管理ディスク)
こちらの記事は、Qiita に掲載した Microsoft Azure Tech Advent Calendar 2017 の企画に基づき、執筆した内容となります。
カレンダーに掲載された記事の一覧は、こちらよりご確認ください。
こんにちは、Azureサポートチームの三國です。
今回は、Azureの仮想マシンを削除する方法についてご案内します。Advent Calendar企画ということで、年末の大掃除にご活用頂ければ幸いです。
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。
目次
1. はじめに: 仮想マシンの削除とは
2. 注意事項
3. 仮想マシンの削除方法
4. ディスクの削除方法
5. ネットワークの削除方法
6. 診断用ストレージアカウントの削除方法
7. 削除しやすい仮想マシンの管理方法の例
1. はじめに: 仮想マシンの削除とは
仮想マシンの削除は、実に簡単です。削除したい仮想マシンビューを開き、削除をクリックするだけです。
しかしながら、それだけでは色々と他のリソースが残ってしまいます。
ディスクや、ネットワークインターフェースまで削除したい場合は、大変お手数をおかけしますがそれぞれを削除頂く必要がございます。
これらを削除しないとディスクの容量や、パブリックIPアドレスがある場合はパブリックIPアドレスに対する課金が発生します。
課金に対する考え方は、こちらのブログをご参照ください。
※ご参考
大雑把なイメージとして、「仮想マシン」はCPUとメモリだけだと思ってください。OSのイメージはディスクの中に入っています。
それにディスクやネットワークインターフェースといったリソースを紐づけることで初めて「実行中」となります。
逆に言えば、「停止済み(割り当て解除)」の時はCPUとメモリを所有していない状態になります。イメージ図として仮想マシンの「ダイアグラム」をご紹介します。
このようにリソースをバラバラに扱うことで、仮想マシンが「停止済み(割り当て解除)」の時は仮想マシンに対する課金が発生しない、という風に考えることもできます。
2. 注意事項
-仮想マシンを削除しただけならば、ディスクから仮想マシンが再作成できますが、ディスクも削除した場合はデータなどの復元はできません。削除する際は十分にご注意ください。
-「診断用ストレージアカウント」は複数の仮想マシンの診断ログを格納できます。削除対象でない仮想マシンの診断ログも格納している場合がございますので削除する際には十分にご注意ください。診断用ストレージアカウントがないと仮想マシンは起動に失敗します。
-今回のブログでは見やすさのためにARMモデル、管理ディスクを利用の場合を記載いたします。そうでない場合も、概念を理解することにお役立て頂けるかと存じます。
3. 仮想マシンの削除方法
前述の通り、仮想マシンの削除は簡単です。
削除する前に、ディスク名、ネットワークインターフェース名、診断用ストレージアカウント名を確認しましょう。診断用ストレージアカウントはない場合もあります。
4. ディスクの削除方法
3. で調べたディスク名を選択し、削除します。ディスクを削除するとデータの復旧ができませんのでご注意ください。
5. ネットワークの削除方法
まずはネットワークインターフェースを削除します。その際にパブリックIPアドレス名を確認しましょう。
次に、パブリックIPアドレスを削除します。
仮想ネットワークは、配下にネットワークインターフェースがいなければ削除できます。下記のようにいる場合は削除できないのでご注意を。
後は、ネットワークセキュリティグループも不要なら削除しておきましょう。
6. 診断用ストレージアカウントの削除方法
前述しましたが、「診断用ストレージアカウント」は複数の仮想マシンの診断ログを格納できます。削除対象でない仮想マシンの診断ログも格納している場合がございますので削除する際には十分にご注意ください。診断用ストレージアカウントがないと仮想マシンは起動に失敗します。
問題なければ、ストレージアカウントを削除します。
7. 削除しやすい仮想マシンの管理方法の例
ここまでご覧頂きました通り、仮想マシンの削除はそれなりに手間がかかる作業です。
リソースグループごと削除することで、まとめての削除が可能です。
この章では最小単位でリソースグループをまとめる方法をご案内します。今後仮想マシンを作成される際などにご参考として頂ければと存じます。
以下は、仮想ネットワークと診断用ストレージアカウントを1つのリソースグループにまとめ、可用性セットごとにリソースグループを作成した例です。シングル構成のサーバはサーバごとのリソースグループとなっています。
例えばWebシステムでしたら、複数台あるWebサーバ、DBサーバごとに可用性セットに入れてリソースグループでくくり、シングル構成のSSH用の踏み台サーバは単一でリソースグループに入れる、などが考えられます。仮想ネットワークは複数の仮想マシンが入り得るのでリソースグループを別出しにし、診断用ストレージアカウントも誤って削除することを予防するために別出しにしました。
もちろん上記は「最小」の考え方ですので、「システムごとにリソースグループを作成し、サービスが終了となったらまとめて削除」といった考え方もあるかと思います。
おわりに
Azureのサービスが開始されてから相当の年月が経ち、長期間ご愛顧頂いているお客様も多いかと存じます。
不要なリソースを削除された後も、是非新しいAzureリソースを利用したビジネスを行って頂けますと幸いです。