AzureのAvailability ZoneにLinux VMを分散配置する方法|az vm createのzoneオプションとゾーン冗長設計の実践

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > Azure > AzureのAvailability ZoneにLinux VMを分散配置する方法|az vm createのzoneオプションとゾーン冗長設計の実践
「本番のLinuxサーバーをAzureに移行したら、データセンター障害でサービスが全停止してしまった…」
「VMは動いているのに、ゾーン障害のたびにダウンする。何か設計が間違っているのか…」

こういった事態を防ぐのが Availability Zone(可用性ゾーン)です。AzureのVMをゾーン1・2・3の独立したデータセンターに分散配置することで、単一DC障害がサービス全体に波及するのを防ぎ、SLA 99.99% の可用性を実現できます。

この記事では、Availability Zone の仕組みから、az vm create の --zone オプションを使ったゾーン分散VM配置の実践手順、Standard Load Balancerとの組み合わせ、Availability Set との違い・AWSのAuto Scaling Groupとの設計思想の比較、トラブルシュートまで、実機ログを交えて解説します。動作確認環境は RHEL 9.4 / Ubuntu 22.04 LTS です。

この記事のポイント

・az vm create --zone で特定ゾーンにVMを配置し、SLA 99.99% を実現できる
・Zone 1~3 は同一リージョン内の独立した物理データセンターを指す
・ゾーン対応には Standard SKU の NIC・パブリックIPが必須(Basic SKU は2026年9月廃止)
・Standard Load Balancerと組み合わせることでゾーン間フェイルオーバーが自動化される
・Availability Set との違いは冗長化の範囲(ゾーン分散 vs 同DC内ラック分散)


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

AzureのAvailability Zoneとは(SLA 99.99%の仕組み)

Availability Zone(可用性ゾーン)は、同一 Azure リージョン内に存在する、物理的に独立したデータセンター群です。現在、東日本リージョン(japaneast)はゾーン1・2・3の3ゾーンをサポートしています。

各ゾーンの特徴は次のとおりです。

・独立した電源・冷却・ネットワーク:ゾーンごとに独立したインフラを持つため、1つのゾーンで障害が発生しても他のゾーンは影響を受けない
・ゾーン間遅延 2ms 未満:ゾーン間は高速専用ファイバーで接続されており、レイテンシは 2ms 未満を保証
・SLA 99.99%:2台以上のVMを別々のゾーンに配置することで、月間ダウンタイムを 4.38 分以内に抑えるSLAが適用される

単一VMだとSLA 99.9%、同一 Availability Set 内2VMだと 99.95% ですが、別ゾーンに分散した2VMで 99.99% に跳ね上がります。本番サービスで「ゾーン冗長」が標準になっているのはこの理由です。
構成 SLA 月間最大ダウンタイム
単一VM(Premium SSD) 99.9% 約 43.8 分
同一Availability Set内 2VM 99.95% 約 21.9 分
別Availability Zoneの 2VM 99.99% 約 4.38 分

ゾーン対応リソースの確認

Availability Zone を使うには、対象リージョンとVMサイズがゾーンをサポートしている必要があります。まず確認コマンドを実行します。

1. ゾーン対応VMサイズを確認する

# ログイン az login # 東日本リージョンでゾーン対応の Standard_D2s_v3 を確認 az vm list-skus --location japaneast --zone true \ --query "[?name=='Standard_D2s_v3'].[name,locationInfo[0].zones]" \ --output table # 出力例(ゾーン対応の場合) Name Zones ---------------- -------- Standard_D2s_v3 [1, 2, 3]

ゾーン列に [1, 2, 3] が表示されれば、そのVMサイズはゾーン対応です。ここに何も表示されない場合、そのサイズはゾーン指定不可です。

2. リソースグループを作成する

# リソースグループを作成 az group create --name rg-az-demo --location japaneast # 出力例 { "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-az-demo", "location": "japaneast", "name": "rg-az-demo", "properties": { "provisioningState": "Succeeded" } }

ゾーンを指定してLinux VMを作成する

ここでは2台のVMをそれぞれゾーン1・ゾーン2に分散配置します。ゾーン対応VMの作成には Standard SKU のパブリックIP が必要です(Basic SKU はゾーン非対応かつ2026年9月にサービス終了)。

1. VNetとサブネットを作成する

# VNetを作成(/16 アドレス空間) az network vnet create \ --resource-group rg-az-demo \ --name vnet-az-demo \ --address-prefix 10.0.0.0/16 \ --subnet-name subnet-main \ --subnet-prefix 10.0.1.0/24 # 出力例(抜粋) { "newVNet": { "addressSpace": {"addressPrefixes": ["10.0.0.0/16"]}, "name": "vnet-az-demo", "provisioningState": "Succeeded" } }

2. ゾーン1にVM-1を作成する

# ゾーン1にVM作成(--zone 1 を指定) az vm create \ --resource-group rg-az-demo \ --name vm-zone1 \ --image Ubuntu2204 \ --zone 1 \ --size Standard_D2s_v3 \ --vnet-name vnet-az-demo \ --subnet subnet-main \ --admin-username azureuser \ --generate-ssh-keys \ --public-ip-sku Standard # 出力例 { "fqdns": "", "id": "/subscriptions/xxx/resourceGroups/rg-az-demo/providers/Microsoft.Compute/virtualMachines/vm-zone1", "publicIpAddress": "20.xxx.xxx.10", "resourceGroup": "rg-az-demo", "zones": "1" }

注意:--public-ip-sku Standard を忘れずに指定してください。省略するとデフォルトの Basic SKU が割り当てられ、ゾーン指定と競合してエラーになります。Basic SKU の NIC にゾーン指定のVMを接続しようとすると VM 作成時点でエラーが返されます。

3. ゾーン2にVM-2を作成する

# ゾーン2にVM作成(--zone 2 を指定) az vm create \ --resource-group rg-az-demo \ --name vm-zone2 \ --image Ubuntu2204 \ --zone 2 \ --size Standard_D2s_v3 \ --vnet-name vnet-az-demo \ --subnet subnet-main \ --admin-username azureuser \ --generate-ssh-keys \ --public-ip-sku Standard # 出力例 { "publicIpAddress": "20.xxx.xxx.11", "resourceGroup": "rg-az-demo", "zones": "2" }

4. ゾーン割り当てを確認する

# vm-zone1 のゾーン確認 az vm show \ --resource-group rg-az-demo \ --name vm-zone1 \ --query "{name:name, zones:zones, location:location}" \ --output table # 出力例 Name Zones Location -------- ------- ---------- vm-zone1 1 japaneast # vm-zone2 のゾーン確認 az vm show \ --resource-group rg-az-demo \ --name vm-zone2 \ --query "{name:name, zones:zones, location:location}" \ --output table # 出力例 Name Zones Location -------- ------- ---------- vm-zone2 2 japaneast

zones 列に「1」「2」と表示されれば、それぞれのゾーンに正しく配置されています。SSH接続の確認については、Linux ポート確認の全コマンドも参考にしてください。

Standard Load BalancerとAvailability Zoneを組み合わせる

2台のVMをゾーンに分散配置しただけでは、片方のゾーンで障害が発生しても外部からの通信を自動で切り替えることはできません。フェイルオーバーを自動化するには、Azure Standard Load Balancerと組み合わせる必要があります。

・Basic SKU(廃止済み):2026年9月にサービス終了。Availability Zoneには非対応だった
・Standard SKU:Availability ZoneにもAvailability Setにも対応。99.99% SLAを保証

1. フロントエンド用パブリックIPとLoad Balancerを作成する

# フロントエンド用パブリックIP(Standard SKU)を作成 az network public-ip create \ --name pip-lb-az \ --resource-group rg-az-demo \ --sku Standard \ --allocation-method Static \ --location japaneast # Standard Load Balancerを作成 az network lb create \ --name lb-az \ --resource-group rg-az-demo \ --sku Standard \ --public-ip-address pip-lb-az \ --frontend-ip-name frontendip \ --backend-pool-name backendpool \ --location japaneast # ヘルスプローブ(TCPポート80で死活監視) az network lb probe create \ --name probe-http \ --resource-group rg-az-demo \ --lb-name lb-az \ --protocol Tcp \ --port 80 # 負荷分散ルール az network lb rule create \ --name rule-http \ --resource-group rg-az-demo \ --lb-name lb-az \ --protocol Tcp \ --frontend-port 80 \ --backend-port 80 \ --frontend-ip-name frontendip \ --backend-pool-name backendpool \ --probe-name probe-http

2. VMのNICをバックエンドプールに追加する

# vm-zone1のNIC名を取得 NIC_1=$(az vm show \ --name vm-zone1 \ --resource-group rg-az-demo \ --query "networkProfile.networkInterfaces[0].id" \ --output tsv | awk -F'/' '{print $NF}') # vm-zone1をバックエンドプールに追加 az network nic ip-config address-pool add \ --address-pool backendpool \ --ip-config-name ipconfig1 \ --nic-name "$NIC_1" \ --resource-group rg-az-demo \ --lb-name lb-az # vm-zone2のNIC名を取得 NIC_2=$(az vm show \ --name vm-zone2 \ --resource-group rg-az-demo \ --query "networkProfile.networkInterfaces[0].id" \ --output tsv | awk -F'/' '{print $NF}') # vm-zone2をバックエンドプールに追加 az network nic ip-config address-pool add \ --address-pool backendpool \ --ip-config-name ipconfig1 \ --nic-name "$NIC_2" \ --resource-group rg-az-demo \ --lb-name lb-az

3. バックエンドプールの登録状態を確認する

az network lb address-pool show \ --name backendpool \ --resource-group rg-az-demo \ --lb-name lb-az \ --query "backendIpConfigurations[].id" \ --output table # 出力例 Result -------------------------------------------------------------------------------- /subscriptions/xxxx/resourceGroups/rg-az-demo/.../vm-zone1/ipconfig1 /subscriptions/xxxx/resourceGroups/rg-az-demo/.../vm-zone2/ipconfig1

2台のVMがバックエンドプールに登録されれば、Standard Load Balancer+Availability Zoneの構成が完成です。ゾーン1のVMが応答しなくなると、LBのヘルスプローブが検知して自動的にゾーン2のVMへトラフィックを切り替えます。

2台のVMをゾーン1・ゾーン2に分散配置することで、ゾーン障害時のサービス継続を準備できます。AzureクラウドでのLinuxサーバー設計・構築スキルを体系的に習得したい方は、Azure対応セミナーの詳細もご覧ください。

Availability ZoneとAvailability Setの違いと使い分け

「Availability Zone と Availability Set の違いがよく分からない」という声をよく聞きます。どちらも冗長化のための機能ですが、分散の粒度が根本的に異なります。

障害ドメイン(FD)と更新ドメイン(UD)の仕組み

Availability Set を理解するには、まず「障害ドメイン(Fault Domain、FD)」と「更新ドメイン(Update Domain、UD)」の概念を押さえておく必要があります。

Azureのデータセンター内では、複数のサーバーが物理ラックに分かれて配置されています。同じラックに収まる複数台のVMは、そのラックの電源装置やネットワークスイッチが故障すると同時に影響を受けます。この物理ラック単位のグループが「障害ドメイン(FD)」です。japaneastリージョンでは最大2つの障害ドメインを利用できます。

一方、Microsoftがゲストハイパーバイザーのパッチ適用や基盤メンテナンスを行う際には、グループ単位でホストを順番に再起動します。このグループが「更新ドメイン(UD)」です。最大20個まで設定でき、UDをまたいだ再起動の間にインターバルが設けられているため、全台同時停止を防げます。

Availability Set を設定しておくと、グループ内のVMをAzureが自動的に異なるFDとUDへ分散して配置します。2台のWebサーバーを同一Availability Setに入れておけば、片方が計画メンテナンスで再起動中もサービスを維持できます。次のコマンドで各VMのFD番号を確認できます。

# VMが割り当てられた障害ドメイン番号を確認 az vm get-instance-view \ --name vm-web-01 \ --resource-group rg-avset-demo \ --query "instanceView.platformFaultDomain" \ --output tsv # 出力例(FD 0 に配置されている場合) 0

Availability ZoneとAvailability Setの比較

Availability Zoneの冗長化の仕組み
ゾーン単位(独立したデータセンター)で分散します。ゾーン間は物理的に数km離れた場所に設置されており、電源・冷却・ネットワーク設備がすべて独立しています。施設単位の障害(停電・自然災害)にも対応できますが、データセンター間のネットワーク遅延が数ms発生します。

Availability Setの冗長化の仕組み
同じデータセンター内のラック単位(Fault Domain)とメンテナンス計画(Update Domain)で分散します。VM間のレイテンシは最小化されますが、施設全体の障害(停電・自然災害)には対応できません。
項目 Availability Zone Availability Set
分散単位 ゾーン(独立したDC) 障害ドメイン・更新ドメイン(同DC内)
SLA 99.99%(2VM以上) 99.95%(2VM以上)
対応SKU Standard必須 Standard対応(BasicはLegacy環境のみ)
ゾーン対応リージョン 東日本・西日本等(要確認) すべてのリージョン
VM間レイテンシ 数ms(ゾーン間) 最小(同一DC内)
主なユースケース 本番サービスの高可用性 ゾーン未対応リージョンの冗長化
ゾーン対応リージョン(東日本など)では Availability Zone を優先してください。ゾーン未対応リージョンやレガシー構成が残る場合のみ Availability Set を選択します。

AWSのAuto Scaling GroupとAvailability Setの設計思想の違い

AWSから入ったエンジニアが「Azure の Availability Set は Auto Scaling Group に相当するのか」と問うことがあります。答えは「目的が根本的に異なる」です。

AWS Auto Scaling Group(ASG)は、需要変動に応じてEC2インスタンスを自動的に増減させるためのリソースです。最小台数・最大台数・希望台数を設定し、CPUやリクエスト数のメトリクスに応じてスケールアウト・スケールインします。ASGの中で複数AZにまたがった配置を指定することで可用性を担保しますが、「スケーリング」が主目的であることに変わりはありません。

一方、Azure Availability Setは「一定台数のVMを物理的に分散配置する」ための静的なグルーピング機能です。自動的にVMを増減させる仕組みを持たず、台数は固定運用が前提です。AzureでASGに相当するスケーリング機能が必要な場合は、Virtual Machine Scale Sets(VMSS)を使います。
比較項目 AWS Auto Scaling Group Azure Availability Set
主目的 インスタンス数の自動スケーリング VM群の物理分散配置(冗長化)
台数制御 自動(メトリクス連動)または手動 手動のみ(固定台数運用)
分散レベル 複数AZにまたがる配置も可 単一データセンター内のラック分散(FD)
AWSの近似機能 — Spread Placement Group(概念が近い)
Azureの近似機能 Virtual Machine Scale Sets(VMSS) —
後付け設定 稼働中のインスタンスをASGに追加可 既存VMへの後付け不可

Availability Setの制約と注意点

Availability Setを運用前に知っておくべき制約を整理します。

・後付け適用不可:すでに作成済みのVMをAvailability Setに後から移すことはできません。VM作成時に --availability-set を指定することが唯一の方法です
・Availability ZoneとAvailability Setは排他:1台のVMに両方を同時に設定することはできません。Zoneが利用できるリージョンではAvailability Zoneを優先することをMicrosoftが推奨しています
・VMサイズは統一推奨:同一Availability Set内では原則として同じVMサイズを使います。サイズが異なると、計画メンテナンス後に希望サイズが確保できないケースがあります
・障害ドメイン数の上限はリージョン依存:japaneastでは最大2、East USなど一部のリージョンでは最大3まで指定できます。上限は az vm list-skus で事前に確認してください

なお、VMSSを使った自動スケールと組み合わせた高可用性構成については「AzureのVMSSとLoad Balancerで高可用性を実現する方法」も参考にしてください。

トラブルシュート

1. 「The requested VM size is not available in the current region/zone」エラーが出る場合

指定したVMサイズが、そのゾーンで利用できない場合に発生します。

# エラー例 (SkuNotAvailable) The requested VM size Standard_D2s_v3 is not available in the current region/zone. # 対処: そのゾーンで使えるSKUを確認する az vm list-skus --location japaneast --zone true \ --query "[].{Name:name, Zones:locationInfo[0].zones}" \ --output table | head -30

出力の Zones 列を確認し、目的のゾーン番号が含まれているSKUを選択してください。

2. 「Basic SKU のパブリックIPはゾーン指定と互換性がない」エラーが出る場合

--public-ip-sku を省略または Basic にした場合に発生します。Basic SKU は2026年9月にサービス終了しているため、新規構築では必ず Standard を指定してください。

# エラー例 (PublicIpSkuMismatch) The public IP address associated with the NIC has a different SKU than the load balancer. # 対処: Standard SKU を明示する az vm create \ --zone 1 \ --public-ip-sku Standard \ ...

3. az vm create 後に zones フィールドが空の場合

--zone を指定しても zones が空になることがあります。多くの場合、Azure Portal や az vm show でのクエリパス指定ミスが原因です。

# zones が正しく取得できるコマンド az vm show --resource-group rg-az-demo --name vm-zone1 \ --query "zones" --output tsv # 出力例(正常) 1

4. 「AvailabilitySetMismatch」エラーでVM作成が失敗する場合

Availability Setを指定したVM作成時に次のエラーが出ることがあります。

# エラー例 (AvailabilitySetMismatch) The specified availability set is in a different location than the virtual machine. # 対処: Availability SetのリージョンとVMのリージョンを一致させる az vm availability-set show \ --name avset-web \ --resource-group rg-az-demo \ --query "location" --output tsv

Availability SetとVMの --location が一致していない場合に発生します。az vm availability-set show で location フィールドを確認し、VM作成コマンドの --location と一致させてください。

本記事のまとめ

やりたいこと コマンド
ゾーン対応VMサイズを確認する az vm list-skus --location japaneast --zone true --query "[?name=='Standard_D2s_v3']"
ゾーン1にVMを作成する az vm create --zone 1 --public-ip-sku Standard --size Standard_D2s_v3 ...
ゾーン2にVMを作成する az vm create --zone 2 --public-ip-sku Standard --size Standard_D2s_v3 ...
VMのゾーン割り当てを確認する az vm show --resource-group <RG> --name <VM名> --query zones
ゾーン対応SKUを絞り込む az vm list-skus --location japaneast --zone true --output table
Standard Load Balancerを作成する az network lb create --sku Standard --public-ip-address <IP名> ...
VMをLBバックエンドプールに追加する az network nic ip-config address-pool add --address-pool <プール名> ...
VMの障害ドメイン番号を確認する az vm get-instance-view --name <VM名> --resource-group <RG> --query "instanceView.platformFaultDomain"
Azure の Availability Zone を活用すれば、単一データセンターの障害からサービスを守り、SLA 99.99% の可用性を実現できます。Standard Load Balancerと組み合わせることで、ゾーン障害時のフェイルオーバーが自動化され、真の高可用性構成が完成します。Availability Setとの違いや、AWSのAuto Scaling Groupとの設計思想の違いを整理した上で、リージョン選定の段階から適切な冗長化方式を選んでください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、20年以上の運用経験を持つ現役エンジニアが基礎から教えます。
Azure対応セミナーの詳細を見る >>

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。