Azure VM入門 仮想マシン作成とネットワーク設定の基礎

「Azureで仮想マシンを立てたいけれど、設定画面の項目が多すぎて何を選べばいいかわからない」——オンプレのVMware環境からクラウドへ移行する段階で、多くのインフラ担当者がぶつかる壁です。

オンプレであれば、ESXiにISOをマウントしてOSをインストールし、vSwitchでネットワークを組めば済みました。しかしAzureでは、仮想マシン本体に加えてVNet・サブネット・NSG・パブリックIPといった複数のリソースが絡み合います。

この記事では、Azure Virtual Machines（Azure VM）の基本概念から仮想マシンの作成手順、ネットワーク設定、料金体系まで、オンプレ経験者が押さえるべきポイントを体系的に解説します。

なぜAzure VMなのか？オンプレ仮想基盤との違い

オンプレの仮想化環境では、VMware vSphereやHyper-Vでハイパーバイザーを構築し、その上にVMを載せるのが一般的です。ホストのCPU・メモリ・ストレージを事前に調達し、キャパシティプランニングを行ったうえでVMを配置する。この運用に慣れている方も多いでしょう。

Azure VMは、この仮想化基盤をMicrosoftが運用してくれるサービスです。主な違いを整理します。

・物理ホストの管理が不要: ハイパーバイザーの更新やホスト障害への対応はMicrosoftが行う。インフラ担当者はVM内のOS・ミドルウェアに集中できる
・スケールの柔軟性: オンプレでは物理サーバーの追加に数週間かかったが、Azure VMなら数分でデプロイできる。不要になれば即座に削除して課金を止められる
・VMサイズの変更が可能: CPUやメモリが足りなくなったら、VMを停止してサイズを変更するだけ。物理サーバーのスペック変更のような大作業は不要
・グローバル展開: 東日本リージョン（Japan East）・西日本リージョン（Japan West）をはじめ、世界60以上のリージョンに数クリックでVMを配置できる

オンプレの仮想基盤が「自社のデータセンターに置く仮想化サーバー」だとすれば、Azure VMは「Microsoftのデータセンターを間借りして使う仮想サーバー」です。ハードウェア管理から解放される代わりに、Azureのリソース構造を理解する必要があります。

Azure VMの作成手順

1. リソースグループを理解する

Azureでは、すべてのリソースが「リソースグループ」に所属します。オンプレでいえば、vSphereのフォルダやクラスタに相当する管理単位です。

リソースグループの命名規則は、実務では「rg-用途-環境」の形が定番です。たとえば「rg-webapp-prod」「rg-batch-dev」のように名付けると、一覧表示した際に何の環境かすぐに判別できます。

2. Azureポータルから仮想マシンを作成する

1. Azureポータル（https://portal.azure.com）にサインインし、「仮想マシン」→「作成」→「Azure仮想マシン」を選択
2. リソースグループを選択または新規作成
3. 仮想マシン名を入力（例: vm-web-prod-001）
4. リージョンを選択。国内向けサービスなら「Japan East（東日本）」が基本
5. イメージを選択。Linux系ならUbuntu Server 22.04 LTSまたはRed Hat Enterprise Linux 9が一般的
6. VMサイズを選択。検証用途なら「Standard_B2s」（2 vCPU / 4 GBメモリ）で十分
7. 認証方式は「SSH公開キー」を選択。パスワード認証はセキュリティ上推奨されない
8. ディスクはOS用にPremium SSD（P10: 128 GB）がバランスが良い
9. ネットワーク設定はデフォルトでVNetとサブネットが自動作成される。本番環境では事前に設計したVNetを選択する
10. 「確認および作成」→「作成」でデプロイが開始される。通常2〜3分で完了

3. Azure CLIでVMを作成する

繰り返しのデプロイや自動化にはCLIが適しています。

# リソースグループの作成（Azure CLI）
az group create \
  --name rg-webapp-prod \
  --location japaneast

# 仮想マシンの作成
az vm create \
  --resource-group rg-webapp-prod \
  --name vm-web-prod-001 \
  --image Ubuntu2204 \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

# VMの状態確認
az vm show \
  --resource-group rg-webapp-prod \
  --name vm-web-prod-001 \
  --show-details \
  --output table

# VMの停止（課金を止める場合は deallocate）
az vm deallocate \
  --resource-group rg-webapp-prod \
  --name vm-web-prod-001

ここで注意すべきは「停止」と「割り当て解除（deallocate）」の違いです。Azureポータルから「停止」を押すとdeallocateされますが、CLIで`az vm stop`を実行するとOS停止のみでコンピューティング課金が継続します。課金を止めたい場合は必ず`az vm deallocate`を使ってください。

ネットワーク設定の基本

Azure VMのネットワーク構成は、オンプレの物理ネットワークとは考え方が異なります。ここでは実務で必須の要素を押さえます。

1. VNet（仮想ネットワーク）とサブネット

VNetはAzureにおけるプライベートネットワークです。オンプレでいえば、社内LANのネットワークセグメントに相当します。

VNetを作成する際にアドレス空間（例: 10.0.0.0/16）を指定し、その中にサブネット（例: 10.0.1.0/24）を切ります。オンプレでVLANを設計した経験があれば、同じ感覚でサブネット分割ができるはずです。

実務でよくある構成例を紹介します。

・Webサブネット（10.0.1.0/24）: パブリックIPを持つフロントエンドVM用
・Appサブネット（10.0.2.0/24）: アプリケーションサーバー用。インターネットからの直接アクセスは不可
・DBサブネット（10.0.3.0/24）: データベースサーバー用。Appサブネットからのみアクセスを許可

2. NSG（ネットワークセキュリティグループ）

NSGはAzureのファイアウォール機能です。オンプレでいえば、iptablesやファイアウォール機器のACLに相当します。

受信ルールと送信ルールをそれぞれ設定でき、優先度（100〜4096の数値。小さいほど優先）・送信元・宛先・ポート・プロトコル・許可/拒否を指定します。

# SSH（ポート22）を特定IPからのみ許可する（Azure CLI）
az network nsg rule create \
  --resource-group rg-webapp-prod \
  --nsg-name vm-web-prod-001-nsg \
  --name AllowSSH \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 203.0.113.10/32 \
  --destination-port-ranges 22

# HTTP（ポート80）を全体に公開する
az network nsg rule create \
  --resource-group rg-webapp-prod \
  --nsg-name vm-web-prod-001-nsg \
  --name AllowHTTP \
  --priority 110 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes '*' \
  --destination-port-ranges 80

NSGはサブネットとNIC（ネットワークインターフェース）の両方にアタッチできます。実務では、共通ルールをサブネットレベルのNSGに、VM固有のルールをNICレベルのNSGに設定するのが管理しやすい構成です。

料金の仕組み

Azure VMの料金は主に3つの要素で構成されます（2026年3月時点、東日本リージョン）。

オンプレでは物理サーバーの減価償却とデータセンターの電気代が固定費としてかかりましたが、Azure VMは使った時間だけの従量課金です。ただし、ディスクとパブリックIPはVMを停止しても課金が続く点に注意してください。

コスト最適化のポイントは以下の通りです。

・Reserved Instances（予約インスタンス）: 1年または3年の利用確約で最大72%割引。本番環境の常時稼働VMに最適
・Azure Spot VM: 余剰キャパシティを最大90%割引で利用できる。ただしAzure側の都合で突然回収される可能性があるため、バッチ処理やCI/CDなど中断可能なワークロード向け
・Azure Hybrid Benefit: 既存のWindows ServerやSQL Serverライセンスをそのまま持ち込むことで、ライセンス料金分を節約できる。オンプレからの移行時に特に有利
・自動シャットダウン: 開発・検証用VMには自動シャットダウンを設定して夜間・休日の無駄な課金を防止する

応用・実務Tips

可用性セットと可用性ゾーン

オンプレでは、物理サーバーの障害に備えてHA構成（vSphere HAやクラスタリング）を組んでいたはずです。Azureでは「可用性セット」と「可用性ゾーン」がその役割を担います。

・可用性セット: 同一データセンター内で、VMを異なる障害ドメイン・更新ドメインに分散配置する。SLA 99.95%
・可用性ゾーン: 東日本リージョン内の物理的に離れた3つのデータセンター（ゾーン1/2/3）にVMを分散配置する。SLA 99.99%

本番環境のWebサーバーであれば、可用性ゾーンを使って2台以上のVMを異なるゾーンに配置し、Azure Load Balancerで負荷分散するのが推奨構成です。

カスタムイメージで構成をテンプレート化する

オンプレのVMテンプレートと同様に、設定済みVMからカスタムイメージを作成できます。VMを一般化（sysprepまたはwaagent -deprovision）→イメージをキャプチャ→新VMを作成する流れです。Azure Compute Galleryでバージョン管理やリージョン間レプリケーションも可能です。

Azure Monitorで監視を設定する

オンプレのZabbixやNagiosに相当するのがAzure Monitorです。VM作成時に「ブート診断」を有効にしておくと、OS起動失敗時のトラブルシューティングに役立ちます。CPU使用率・ディスクIOPS・ネットワーク帯域のメトリクスはデフォルトで収集されるため、アラートルールで閾値超過時のメール通知を設定しておくと安心です。

よくあるトラブルと対処法

SSHで接続できない

Azure VMで最も多いトラブルです。原因を切り分けるチェックポイントは以下の通りです。

1. NSGの受信ルールでポート22が許可されているか確認する
2. 送信元IPアドレスの制限が正しいか確認する。自宅やオフィスのIPが変わっている場合がある
3. VMが「実行中」状態であることを確認する。deallocate状態ではアクセスできない
4. Azureポータルの「接続のトラブルシューティング」機能でネットワーク到達性を診断する

それでも接続できない場合は、Azureポータルの「シリアルコンソール」からVM内部にアクセスして、OS側のファイアウォール（firewalld/ufw）の設定を確認してください。

VMサイズの変更に失敗する

VMサイズの変更時に「AllocationFailed」エラーが出ることがあります。これは、VMが配置されている物理クラスタに希望のサイズに対応するキャパシティがない場合に発生します。

対処法は、一度VMをdeallocateしてからサイズを変更することです。deallocateにより物理クラスタの制約が外れ、リージョン内の別クラスタに再配置されます。ただし、パブリックIPアドレスがDynamic設定の場合は変更されるため、Static IPの利用を推奨します。

ディスクのIOPSが足りない

Standard HDDやStandard SSDを選んでいると、IO負荷の高いワークロードでレスポンスが著しく低下することがあります。オンプレでRAID 10を組んでIOPSを稼いでいた環境の移行では、Premium SSDまたはUltra Diskを検討してください。

ディスクのIOPS上限はサイズによって決まります。Premium SSD P30（1 TB）であれば5,000 IOPSが上限です。現在のIOPS消費はAzure Monitorの「Data Disk IOPS Consumed Percentage」メトリクスで確認できます。

本記事のまとめ

Azure VMは、オンプレの仮想化基盤から最も移行しやすいAzureサービスの一つです。まずはStandard_B2sサイズでUbuntuのVMを1台作成し、SSHで接続してみてください。ESXiやHyper-VでVMを作成するのと同じ感覚で操作できることが実感できるはずです。

ネットワーク設定で最初に押さえるべきは、NSGで必要なポートだけを開放し、SSHのアクセス元IPを限定することです。オンプレのファイアウォールと同じく、「まず全部拒否、必要な分だけ許可」の原則を徹底してください。AWSとの機能比較については、今後の記事で詳しく取り上げる予定です。Linuxサーバーの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。