Azureの可用性セットとは？仕組みや可用性ゾーンとの違い、使い方を解説

Azureの可用性セット（Availability Set）は、仮想マシン（VM）を障害ドメインと更新ドメインに分散配置し、計画メンテナンスやハードウェア障害によるサービス停止を防止する機能です。本記事では、2026年最新の可用性ゾーンやVMSS Flexibleとの比較を踏まえ、仕組み・作成手順・選定判断までを体系的に解説します。
Azureとは？入門者向けにできること、凄い点、使い方を徹底解説

Azureの可用性セットとは（2026年最新ガイド）

可用性セットイメージ

Azureの可用性セット（Availability Set）は、複数の仮想マシン（VM）を障害ドメインと更新ドメインに分散配置し、ハードウェア障害や計画メンテナンス時にもサービスを継続させるための機能です。可用性セット自体に追加料金はかからず、VMの通常料金のみでSLA 99.95%の高可用性を実現できます。

以下のテーブルで、可用性セットの基本仕様を整理しました。

項目	内容
保護対象	単一データセンター内の物理障害（ラック・電源・ネットワークスイッチ）
SLA	99.95%（2台以上のVM配置時）
障害ドメイン（FD）	最大3（リージョンにより2）
更新ドメイン（UD）	最大20（デフォルト5）
VM上限	200台
料金	無料（VM料金のみ）

SLA 99.95%は年間ダウンタイム換算で約4時間23分に相当します。これはMicrosoftが保証する稼働率であり、適切にFDとUDを設計した2台以上のVM配置が条件となります。

2026年3月時点で、可用性セットは引き続きサポートされていますが、Microsoftによる新機能追加は2019年で停止しています。公式ドキュメントでは、高可用性と最も幅広い機能のためにVMSS Flexible Orchestrationを選択することが推奨されています。AKS（Azure Kubernetes Service）では2025年9月30日に可用性セットが完全廃止され、VM node poolsへの移行が必須となりました。

ただし、可用性設計を怠るとビジネスに深刻な影響が生じます。可用性セットもゾーンも設定しない単一VMでは、ハードウェア障害時にサービスが全停止します。また、可用性セットは単一データセンター内の保護に限定されるため、データセンター全体の障害やリージョン障害には対応できません。後述する可用性ゾーン（SLA 99.99%）との比較を理解した上で、ワークロードに適したデプロイ方式を選定することが重要です。

更新ドメインと障害ドメインの仕組み

可用性セットの中核となるのが、更新ドメイン（Update Domain）と障害ドメイン（Fault Domain）という2つの分散メカニズムです。以下のテーブルで両者の違いを比較しました。

項目	更新ドメイン（UD）	障害ドメイン（FD）
目的	計画メンテナンス時の影響最小化	ハードウェア障害時の影響局所化
最大数	20（デフォルト5）	3（リージョンにより2）
保護対象	OS更新・ホストメンテナンスによる再起動	電源・ネットワークスイッチの共有障害
動作	UDごとに順次再起動（同時には1つのUDのみ）	FDごとに物理的に異なるラックに配置

ドメインイメージ (参考：Microsoft)

更新ドメインは、Azureが計画メンテナンスを実行する際に、一度にすべてのVMを停止するのではなく、UDごとに順番に再起動する仕組みです。たとえば5つのUDに10台のVMを配置した場合、メンテナンス時には2台ずつが順次再起動され、残りの8台は稼働を継続します。Microsoftの公式ガイドラインでは、2台以上のVMを可用性セットに配置することが推奨されており、1台が停止しても他のVMがワークロードを引き継げる構成が基本です。

障害ドメインは、VMを物理的に異なるラック（電源・ネットワークスイッチが独立）に配置する仕組みです。同じFD内のVMは共通のハードウェアインフラを共有するため、1つのラック障害が発生するとそのFD内の全VMに影響しますが、他のFDのVMは正常に稼働を続けます。Azureは同じFD内のVMであっても異なるUDに配置するため、メンテナンスと障害の両方からVMを保護する多層防御を実現しています。

可用性セットの作成手順と注意点

Azure Portalから可用性セットを作成するには、VM作成時に「可用性オプション」で「可用性セット」を選択します。以下のスクリーンショットでPortalの設定画面を確認できます。

Azureポータル画面

まずリソースグループを選択し、仮想マシンの作成画面に進みます。

リソースの作成画面

「基本」タブでサブスクリプション、リソースグループ、仮想マシン名、リージョンを設定し、可用性オプションから「可用性セット」を選択します。

基本タブ

「新規作成」をクリックし、可用性セット名・障害ドメイン数・更新ドメイン数を指定します。

新規作成ボタン

イメージとVMサイズを選択し、認証情報を設定します。

基本タブ入力画面

基本タブ入力画面２

ディスクとネットワークの設定を行います。VNetとサブネットの選択、負荷分散オプションの設定が含まれます。

ディスク設定画面

ディスクタブ

ネットワークタブ

すべての設定を確認し、「確認および作成」をクリックしてデプロイを実行します。

確認および作成ボタン

可用性セットの作成にあたっては、以下の制約を押さえておく必要があります。可用性セットはVM作成時にのみ設定可能で、既存VMへの後追加はできません。RBACによるアクセス制御を適切に設定し、可用性セットの構成変更が意図せず行われないよう管理することも重要です。既存VMを可用性セットに移動するには、VMを一度削除してから可用性セットを指定して再作成する必要があります。また、可用性セット内のVMは同一のVMサイズファミリーに属している必要があり、作成後にFD/UDの構成を変更することもできません。

可用性セットと可用性ゾーン・VMSS Flexibleの比較

2026年3月時点で、Azureは可用性セット・可用性ゾーン・VMSS Flexible Orchestrationの3つのデプロイ方式を提供しています。以下のテーブルで主要な違いを比較しました。

項目	可用性セット	可用性ゾーン	VMSS Flexible
保護対象	単一DC内の物理障害	データセンター全体の障害	DC障害+自動スケーリング
SLA	99.95%	99.99%	99.95%（FD分散）/ 99.99%（マルチゾーン）
スケール上限	200台	リージョン依存	最大1,000台
自動スケーリング	非対応	非対応（単体）	対応（スケールイン/アウト）
ローリングアップグレード	非対応	非対応（単体）	対応
対応リージョン	全リージョン	AZ対応42リージョン以上	AZ対応リージョン
新機能追加	2019年で停止	継続中	継続中（推奨）

この比較で最も重要な点は、SLAの差です。可用性セットの99.95%は年間約4時間23分のダウンタイムを許容するのに対し、可用性ゾーンの99.99%は年間約52分に抑えられます。ミッションクリティカルなワークロードでは、この差がビジネス損失に直結します。

VMSS Flexible Orchestrationは、2023年11月以降のPowerShell/CLIでのデフォルトモードとなっており、Microsoftが最も推奨するデプロイ方式です。可用性セットの機能をすべて包含した上で、自動スケーリング・ローリングアップグレード・Spotインスタンスとの混在・Linux/Windows混在などの高度な機能を提供します。ただし、可用性セットからVMSS Flexibleへの自動移行ツールは存在しないため、新規Flexible Scale Setを同じリソースグループとVNetに作成し、トラフィックを段階的に移行する手動プロセスが必要です。

2026年のデプロイ方式選定ガイド

デプロイ方式の選定は、ワークロードの要件とリージョンの対応状況に基づいて判断します。2026年3月時点で可用性ゾーン対応リージョンは42以上に拡大しており、Japan EastとJapan Westの両方がAZ対応済みです。そのため日本国内のワークロードでは、新規デプロイには可用性ゾーンまたはVMSS Flexible（マルチゾーン）の選択が基本方針となります。

可用性セットが依然として有効な場面は限定的です。AZ非対応リージョンでのデプロイ、VM間の超低レイテンシが必要な場合（同一データセンター内配置）、または既存の可用性セットベースアーキテクチャを維持する場合に限られます。新規プロジェクトでAZ対応リージョンを使用する場合は、可用性セットを選択する合理的な理由はほとんどありません。

単一VMの場合でも、Premium SSDまたはUltra Diskを使用すればSLA 99.9%（年間約8時間44分）が適用されます。Standard SSDではSLA 99.5%、Standard HDDではSLA 95%となるため、ディスク選択もSLAに影響する重要な設計要素です。

可用性セットのメリットと導入判断

可用性セットは追加コスト不要で高可用性を実現できる一方、いくつかの制約も存在します。以下のテーブルでメリットと制約を整理しました。

メリット	制約
追加料金なしで99.95% SLAを確保	データセンター全体の障害には非対応
計画メンテナンス時のダウンタイム最小化	VM作成後の後追加不可
同一DC内配置による低レイテンシ通信	VMサイズファミリーの統一が必要
シンプルな設定で即座に高可用性を実現	200台のスケール上限
ディスク暗号化やマネージドディスクとの互換性	自動スケーリング・ローリングアップグレード非対応

実務上、可用性セットが最も効果を発揮するのは、同じ機能を持つVM群（Webサーバー、アプリケーションサーバーなど）を同一可用性セットに配置するパターンです。たとえば3台のWebサーバーを3つの障害ドメインに分散配置すれば、1つのラック障害が発生しても残り2台がトラフィックを処理し続けます。このパターンは追加コストなしで実現でき、コスト効率を重視する中小規模のワークロードに適しています。

一方、データセンター全体の停電や冷却システムの障害など、DCレベルの障害に対しては可用性セットでは保護できません。ミッションクリティカルなシステムでは、可用性ゾーンの活用が不可欠です。また、200台を超えるスケールが必要な場合や、トラフィックの変動に応じた自動スケーリングが求められる場合は、VMSS Flexibleが唯一の選択肢となります。

ロードバランサーとの併用設計

可用性セットの効果を最大化するには、Azure Load Balancerとの併用が推奨されます。Load Balancerは可用性セット内の複数VMにトラフィックを均等に分散し、特定のVMに負荷が集中することを防ぎます。

ロードバランサ―イメージ 参考：Microsoft

Load Balancerの正常性プローブ機能と組み合わせることで、障害が発生したVMへのトラフィック送信を自動的に停止し、正常なVMのみにリクエストを振り分けます。Standard Load Balancerはゾーン冗長にも対応しており、可用性セットからゾーンベースのアーキテクチャに将来移行する場合にもLoad Balancerの設定をそのまま活用できます。

Azure MonitorとAzure Backupを組み合わせた運用設計も重要です。MonitorでVMのストレージ性能やCPU使用率をリアルタイムに監視し、Compute Galleryで標準化イメージを管理しておけば、障害発生時の迅速なVM再作成が可能になります。Backupで定期的にVMスナップショットを取得しておくことで、データ損失リスクも最小化できます。

まとめ

本記事では、Azureの可用性セットの基本仕様から更新ドメイン・障害ドメインの仕組み、Portal上の作成手順、可用性ゾーン・VMSS Flexibleとの比較、メリット・制約とロードバランサー併用設計までを解説しました。

可用性セットの導入判断と最適化を進めるには、以下のステップを推奨します。まず現行環境のVM配置を確認し、可用性セットが適用されているかをAzure Portalのリソース一覧から確認します。Japan EastやJapan WestなどAZ対応リージョンを使用している場合は、新規ワークロードでは可用性ゾーンまたはVMSS Flexibleへの移行を検討してください。既存の可用性セットを維持する場合は、障害ドメインを最大の3、更新ドメインを5以上に設定し、Load Balancerによるトラフィック分散とMonitorによる監視体制を整備することで、99.95% SLAを確実に活用できます。