Azure Subscriptionの設計と分割パターン｜Management Group階層・環境分離・コスト配賦の実践ガイド

「Azure環境が大きくなってきたけど、Subscriptionをどう分けるべきか迷っている」「Management Groupって結局どう使えばいいのか」——こういう疑問を持つエンジニアは多いはずです。

AWSをある程度使ってきた人でも、Azureのサブスクリプション構成はとっつきにくい部分があります。AWSのアカウント分割に相当するのがAzureのSubscription分割ですが、その上にManagement Groupという階層がある分、設計の自由度と複雑さが増します。

この記事では、Azure Subscriptionの設計と分割パターンについて、Management Group階層の構成・環境別分割の考え方・コスト配賦設計のポイントを整理します。オンプレやAWS経験者が「Azureの環境設計をゼロから考える」際の判断材料として活用してください。

AzureのリソースはなぜSubscriptionで分けるのか

オンプレ時代は、サーバーやネットワーク機器を物理的に管理する単位が「プロジェクト」や「部門」でした。Azureでは、それに相当する論理的な単位がSubscriptionです。

Subscriptionは単なる「課金単位」ではありません。実際には次の3つの役割を同時に担っています。

・課金の境界: 各Subscriptionで独立した請求書が発行される
・アクセス制御の境界: RBAC（ロールベースアクセス制御）のスコープとして機能する
・クォータ（上限）の境界: vCPUやPublic IPなどのリソース上限はSubscription単位で管理される

つまり、Subscriptionを分けることで「課金の可視化」「権限の分離」「クォータの独立」が同時に実現します。

AWSで言えば、1つのAWSアカウントに相当するイメージです。ただしAWSの場合、Organizations配下で複数アカウントを管理するのと同様に、AzureではEntra ID（旧Azure AD）テナント配下に複数のSubscriptionを作り、Management Groupで束ねます。

Management Groupの階層を理解する

Azureのリソース管理階層は、上から次の順番になっています。

Management Groupのポイントは、ポリシーと権限を上位から継承できる点です。たとえば「全社で特定リージョン以外へのデプロイを禁止する」というAzure Policyを Root Management Groupに適用すれば、配下のすべてのSubscriptionに一括で適用されます。

1. Management Groupの設計原則

Management Groupの階層は深くなるほど管理が複雑になります。実務では3階層以内に収めることが推奨されています。

典型的な構成例：

# Management Group 階層の例（テナント直下）
Root Management Group
├── Platform（共通基盤）
│   ├── Management（監視・ログ・セキュリティ用途）
│   └── Identity（Entra ID Connect・AD DS等）
├── Landing Zones（業務ワークロード）
│   ├── Corp（社内向けアプリ）
│   └── Online（外部公開アプリ）
├── Sandbox（検証・PoC）
└── Decommissioned（廃止予定）

この設計は Microsoft の「Cloud Adoption Framework（CAF）」でも推奨されているパターンで、「Landing Zone」という概念がベースになっています。ただし、小規模な組織では Management Group 1階層で十分なことが多く、最初から全部作る必要はありません。

2. Management Groupが1つでも機能するケース

Subscription数が5～10程度、チームが1部門のみ、という規模であれば Management Group の多階層化はかえって管理コストになります。この場合は Root 直下に Subscription を並べ、Resource Group レベルで用途を分ける方がシンプルです。

Management Groupの多階層化が必要になるサイン：

・Subscriptionが10本以上になってきた
・部門や事業単位で権限を分離したい
・全社共通のAzure PolicyやRBACを一元管理したい
・予算・コストをManagement Group単位でレポートしたい

環境別Subscriptionの分割パターン

実際の現場で最もよく議論になるのが「開発・ステージング・本番をどう分けるか」という問題です。主なパターンは3つあります。

1. Subscriptionを環境別に分割する（推奨）

開発・ステージング・本番それぞれに独立したSubscriptionを作るパターン。

メリット：

・課金の分離: 環境ごとのコストが正確に把握できる
・権限の分離: 開発者が誤って本番リソースを操作するリスクがゼロになる
・クォータの分離: 本番環境のvCPU上限が開発環境の使いすぎで圧迫されない
・Policy適用の柔軟性: 本番だけ厳格なポリシーを適用できる

デメリット：

・Subscription数が増えると管理コストがかさむ: 命名規則・タグ戦略・監視設定を各Subscriptionで統一する手間がある
・テナントの上限: Entra ID テナントあたりの Subscription 数は初期状態では限りがある（ただし引き上げ申請が可能）

2. Resource Groupで環境を分離する（小規模向け）

1つのSubscription内に「rg-prd-webapp」「rg-stg-webapp」「rg-dev-webapp」のようにResource Groupで環境を分けるパターン。

小規模チーム・初期フェーズには向きますが、規模が大きくなると権限管理・コスト集計・クォータの問題が出てきます。スタートアップや数人のチームで始める場合はこちらで問題ありません。

3. アプリケーション単位 × 環境でマトリクス分割する

中～大規模の企業でよく採用されるパターンです。

# アプリ × 環境マトリクスの例
sub-prd-webapp    # Webアプリ 本番
sub-prd-infra     # 共通基盤（DNS・監視・セキュリティ）本番
sub-prd-data      # データ基盤（SQL DB・Blob・分析）本番
sub-stg-all       # ステージング環境（全アプリ共用）
sub-dev-all       # 開発環境（全アプリ共用）
sub-sandbox       # 検証用（個人使用可）

本番は「アプリ・インフラ・データ」で分割してクォータとコストを切り離し、ステージング・開発は統合して管理コストを下げる、というアプローチです。

コスト配賦のためのSubscription設計

「部門別・プロジェクト別にコストを出したい」という要件は、Azure Subscription設計の大きな動機の一つです。

1. コスト配賦の3つのアプローチ

2. タグ戦略との組み合わせ

Subscriptionを分割しても、タグが付いていないリソースはコスト集計の精度が落ちます。以下のタグを全リソースに必須化するAzure Policyを設定するのが実務上の標準です。

・CostCenter: 予算コードや部門コード
・Environment: prd / stg / dev / sandbox
・Project: プロジェクト名や案件名
・Owner: リソースオーナーのメールアドレス
・ManagedBy: terraform / manual / arm-template 等

タグを必須化するにはAzure Policyの「Require a tag on resources」を使います。タグなしでリソースを作成しようとすると拒否するポリシーを Management Group 上位から継承させることで、全Subscriptionで統一管理できます。

3. Azure Cost Managementでのコスト分析

Azure Cost Managementでは、スコープを Management Group に設定すると配下の全Subscriptionのコストを一括表示できます。これがManagement Groupを設計する実務上の大きなメリットです。

・Management Groupスコープで予算アラートを設定
・Subscription別・タグ別でコストをドリルダウン
・月次レポートを自動生成してFinOps担当者にメール配信

Subscriptionの命名規則とリソースグループ設計

命名規則を決めておかないと、後から「どのSubscriptionが何用なのか」がわからなくなります。

1. 推奨命名パターン

# Subscriptionの命名規則
# パターン: sub-{環境}-{アプリ/用途}-{省略会社名}
sub-prd-webapp-contoso
sub-stg-webapp-contoso
sub-dev-webapp-contoso
sub-sandbox-contoso

# Resource Groupの命名規則
# パターン: rg-{アプリ}-{コンポーネント}-{環境}-{リージョン略称}
rg-webapp-frontend-prd-japaneast
rg-webapp-backend-prd-japaneast
rg-webapp-db-prd-japaneast
rg-webapp-monitor-prd-japaneast

命名規則を決める際の注意点：

・Azureの命名文字制限: Subscriptionには最大64文字、Resource Groupには最大90文字
・小文字・ハイフン推奨: 大文字は後で小文字に統一したくなることが多い
・環境をプレフィックスに: 「prd-」「stg-」をSubscription名の先頭に置くと一覧で視認しやすい

2. Resource Groupの分割粒度

Resource Groupはライフサイクルが同じリソースをまとめる単位です。「まとめて削除できる単位」と考えると分かりやすいです。

・フロントエンド（App Service、Front Door）
・バックエンドAPI（App Service、Functions）
・データベース（SQL Database、Cosmos DB）
・ネットワーク（VNet、NSG、Private Endpoint）
・監視（Log Analytics Workspace、Application Insights）

これらをそれぞれ別のResource Groupにしておくと、「DBだけ残してアプリ層を作り直す」という操作がResource Group単位の削除で実現できます。

Subscriptionの上限（クォータ）について

Subscriptionを分割するもう一つの理由が「クォータの分離」です（2026年9月時点）。

大規模な本番環境で vCPU を大量に使う場合、開発・テスト環境と同じ Subscription にしているとクォータを食い合います。本番 Subscription を分離してクォータを独立させることが重要です。

クォータの確認と引き上げ申請は Azure Portal の「使用量 + クォータ」メニューか、Azure CLI で行います。

# Azure CLI でvCPUクォータを確認する例（東日本リージョン）
az vm list-usage --location japaneast --output table

# Management Group 配下のSubscription一覧を確認
az account management-group show \
  --name "mg-landing-zones" \
  --expand-children

実務でよくあるハマりどころ

1. Subscription移動の制限

一度作成したリソースを別のSubscriptionに移動できる場合もありますが、すべてのリソースタイプが移動に対応しているわけではありません。特にAzure Cosmos DBやAzure Kubernetes Serviceは移動に制限がある場合があります。最初から適切なSubscriptionに作成することが重要で、「後で移そう」は危険です。

2. 同じEntra IDテナントに紐付ける必要がある

Management Groupで束ねられるのは同一Entra IDテナント配下のSubscriptionのみです。別会社・別組織のSubscriptionをManagement Groupに追加することはできません。子会社や外部パートナーの環境を管理する場合は、Azure Lighthouseを使った別テナント間の委任管理を検討します。

3. Subscriptionを削除すると課金が止まらない場合がある

Subscriptionを削除しても、一部のリソースは請求対象として残ることがあります（Reserved InstancesやSavings Plansなど）。削除前にAzure Cost Managementで予約購入がないか確認することを忘れないようにしてください。

4. Management GroupのルートIDは変更できない

Root Management GroupのIDはEntra IDテナントIDと紐付いており、後から変更できません。命名規則は最初に慎重に決めておくことが必要です。

5. AWSのOrganizations設計と混同しやすい点

AWSのAWS Organizationsでは SCP（Service Control Policy）でアカウントへの操作を制限しますが、Azureでは Management Group に Azure Policy を割り当てることで同等の制御を実現します。どちらも「上位から一括適用する」という考え方は同じです。ただし、AWSの SCP は「できることを制限する（ホワイトリスト/ブラックリスト）」のに対し、Azure Policy は「設定値を強制する・非準拠を検知する」という用途が中心で、使い方のニュアンスが異なります。

小規模から始める段階的な設計ガイド

いきなり完璧なManagement Group設計を作ろうとすると、運用が始まる前に設計疲れします。段階的に拡張することを前提にした進め方を紹介します。

初期フェーズでは「本番Subscriptionだけは必ず分離する」という鉄則を守れば、残りは後から整理できます。逆に言えば、本番と開発・検証が同一Subscriptionにいる状態は最も危険なので最初に解消します。

本記事のまとめ

Azure Subscriptionの設計と分割パターンについて、Management Group階層・環境別分割・コスト配賦の観点で整理しました。

・Subscriptionは課金・権限・クォータの境界であり、AWSアカウントに相当する
・Management GroupでSubscriptionをグループ化し、PolicyとRBACを上位から継承させる
・本番Subscriptionは最初から分離する。他の環境は規模に応じて段階的に分割
・コスト配賦はSubscription分割×タグ戦略の組み合わせで実現する
・命名規則はプロジェクト開始前に決め、後からの変更コストを避ける

AWSのOrganizations設計と共通する考え方が多いので、AWS経験者であれば比較的スムーズに理解できるはずです。詳細なポリシー設計はAzure Policyの実践ガイドもあわせて参照してください。