Azureのコアアーキテクチャ — リージョン・可用性ゾーン・サブスクリプションの階層
この章の目次開く
この章から、いよいよAzure本体の話に入ります。最初に押さえるのは、すべてのAzureサービスの土台となる 物理的な構造(データセンター・リージョン・可用性ゾーン) と 論理的な構造(リソース・リソースグループ・サブスクリプション・管理グループ) です。
この2つの構造は、後の章で学ぶ仮想マシンにもストレージにもコスト管理にも関わってきます。ここを図で頭に入れておくと、以降の理解が一気に楽になります。
学習者「東日本リージョン」とか聞いたことはあるけど、リージョンとデータセンターと可用性ゾーンって、どういう包含関係なんだろう？
物理的な構造 — データセンター・可用性ゾーン・リージョン
Azureの実体は、世界中に配置された データセンター(サーバーが詰まった建物) です。これが次のようにグループ化されています。
リージョン
リージョンは、低遅延ネットワークで接続された複数のデータセンターの集まり で、利用者がリソースを配置する場所の基本単位です。日本には「東日本」「西日本」の2リージョンがあります。
リージョン選びの観点は3つです。
- ユーザーとの距離 — 近いほど通信の遅延が小さい
- データの所在地に関する規制 — 「データを国内に置くこと」といった要件への対応
- サービスと価格の違い — リージョンによって使えるサービスや料金が異なる
可用性ゾーン
可用性ゾーン(Availability Zone)は、リージョン内で物理的に分離されたデータセンターのグループ です。ゾーンごとに独立した電源・冷却・ネットワークを持ちます。
仮想マシンを複数のゾーンに分散して配置すれば、1つのデータセンターが丸ごと停電してもサービスを継続できます。第3章で学んだ「高可用性」を実現する具体的な手段です。
リージョンペアとソブリンリージョン
さらに広域の災害に備えて、多くのリージョンは 同じ地域内の別リージョンとペア を組んでいます(例: 東日本と西日本)。ペアの片方が大規模災害で失われても、もう片方で復旧できる設計です。
また、ソブリンリージョン という特殊なリージョンもあります。米国政府専用(Azure Government)や中国専用など、法規制対応のために通常のAzureから分離された環境です。
論理的な構造 — リソースからサブスクリプションまで
物理的な構造の上に、利用者が管理するための 論理的な階層 があります。下から順に見ていきます。
リソース
リソースは、Azure上に作る個々の部品 です。仮想マシン1台、ストレージアカウント1つ、データベース1つ——それぞれがリソースです。
リソースグループ
リソースグループは、関連するリソースをまとめる入れ物 です。たとえば「ECサイト用のVM+DB+ストレージ」を1つのリソースグループに入れます。
重要な性質が3つあります。
- すべてのリソースは、必ずどれか1つのリソースグループに属する(複数への同時所属は不可)
- リソースグループを削除すると、中のリソースもすべて削除される(ライフサイクルの一括管理)
- リソースグループは 入れ子にできない
「プロジェクトが終わったらリソースグループごと削除して課金を止める」というのが典型的な使い方です。
サブスクリプション
サブスクリプションは、課金とアクセス管理の境界 です。Azureの利用料金はサブスクリプション単位で請求されます。
企業では「本番用」「開発用」「部署ごと」のようにサブスクリプションを分けて、予算と権限を分離 するのが一般的です。開発チームには開発用サブスクリプションだけの権限を与えれば、本番環境を誤って触る事故を防げます。
管理グループ
管理グループは、複数のサブスクリプションをまとめて統制する仕組み です。
たとえば「全社共通:リソースは日本リージョンのみ許可」というポリシーを管理グループに適用すれば、配下のすべてのサブスクリプションに一括で強制できます。管理グループは入れ子にでき、大企業の組織階層をそのまま表現できます。
学習者リソースグループとサブスクリプションって、どっちも「まとめる入れ物」だよね。どう使い分けるの？
先生役割が違います。リソースグループは「一緒に作って一緒に消すもの」をまとめる作業単位、サブスクリプションは「お金と権限」を区切る管理単位 です。「請求書を分けたい・権限を大きく分けたい」ならサブスクリプション、「アプリ一式をまとめたい」ならリソースグループ、と覚えてください。
階層まとめ — 誰が何のために使うか
4つの論理階層を一枚の表に整理します。この表はRBAC(第9章)やAzure Policy(第12章)のスコープにもそのまま登場します。
| 階層 | 役割 | 典型的な用途 |
|---|---|---|
| 管理グループ | サブスクリプションの統制 | 全社ポリシーの一括適用 |
| サブスクリプション | 課金・アクセスの境界 | 部署/環境ごとの予算と権限の分離 |
| リソースグループ | リソースのライフサイクル管理 | アプリ一式の作成・削除の一括化 |
| リソース | 個々のサービス実体 | VM、ストレージ、DBなど |
ポータルで試してみよう — リソースグループの作成と削除
この章の内容は、ポータルで実際に触るのが一番の近道です。空のリソースグループは課金されない ので、安心して試せます。
- Azure Portal にサインインする
- 画面上部の 検索ボックス に「リソース グループ」と入力して選択する
- 「+ 作成」 をクリックし、サブスクリプション・名前(例:
rg-learn)・リージョン(例: Japan East)を指定する - 「確認および作成」→「作成」 で完成。一覧に自分のリソースグループが現れる
- 後片付け: リソースグループを開き 「リソース グループの削除」 をクリック。確認のためにリソースグループ名の入力を求められる
手順5の「名前を入力しないと削除できない」仕組みは、「リソースグループを消すと中身がすべて消える」というこの章で学んだ性質の裏返しです。ついでに、作成画面のリージョン一覧を眺めて「東日本」「西日本」がどこにあるかも見ておきましょう。
まとめ
- 物理構造は データセンター < 可用性ゾーン < リージョン の入れ子で、リージョンは災害対策のために ペア を組む
- 可用性ゾーン はデータセンター単位の障害対策、リージョンペア はリージョン規模の災害対策
- 論理構造は リソース < リソースグループ < サブスクリプション < 管理グループ の4階層
- リソースグループ はライフサイクルの単位(削除すると中身も消える)、サブスクリプション は課金と権限の境界
- ポリシーと権限は 上位から下位へ継承 される
次の章では、この土台の上に載せる最初のサービス——仮想マシン・App Service・Functions などのコンピューティングサービスを見ていきます。