【実務比較】Azure の「Availability Zones」と「Availability Set」：どちらで冗長化するべきか

１．はじめに

また業務で出た話題を整理するために記事を書きました。
同一リージョン内での可用性を高める方法として、AZ をまたいだ冗長化、いわゆるゾーン冗長と、単一データセンター内での可用性セット（Availability Set）のふたつが代表的です。
どちらも VM の計画停止/計画外停止に対する耐性を高める手段ですが、故障境界のスコープと運用の手触りが大きく異なります。
この記事では、その違いと使い分け、設計の型を体系的に整理します。

※本稿では Microsoft 正式用語である Availability Zones（以下、AZ）、Availability Set、Fault Domain（FD）、Update Domain（UD） を用います。数値や仕様はリージョンや SKU により変わるため、設計時は公式ドキュメントで最新を確認してください。

---

２．まずは用語の整理から

• Availability Zones（AZ）：リージョン内の物理的に分離されたデータセンター群（電源/冷却/ネットワークが独立）。リージョンによっては AZ が存在しない場合あり。
  ※2025年4月16日から西日本リージョンで AZ が利用開始になりました。
• Fault Domain（FD）：ラック/電源系統など同時停止しうる物理範囲。データセンターのフロアやラック単位で障害が発生した時に影響する。
• Update Domain（UD）：Azure の計画メンテ時に同時に更新される VM のグループ。アップデート失敗時などに影響する。
• Zonal リソース：特定の AZ にピン留め。指定した AZ で構築。
• Zone-redundant リソース：複数 AZ にまたがって冗長化。
• Availability Set：単一データセンター内で、FD（物理的故障境界）と UD（更新の単位）に複数 VM を分散する論理コンテナ。

---

３．要点から解説

• 最優先の既定解：要件が許すなら AZ またぎの冗長化を採用。
• Availability Set は依然有効：レガシー要件や単一ゾーン内での冗長（FD/UD 分散）が必要なときに有効。AZ が提供されていないリージョンでの選択肢に。
• SLA の目安（代表値）：
  • AZ またぎで VM を複数：99.99%（代表値）
  • Availability Set で VM を複数：99.95%（代表値）
  • 単一 VM（Premium SSD 等）：99.9%（代表値）
    ※実際の数値は SKU/構成で異なるため、必ず公式 SLA を確認してください。

---

４．アーキテクチャの違いを解説

４.１　故障境界のスコープ

• AZ：建屋レベルで独立。データセンター障害に強い。
• Availability Set：同一データセンター内の FD/UD 分散。ラック/電源系統/メンテに強いが、データセンター障害は避けられない。

４.２　ネットワーク/入口

• AZ 冗長の入口は Standard Load Balancer（L4） か Application Gateway v2（L7/WAF） の Zone-redundant 構成が定番。
• Availability Set でも同様の入口を置けるが、単一データセンター前提。

４.３　ストレージ/データ

• AZ 冗長では、選べるなら Managed Disk の ZRS（ゾーン冗長ストレージ）、または DB レイヤのマルチ AZ レプリケーションを併用し、VM だけではなくデータ面もゾーン耐性を確保。
• Availability Set では LRS（ローカル冗長ストレージ）前提のことが多く、データ冗長はアプリ/DB 側で補う設計が一般的。

４.４　レイテンシ/スループット

• AZ 間はリージョン内で低遅延（代表的に数 ms 程度）に設計されるが、単一データセンター内よりは大きい。超低遅延を最優先する場合は 単一ゾーン＋PPG（Proximity Placement Group） 等の検討が必要（※PPG は ゾーンをまたげない）。

４.５　コスト含みの運用性

• AZ：入口/NAT/ストレージのゾーン冗長化や、ゾーン間トラフィックでコスト差が出る場合がある。
• Availability Set：同一データセンター内ゆえネットワーク面はシンプル。ただし SLA と障害耐性は AZ に劣る。

---

５．比較表（実務観点）

観点	Availability Zones	Availability Set
故障境界	データセンター級をまたぐ	ラック/電源/メンテ級 （単一 DC 内）
SLA 代表値	99.99% （複数 VM を複数 AZ）	99.95% （複数 VM を AS 内で分散）
レイテンシ	AZ 間で数 ms 程度 （地域差あり）	最小（単一 DC 内）
データ冗長	ZRS/DB のマルチ AZが選択肢	アプリ/DB 側の冗長で補完
入口/NAT	Zone-redundant を推奨	標準構成（ゾーン冗長は任意）
PPG（近接配置）	ゾーンまたぎ不可 （単一ゾーン内のみ）	単一 DC 内で有効
代表的な使いどころ	本番系の既定解、高可用性が 必須	レガシー/強いローカル性/ ゾーン未提供の制約下

※課金/在庫/サポート可否はリージョン/SKU ごとに差があるため、都度の確認が必須です。

---

６．具体的な設計パターン

６.１　AZ 冗長（推奨の最小構成）

• Zonal VM/VMSS を AZ“１/２（/３）” に分散
• 入口は Standard Load Balancer（Zone-redundant） もしくは Application Gateway v2（Zone-redundant＋Auto Scale）
• アウトバウンドは NAT Gateway を各 AZ に配置（いわゆる“ゾーンスタック”）
• ディスクは選べるなら ZRS、非対応ならDB レプリケーションで補う

６.２　Availability Set（単一データセンター内の冗長）

• Availability Set（例：FD=2/UD=5）を作成し、２台以上の VM を登録
• 入口は Standard Load Balancer（必要に応じて）
• データ冗長はアプリ層で確保（同期/非同期の切替基準を明確化）

---

７．サンプル（Bicep ：Azure リソースをデプロイするドメイン固有言語）

AZ にまたがる Zonal VM（例）：

resource vmA 'Microsoft.Compute/virtualMachines@2023-09-01' = {
  name: 'app-az1'
  location: location
  zones: [
    '1'
  ]
  properties: { /* 省略 */ }
}
resource vmB 'Microsoft.Compute/virtualMachines@2023-09-01' = {
  name: 'app-az2'
  location: location
  zones: [
    '2'
  ]
  properties: { /* 省略 */ }
}

Availability Set の作成と VM 登録（例）：

resource as 'Microsoft.Compute/availabilitySets@2023-09-01' = {
  name: 'app-as'
  location: location
  properties: {
    platformFaultDomainCount: 2
    platformUpdateDomainCount: 5
  }
}

resource vm1 'Microsoft.Compute/virtualMachines@2023-09-01' = {
  name: 'app-as-1'
  location: location
  properties: {
    availabilitySet: { id: as.id }
    /* 省略 */
  }
}

---

８．アンチパターン/よくある誤解

• Availability Set を複数 AZ にまたがって使える？ → 不可。Availability Set は単一データセンター内の分散機構です。
• PPG（近接配置グループ） と AZ を同時に？ → 両立しない（PPG は単一ゾーン内）。
• LB があれば AZ 冗長になる？ → ならない。VM/データ/NAT/IP までゾーン設計が必要。
• SLA の数値は固定？ → 変わり得る。SKU/構成/OS で差があるため最新の公式 SLAを必ず参照。
• ゾーン間通信は全部無料？ → 前提による。帯域課金/LB クロスゾーン処理の料金が関係する場合があるため、価格表を確認。

---

９．使い分けフローチャートで確認

1. データセンター障害に耐える必要があるか？
   　→ はい：AZ。/ いいえ：次へ。
2. 超低遅延（PPG 必須級）か？
   　→ はい：単一ゾーン＋PPG＋Availability Set（必要に応じて）。/ いいえ：次へ。
3. 既存運用・ライセンスの制約で個体管理が前提か？
   　→ はい：Availability Set も選択肢。/ いいえ：AZ が既定。
4. 将来のスケール/自動復旧を重視するか？
   　→ はい：VMSS（Flexible）＋AZ を推奨。

---

１０．なぜで深掘り

1. なぜ AZ を既定にすべきか？
   答え：データセンター級の障害境界を跨げるため、事業継続性への寄与が最も大きいから。
2. なぜ Availability Set はまだ使われるのか？
   答え：単一データセンター内での FD/UD 分散が必要なケースや、レガシー要件/ゾーン未提供の制約が現場に残るから。
3. なぜ SLA が違うのか？
   答え：故障境界の独立性の差（AZ は建屋級、AS はラック/電源級）が同時停止確率を下げるから。
4. なぜ PPG と AZ を同時に使いにくいのか？
   答え：PPG は近接性優先、低レイテンシ＝単一ゾーン内という設計思想で、ゾーン跨ぎと本質的に相反するから。
5. なぜ 入口/NAT/ディスクまで“ゾーン設計”が必要か？
   答え：ボトルネックは一番弱いリンクに引きずられる。片方が単一ゾーンだと全体の可用性が下がるため。

---

１１．仮説 → 根拠/データ → 再検証 → 示唆・次アクション

• 仮説：本番系は AZ 冗長を既定とし、AS は補助的に（単一ゾーン内の FD/UD 分散）使うのが、SLA/運用コスト/拡張性の最適点。
• 根拠/データ：AZ は物理的分離、AS はFD/UD 分散という設計思想の差。SLA の代表値（99.99%/99.95%/99.9%）は公式 SLA の一般的な水準と整合。
• 再検証：対象リージョンの AZ 提供状況/在庫/価格（ゾーン間転送料・LB クロスゾーン課金）/ZRS 対応を、最新ドキュメントと価格表で確認。
• 示唆・次アクション：
  1. 入口（LB/AppGW）/NAT/IP のゾーン属性を棚卸し。
  2. IaC に zones/zoneRedundant/FD/UD をパラメータ化しスイッチ可能にする。
  3. 試験や訓練でゾーン停止/ラック停止/ホスト故障を模擬的に発生させ、RTO/RPO/フェイル判定を定義。

---

１２．おわりに

可用性は“境界をどう跨ぐか”の設計問題です。
AZ 冗長はデータセンターの建屋級の障害に強く、Availability Set は単一データセンター内の計画停止・局所障害に強い。要件とコスト、遅延、運用制約を秤にかけ、入口〜計算〜データ〜出口まで一貫したゾーン設計で仕上げましょう。迷ったら、AZ 冗長＋VMSS（Flexible）を起点に評価するのが近道です。
あと、コスト面はしっかりシミュレーションしましょうね。

---

参考

• Azure Regions/Availability Zones/SLA：Microsoft Learn/Azure SLA
• Availability Set（FD/UD）：Microsoft Learn
• Managed Disks（ZRS/LRS）：Microsoft Learn
• Pricing（ゾーン間データ転送・LB クロスゾーン処理）：Azure Pricing/Bandwidth/Load Balancer 価格ページ

※具体的な URL/価格は更新が頻繁なため、設計直前に 公式ページで最新版を確認してください。