本記事は、日本などの地域エリア→リージョン→可用性ゾーン（AZ）→データセンター→ラック→ハイパーバイザー配下の物理サーバーまで、下層から上層へ段階的に概念を整理します。
出典は原則 Microsoft 公式を引用しています。

はじめに

クラウドの高可用性を設計するうえで、地理と物理の“層構造”の正しい把握が最初の一歩です。
Azure では、地理エリア（Geography：ジオグラフィー）がデータ所在地境界を定め、その中にリージョンがあり、リージョンの中で可用性ゾーン（AZ）が物理的に分離されたデータセンター群として存在します。
各ゾーンは独立した電源・冷却・ネットワークを備え、複数ゾーンにまたがる設計が高可用性の基本になります。(Azure リージョンとは)

1．全体図と層で見る用語マップ

層（上→下）	Azure の呼称	役割/ポイント	例
地域エリア	Geography	データ所在地境界。その内側に 1 つ以上のリージョン	Japan、Europe など (Azure データ所在地)
リージョン	Region	複数 DC とネットワークの集合。多くは AZ を提供。ペアリージョンの考え方もある	東日本↔西日本などのペア (リージョンの一覧)
可用性ゾーン	AZ	物理的に分離された DC の論理グループ。独立電源/冷却/ ネットワーク。ゾーン間は低遅延	低遅延（ターゲット約 2ms 未満）、距離は通常 100km 以内 (可用性ゾーンとは)
データセンター	DC	建屋単位。電源/冷却/ 物理セキュリティ	多層防御・冗長化の設計指針 (データセンターのアーキテクチャとインフラストラクチャ)
ラック/列	Rack/Row	電源・ネットワーク分配の基本単位	ToR スイッチなど
ハイパーバイザー	Hyper-V ベース	ゲスト VM を分離・実行	Azure のハイパーバイザーは Windows Hyper-V を基盤 (Azure フリートでのハイパーバイザーのセキュリティ)
物理サーバー	物理ホスト	ハイパーバイザーが載るサーバー	x86 サーバー群

2．地域エリアとリージョン

地域エリアはデータ所在地の境界。法令/ガバナンス要件に沿って、データの保存・処理場所の前提を提供します。
リージョンは物理施設（複数 DC とネットワーク）の集合で、可用性と復旧性の選択肢（AZ/ペアリージョン等）を提供します。リージョンを選ぶときは、その回復性オプションを確認するのが鉄則です。

日本の例：東日本（東京・埼玉）と西日本（大阪）はいずれも AZ 対応で、ペアリージョンとして関連付けられています。
2025年4月から、西日本リージョンでもAZ提供が始まりました。

3．可用性ゾーン（AZ）：建屋ごとの独立が前提

定義：リージョン内の物理的に分離されたデータセンター群の論理グループです。独立した電源・冷却・ネットワークを持ち、ゾーン障害に備えます。
距離と遅延：ゾーン間は通常100km 以内、約 2ms 未満のラウンドトリップを目標に高性能ネットワークで接続します。
ゾーン冗長 vs ゾーナル：
- ゾーン冗長…サービス/データを複数ゾーンへ自動分散します。例えば、ゾーン冗長ストレージ/ロードバランサーがあります。
- ゾーナル…リソースを特定ゾーンに特定します。より低遅延を狙えるものの、冗長性は自分で設計する必要があります。
論理ゾーンと物理ゾーンのマッピング：サブスクリプションごとにマッピングが違う場合があるため、API（checkZonePeers など）で確認が可能です。

4．データセンター：電源・冷却・ネットワーク・物理セキュリティ

多層防御（Defense-in-Depth）で可用性とセキュリティを設計しています。電源/ネットワーク/設備は複数レベルで冗長化されています。
物理セキュリティ：入退館や監視、境界制御などの対策が公開されています。(Azure の施設、建物、および物理上のセキュリティ)
最新動向（補足）：省水・高密度化など次世代 DC 設計の取り組みが行われています。例えば、水使用ゼロ冷却コンセプトの導入などです。ビジネス/環境要件に影響します。(持続可能な設計)

5．ラックとネットワーキング（ToR/EoR の世界）

ラック（Rack）は電源・ネットワーク分配の単位です。上部の ToR スイッチ を起点に、イースト/ウエスト方向やスパイン-リーフで DC 内を接続しています。構成は Azure 側が抽象化しています。
運用示唆：アプリ観点ではゾーン間トラフィック量と遅延の敏感度を把握し、同期/非同期の切り分けやLB レベル（L4/L7）を選択します。ゾーン間の課金は同リージョン内で無料（IP の種類にかかわらず）であることも設計時のヒントです。

6．ハイパーバイザーと物理ホスト

Azure のハイパーバイザーはWindows Hyper-V を基盤としており、ゲスト間の強固な分離・最小権限・監査等の要件を満たすよう設計されています。
このハイパーバイザーが物理サーバー（ホスト）上で VM を実行し、仮想デバイスを介してネットワーク/ストレージを共有化しますが、テナント間は分離されている点に注意です。

7．日本の具体（東日本/西日本）

東日本（Japan East）：AZ 対応、物理場所の一例は東京・埼玉。ペアは西日本。
西日本（Japan West）：AZ 対応、物理場所は大阪。ペアは東日本。
単に“日本”と括るのではなく、どのリージョン/どのゾーンかまで設計段階で明示しましょう。

8．設計ベストプラクティス（要点だけ）

リージョン選定時に、そのリージョンのAZ 提供状況とサービスの AZ 対応を確認しましょう。同じリージョンでも未対応サービスがある場合のチェックです。
本番は“複数 AZ”をデフォルトにし、ゾーン冗長を選べるサービスは積極的に採用しましょう。
サブスクリプションごとのゾーンマッピング差に留意しましょう。checkZonePeers 等で事前確認が重要です。
ゾーン間遅延の実測と同期要件の整合をとりましょう。目標は約 2ms 未満ですが、実測した方が確実で安心です。
ペアリージョンは DR 設計で重要になります。地震/大規模停電など広域災害を考えるなら必ず検討しましょう。(Microsoft Learn)

9．なぜ？

なぜ“層”で理解する必要があるのか？
　答え：障害境界（ゾーン/建屋/ラック/ホスト）を跨いで設計することで単点故障を避けられるから。
なぜ“AZ 前提”が推奨されるのか？
　答え：独立電源・冷却・ネットワークでリージョン内障害の局所化ができ、低遅延で同期できるため。
なぜゾーンマッピングを確認するのか？
　答え：論理ゾーン≠物理ゾーンの可能性があり、均等分散や DR の検証に影響するから。
なぜ日本では“東西”を意識するのか？
　答え：東日本/西日本はペアで、AZ 提供もあり、国内法規やデータ所在地の観点で現実的な選択肢になるから。
なぜハイパーバイザーまで知るべきか？
　答え：分離の仕組み/性能特性を理解し、セキュリティ設計やトラブルシュートに活かすため。

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

仮説：“複数 AZ を前提”に、ゾーン冗長サービス＋ゾーナル分散を組み合わせるのが最小の事故で最大の可用性を得る近道。
根拠/データ：AZ の独立性・距離/遅延目標、リージョン/ペアの考え、Hyper-V ベースの分離は Microsoft 公式で確認。
再検証：対象リージョンのAZ 提供状況・サービスごとの AZ 対応・ゾーンマッピングを API/ポータルで都度確認。ゾーン間遅延は実測で追認。
示唆/次アクション：
1. 設計書に層の境界（ゾーン/建屋/ラック/ホスト）を明記。
2. IaC（Bicep/Terraform）でzones/zoneRedundant をパラメータ化。
3. ゲームデイでゾーン停止/ラック故障/ホスト障害の擬似シナリオ演習を定例化。

おわりに

クラウドの可用性は偶然の産物ではなく、層ごとの境界を“意図して跨ぐ”設計の結果です。まずはリージョン内の複数 AZを“当たり前”にし、ゾーン冗長サービスを選び、論理-物理マッピングと遅延特性を見える化しましょう。
日本拠点では東日本/西日本のペアやデータ所在地の要件も加味しつつ、現実に動く設計へ落とし込むのが高可用性を狙う成功の鍵です。