Azure Fundamentals · レッスン

管理グループとサブスクリプション

Q: 「管理グループとサブスクリプション」で何を学びますか？

Azure サブスクリプションを管理グループの階層に整理し、企業全体でポリシーとアクセス制御を一貫して適用します。 ブラウザで直接実行するハンズオンコードでAzure Fundamentalsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Azure サブスクリプションを管理グループの階層に整理し、企業全体でポリシーとアクセス制御を一貫して適用します。

「管理グループとサブスクリプション」はCoddyKit上の無料Azure Fundamentalsレッスンです。これはレッスン1/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAzure Fundamentals学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Azure Fundamentalsコースには全4レッスンが含まれています。

Azure リソース階層

Azure では、リソースを 4 つのレベルからなる階層に整理します。最上位は管理グループです。管理グループは、ポリシーとアクセス制御を大規模に適用するためにサブスクリプションをまとめるコンテナーです。その下にはサブスクリプションがあります。サブスクリプションは、請求とリソース境界の単位です。サブスクリプション内には、関連するリソースをまとめる論理コンテナーであるリソースグループがあります。最下位はリソースで、VM、データベース、ストレージアカウントなどの個々のサービスを指します。上位レベルで適用されたポリシーとアクセス許可は、下位レベルに継承されます。

Azure サブスクリプションとは

Azure サブスクリプションは、請求単位であると同時に、論理的なリソース境界でもあります。サブスクリプション内のすべてのリソース使用量は、1 つの請求書にまとめて請求されます。サブスクリプションでは、種類ごとにデプロイできるリソース数の上限（クォータ）が設定されます。組織では通常、環境（Production、Development、Testing）、事業部門、地理的リージョンごとに別々のサブスクリプションを作成します。それぞれのサブスクリプションで、独自のコストレポートとアクセス制御を設定できます。

# List all subscriptions you have access to
az account list --output table

# Switch to a specific subscription
az account set --subscription 'My Production Subscription'

複数サブスクリプションのパターン

大規模な企業が複数のサブスクリプションを使用する理由はいくつかあります。分離 — 本番リソースを開発環境やテスト環境から完全に分離できます。開発環境の設定ミスが本番環境に影響することはありません。請求の粒度 — 各部門のサブスクリプションから個別に請求書が作成されるため、コストを明確に配分できます。サブスクリプションの制限 — Azure にはサブスクリプション単位のクォータがあります（例: 1 リージョンあたり 250 VM）。大規模なワークロードでは、制限内に収めるために複数のサブスクリプションが必要になる場合があります。

管理グループとは

管理グループは、Azure の階層構造でサブスクリプションの上位に位置するコンテナーです。サブスクリプションを管理グループにまとめ、管理グループのレベルでAzure Policy 定義やRBAC ロールの割り当てを適用できます。これらはグループ内のすべてのサブスクリプションとリソースに継承されます。そのため、数十個のサブスクリプションごとに同じポリシーやロールの割り当てを重複して設定する必要がなくなります。

# Create a management group
az account management-group create \
  --name mg-production \
  --display-name 'Production Workloads'

# Move a subscription into the management group
az account management-group subscription add \
  --name mg-production \
  --subscription <subscription-id>

管理グループの階層

管理グループは最大 6 階層まで入れ子にできます。すべての Azure ディレクトリの最上位には、1 つのルート管理グループがあります。その配下に、ほかのすべての管理グループとサブスクリプションが配置されます。一般的なエンタープライズの階層は、次のようになります。Root → Company → Platform → Production → Landing Zones → 個別のワークロード用サブスクリプション。Root レベルで適用したポリシーは、ディレクトリ全体のすべてのサブスクリプションに影響します。

// Example management group hierarchy:
// Root Management Group
//   Company (mg-company)
//     Platform (mg-platform)
//       Identity (sub: identity)
//       Connectivity (sub: connectivity)
//     Landing Zones (mg-landingzones)
//       Production (mg-production)
//         App1 (sub: app1-prod)
//         App2 (sub: app2-prod)
//       Dev/Test (mg-devtest)
//         App1 Dev (sub: app1-dev)

階層を通じた RBAC の継承

階層内の任意のレベルで設定したアクセス制御の割り当ては、下位へ継承されます。管理グループに対してユーザーに Reader ロールを割り当てると、その管理グループ内のすべてのサブスクリプションとリソースグループに対する Reader アクセスが自動的に付与されます。この継承は加算的です。下位のスコープで継承されたアクセス許可を取り消すことはできず、追加のアクセス許可を付与することだけができます。例外は拒否の割り当てです。拒否の割り当ては、ロールの割り当てによって許可されるアクションであってもブロックします。

# Assign a role at management group scope
az role assignment create \
  --assignee security-team@mycompany.com \
  --role 'Security Reader' \
  --scope /providers/Microsoft.Management/managementGroups/mg-company

階層を通じたポリシーの継承

同様に、管理グループレベルのAzure Policy の割り当ては、そのグループ内のすべてのサブスクリプション、リソースグループ、リソースに適用されます。一般的な方法として、ルートまたは会社の管理グループに企業ベースラインポリシーを割り当て、許可するリージョン、必須タグ、診断設定などの標準を組織全体に適用します。一方、個々のサブスクリプション所有者は、企業ベースラインを上書きすることなく、下位のスコープにさらに具体的なポリシーを追加できます。

# Assign a policy at management group level
az policy assignment create \
  --name 'require-tags-mgmt' \
  --policy 'your-policy-definition-id' \
  --scope /providers/Microsoft.Management/managementGroups/mg-company

サブスクリプションのライフサイクル管理

Azure のサブスクリプションは、作成、名前変更、キャンセル、および管理グループ間の移動が可能です。サブスクリプションを別の管理グループへ移動すると、そのサブスクリプションに適用されるポリシーとロールの割り当てが変わります。ポリシーの変更は、サブスクリプション内のすべてのリソースに直ちに反映されます。サブスクリプションをキャンセルすると、リソースの作成が無効になり、猶予期間の後にその中のすべてのリソースが最終的に削除されます。そのため、この操作は十分に計画したうえで実行してください。

# Move a subscription to a different management group
az account management-group subscription add \
  --name mg-production \
  --subscription <subscription-id>

# Remove a subscription from a management group
az account management-group subscription remove \
  --name mg-devtest \
  --subscription <subscription-id>

Enterprise Agreement と MCA

大規模な組織は、サブスクリプションの構成に影響する請求契約を通じて Azure を利用します。Enterprise Agreement (EA) は、まとまった利用額を契約する大規模組織向けに、中央の請求アカウントで登録単位のサブスクリプションを提供します。Microsoft Customer Agreement (MCA) はその後継となる最新の契約で、より多くのサブスクリプション管理をセルフサービスで行えます。どちらの契約でも、請求プロファイルと請求書セクションを使用して、部署ごとにサブスクリプションの料金をまとめられます。

サブスクリプションのクォータと上限

すべての Azure サブスクリプションにはサービスクォータがあります。これは、リージョンごとに作成できる各種類のリソース数に対する、緩和可能な上限です。既定値の例として、リージョンあたり 20,000 vCPU、サブスクリプションあたり 980 リソースグループ、サブスクリプションあたり 800 マネージドディスクがあります。ワークロードがクォータに近づいた場合は、Azure portal でクォータ増加要求を送信できます（Support + troubleshooting > New support request）。大規模なスケールアウトでは、複数のサブスクリプションにワークロードを分散することを Microsoft は推奨しています。

# View current vCPU quotas for a region
az vm list-usage \
  --location eastus \
  --query '[].{Name:name.value, CurrentValue:currentValue, Limit:limit}' \
  --output table

管理グループのベストプラクティス

Microsoft は、管理グループを設計する際のベストプラクティスをいくつか推奨しています。入れ子の階層は 3～4 レベルを超えないようにします。レベルが多すぎると、ポリシーのトラブルシューティングが複雑になります。共有サービス（ID、接続、管理）用に専用の Platform 管理グループを作成します。ランディングゾーンのワークロードとは分離してください。Production と Non-Production を別の管理グループに分けます。これにより、パブリックインターネットアクセスの無効化など、本番環境専用のポリシーが開発環境に誤って適用されるのを防げます。

クイックチェック

このレッスンで扱った Microsoft Azure Fundamentals (AZ-900) の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、Azure のリソース階層は、管理グループ、サブスクリプション、リソースグループ、リソースの順に構成されること、管理グループレベルのポリシーと RBAC の割り当ては、すべての子サブスクリプションへ下位に継承されること、そして複数のサブスクリプションによって、請求の分離、環境の分離、サブスクリプション単位のクォータへの対処が可能になることを学びました。次は Azure Policy について詳しく説明します。

よくある質問