跳到主要内容

Azure管理階層と命名規則

Azureリソースを効果的に管理するためには、管理階層（Hierarchy）の理解と、一貫した命名規則の適用が不可欠です。本ドキュメントでは、Azureの主要な管理単位と、Microsoft Cloud Adoption Framework (CAF) に基づくベストプラクティスを解説します。

Azureの管理階層​

Azureの管理構造は、以下の4つのレベルで構成されています。

  1. 管理グループ (Management Groups)
  2. サブスクリプション (Subscriptions)
  3. リソースグループ (Resource Groups)
  4. リソース (Resources)

これらは親子関係を持ち、上位レベルで適用されたポリシーやアクセス権限は下位レベルに継承されます。

1. テナント (Tenant) / Microsoft Entra ID​

厳密にはAzureリソースの階層構造の外側に位置しますが、アイデンティティとアクセスの境界を定義します。

  • 1つの組織（企業）を表すインスタンス。
  • ユーザー、グループ、アプリケーションの認証情報を管理。

2. 管理グループ (Management Groups)​

複数のサブスクリプションをグループ化して管理するためのコンテナです。

  • 用途: 組織全体のガバナンス、ポリシー適用、コンプライアンス管理。
  • 例: 「本番環境」「開発環境」や「事業部」ごとにグループ化し、共通のポリシー（例：特定のリージョンのみ使用許可）を適用。

3. サブスクリプション (Subscriptions)​

リソースの論理的なコンテナであり、課金とアクセス制御の主要な境界線です。

  • 用途: コスト管理の単位、技術的な制限（クォータ）の境界。
  • 戦略:
    • ワークロード分離: 本番環境(Production)と非本番環境(Non-Production)でサブスクリプションを分ける（推奨）。
    • カテゴリ分離: アプリケーションの種類や事業部ごとに分ける。

4. リソースグループ (Resource Groups)​

Azureリソースを論理的にグループ化するコンテナです。すべてのリソースは必ず1つのリソースグループに属します。

  • ライフサイクル管理: 同じライフサイクル（作成、更新、削除）を持つリソースをまとめる。
  • 権限管理: 特定のプロジェクトメンバーにのみアクセス権を付与する単位。
  • ベストプラクティス:
    • リソースグループを削除すると、中のリソースもすべて削除されるため、環境のクリーンアップに利用できる。
    • 異なるライフサイクルのリソース（例：永続的なDBと一時的なVM）は別のグループにすることを検討する。

命名規則 (Naming Conventions)​

一貫した命名規則は、リソースの特定、管理、トラブルシューティングを容易にします。Microsoft CAFでは以下の構成要素を組み合わせることを推奨しています。

基本フォーマット: [リソース種類]-[ワークロード/アプリ名]-[環境]-[リージョン]-[インスタンス番号]

推奨される省略形​

リソース種類省略形例
Resource Grouprgrg-myapp-prod-001
App Service Planaspasp-myapp-prod-eastus-001
App Service (Web App)appapp-myapp-prod-eastus-001
Function Appfuncfunc-myapp-prod-eastus-001
SQL Serversqlsql-myapp-prod-eastus-001
SQL Databasesqldbsqldb-myapp-prod-eastus-001
Storage Accountststmyappprod001 (小文字英数字のみ)
Virtual Networkvnetvnet-myapp-prod-eastus-001
Key Vaultkvkv-myapp-prod-001

注意点​

  • スコープの一意性: Storage AccountやKey Vaultなど、グローバルで一意な名前が必要なリソースがある。
  • 文字制限: リソースによって使用可能な文字種（ハイフン不可など）や長さ制限が異なる。
  • 変更不可: リソース名は作成後に変更できないため、慎重に決定する。

タグ付け戦略 (Tagging Strategy)​

名前だけでなく、タグを使用してメタデータを付与することで、コスト分析や運用管理が効率化されます。

推奨されるタグ​

  • Owner: リソースの責任者（メールアドレスなど）
  • Environment: Production, Staging, Development
  • CostCenter: 請求先の部門コード
  • Application: 関連するアプリケーション名
  • Criticality: High, Medium, Low (災害復旧の優先度判断などに利用)

ベストプラクティスまとめ​

  1. 階層構造の設計: 管理グループを活用して、組織全体のガバナンスを効かせる。
  2. サブスクリプションの分離: 本番環境と開発環境はサブスクリプションレベルで分離し、セキュリティリスクと誤操作を防ぐ。
  3. リソースグループのライフサイクル: 一緒にデプロイ・削除されるリソースを同じグループにする。
  4. 命名規則の徹底: 自動化やIaC (Infrastructure as Code) の導入を見据え、ルールを文書化し遵守する。
  5. タグの活用: コスト配分や運用自動化のために、必須タグポリシーを適用する。