Azureランディングゾーンを小さく始める｜中堅企業のための最小構成

「Azureを本格的に使い始めたいので、まず基本構成を作りたい」—そうした相談をいただいたとき、私たちが最初に話すのが「ランディングゾーン」です。
ランディングゾーンとは、ワークロードを載せる前に整えておくAzureの基盤設計——サブスクリプションの構造、権限、ネットワーク、ガバナンスの初期配置のことです。

Azure Landing Zoneの参照アーキテクチャには、大規模なAzure利用を見据えた多くの設計要素が含まれています。
ただし、これはすべての企業が最初から同じ構成を実装するためのものではありません。Microsoft自身も、参照アーキテクチャを「組織の要件に合わせて適応させる出発点」と位置付けています。
この記事では、「後から拡張できる形を保ちながら、必要な要素から取り入れていく」ための設計の考え方を整理します。

この記事でわかること

• 参照アーキテクチャを「そのまま」実装したときに起きること

• 中堅企業が最初に押さえるべき最小限の4要素

• 「後から拡張できる設計」にしておくための勘所

※本記事は、Azureサブスクリプションを1〜数個の規模で使い始める企業を想定しています。数十サブスクリプション規模のエンタープライズ環境には、CAF（クラウド導入フレームワーク）のエンタープライズスケール・ランディングゾーンの検討をおすすめします。

「標準どおりそのまま」で起きること

CAFのランディングゾーン設計は、よくできています。管理グループの階層、プラットフォーム用と業務用のサブスクリプション分離、ハブ＆スポーク型のネットワーク、Azure Policyによるガードレール——大規模環境で統制を効かせるための知見が詰まっています。

問題は、これを数人の情報システム部門でそのまま運用しようとすると、「作った本人しか全体像を把握できない基盤」ができあがることです。管理グループが5階層あっても、載せるサブスクリプションが2つでは意味がありません。ハブ＆スポークを組んでも、接続するスポークが1つなら、複雑さのコストだけを払うことになります。

実際の支援現場では、設計当初のルールが運用に合わなくなっているケースもよく見かけます。例えば、分離する目的が曖昧なままサブスクリプションを増やした結果、管理対象だけが増えてしまった環境。
あるいは、用途ごとにリソースグループを分けるルールを作ったものの、次第に分類しきれなくなり、枝番だけが増えて用途が分からなくなった環境です。
ルールを細かくすることよりも、「なぜ分けるのか」を明確にしておく方が、長期的には重要です。

ランディングゾーンは一度作ると作り直しにくいからこそ、最初のサイズ選びが重要です。

最初に押さえる最小限の4要素

CAFが挙げる設計領域は多岐にわたりますが、私たちが中堅規模の初期構築で「ここだけは最初に決める」としているのは、次の4つです。

1. 管理グループとサブスクリプションの分け方

最初から「本番用」「検証用」「システムA用」「システムB用」と機械的にサブスクリプションを増やす必要はありません。サブスクリプションを分ける主な判断軸は、環境の分離、権限の分離、コスト管理、システムの責任分界、Azureのクォータや制限などです。小規模な利用であれば1〜2サブスクリプションから始め、分離する理由が出てきた段階で追加する考え方でも十分です。

そのうえで、私たちがよく採用する初期構成の一例が、本番と検証を分離する構成です。管理グループは「プラットフォーム用」と「ワークロード用」程度の浅い階層から始めます。

大切なのは数を増やすことではなく、「何を分離の単位にするか」の方針を決めておくことです。部門で分けるのか、システムで分けるのか、環境で分けるのか。この方針さえ決まっていれば、後からサブスクリプションを追加しても構造は崩れません。

2. 命名規則とタグの規約

地味ですが、後から直すのが最も大変な項目です。リソースグループ、仮想ネットワーク、ストレージアカウントなどの命名パターンと、最低限のタグ（環境、所有部門、コスト配賦先）を最初に決め、1枚の管理表にしておきます。

命名規則は凝る必要はありません。「リソース種別-システム名-環境-連番」のような、誰が見ても読める単純なパターンで十分です。重要なのは、最初のリソースを作る前に決めておくことです。

3. Entra IDとの連携とRBAC設計

AzureのアクセスはEntra IDのグループで管理します。個人にロールを直接割り当てるのではなく、「このグループには本番の閲覧権限」「このグループには検証環境の共同作成者」のように、グループ単位でRBACを設計します。

ここでも最小限で構いません。最初は「管理者」「運用担当」「閲覧のみ」の3グループ程度から始め、必要になったら細分化します。前回の記事で書いた条件付きアクセスの設計と合わせて、管理者ロールにはより強い認証を要求しておきます。

4. コスト管理とガードレール

使い始めの事故で最も多いのが「想定外の課金」です。サブスクリプションごとに予算アラートを設定し、閾値を超えたら通知が飛ぶようにしておきます。これは数分でできる設定ですが、やっていない環境が驚くほど多いのが実情です。

なお、Budgetは利用上限を設定する機能ではありません。閾値を超えてもAzureリソースは停止しないため、「予算アラート＝課金を止める仕組み」ではない点には注意が必要です。コストデータの反映にも一定の遅延があります。それでも、「気づける状態」を作っておくことが初期の事故防止には最も効きます。

あわせて、Azure Policyで最低限のガードを固めます。例えば「原則としてJapan East / Japan Westを利用する」「利用可能なVM SKUを一定範囲に定義する」といったガードレールです。サービスによってはグローバルリソースや利用可能リージョンが異なるため、例外が必要になることを前提に設計します。禁止事項を増やしすぎると検証の自由度が下がるため、初期は「事故を防ぐ最小限」に絞ります。

「後から拡張できる」ようにしておくポイント

最小構成で始めることと、行き当たりばったりで作ることは違います。次の3点を意識しておくと、規模が拡大したときにCAF標準の構成へ自然に近づけていけます。

• 管理グループの階層は浅く、しかし「階層がある」状態にしておく。
  ルート直下にサブスクリプションをぶら下げず、1階層でも管理グループを挟んでおくと、後からポリシーの適用単位を整理できます。

• ネットワークは「将来ハブになれるVNet」を意識する。
  最初からハブ＆スポークを組む必要はありませんが、アドレス空間の設計だけは将来の拡張（拠点接続、スポーク追加）を見込んで重複なく確保しておきます。

• 手作業の構築でも、設定内容を記録に残す。
  初期からIaC（コード化）まで求めると負荷が高すぎますが、「何をどう設定したか」の記録があれば、将来のコード化・棚卸しの土台になります。

最初の1ヶ月でやることチェックリスト

最後に、ここまでの内容を導入初月のチェックリストとしてまとめます。

• [ ] 分離の方針を決める（何をサブスクリプション分割の単位にするか）

• [ ] 管理グループを作成し、サブスクリプションを配置する（例: 本番・検証）

• [ ] 命名規則とタグ規約を1枚の表にする

• [ ] Entra IDグループを作成し、グループ単位でRBACを割り当てる

• [ ] 管理者ロールに条件付きアクセスで強い認証を要求する

• [ ] すべてのサブスクリプションに予算アラートを設定する

• [ ] リージョンやSKUの制限など最小限のAzure Policyを適用する

• [ ] 設定内容の記録（構成表）を残す

まとめ

ランディングゾーンの価値は、構成の立派さではなく、「この基盤の上なら安心してワークロードを増やせる」という状態を維持できることにあります。中堅規模であれば、管理グループとサブスクリプションの方針、命名とタグ、グループベースのRBAC、コストとポリシーのガードレール——この4つを小さく確実に整えることが、参照アーキテクチャの分厚いドキュメントを読み込むことよりも先です。
小さく始めて、必要になったときに標準構成へ育てていく。それが、運用する人数が限られる組織にとって現実的なランディングゾーンだと私たちは考えています。