Azure の正しい始め方④ - サブスクリプション、管理グループ、リソースグループ

Azure の正しい始め方 ①-④

本記事について

本記事では Azure の始め方第四弾として、サブスクリプションの管理と管理グループ・リソースグループの設計について見ていきます。

サブスクリプションの管理

前回までの記事で、Azure にサインアップするとひとつサブスクリプションが作成されることをご紹介しました。Azure ではこのサブスクリプションにリソースを作成していきます。今回はこのサブスクリプションについて詳細を見ていきます。

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

Azure におけるサブスクリプションとは、課金・管理・スケールの単位です。

Azure のリソースはすべてそれぞれひとつのサブスクリプションに紐づいて作成され、そのサブスクリプションごとに請求がされます。

また、サブスクリプションに対してアクセス権を設定することで、そのサブスクリプション配下のリソースを管理することができます。

サブスクリプションはスケールの単位でもあり、リソースのクォータをサブスクリプション単位で要求したり、Azure の既定のリソース数やパフォーマンスの制限がサブスクリプション単位で設定されていたりします。

サブスクリプションをどの単位で区切るべきか？

サブスクリプションをどの単位で区切るべきか？という問いに対して、ひとつの絶対的な回答はありません。ただし、アンチパターンとしては、ひとつのサブスクリプションに組織内のリソースをすべて詰め込むというものがあります。逆に言うと、それなりの単位 (システム・アプリケーション単位、プロジェクト単位、開発・検証・本番単位など) で分割することが推奨になっています。

特に分割に際し、以下の考慮ポイントを見ておくと良いです。

• 適切な権限分掌を行う。

• サブスクリプション単位で設定されているリソース数上限を避ける。クォータ申請がサブスクリプション単位のため、利用したいサービスにクォータがある場合はそのサブスクリプションで利用するようにする。

• Defender for Cloud など重要なセキュリティ機能の ON/OFF がサブスクリプション単位になっているため、セキュリティレベルが異なるものは別サブスクリプションにする。

• 課金の明確な単位（共有ネットワーク（ExpressRoute, Firewall など）はコアネットワーク用サブスクリプションに入れるなど）として利用する。

• 特定の仮想ネットワークに入れる仮想マシンは、仮想ネットワークと同じサブスクリプションに存在する必要がある。

VM に接続された各 NIC は、VM と同じ場所およびサブスクリプションに存在する必要があります。 NIC と同じ Azure の場所およびサブスクリプションに存在する VNet に各 NIC を接続する必要があります。

管理グループによる複数のサブスクリプションの管理

多くのケースで組織内で複数のサブスクリプションを運用することになります。その際にアクセス権設定やポリシーは一元的に構成したいというニーズが出てきます。それを満たす機能が 2018年にリリースされた 管理グループ (Management Group) という機能になります。

管理グループの仕組み

管理グループはサブスクリプションをまとめる仕組みです。Microsoft Entra ID テナントの最上位のグループとして、テナントルート管理グループ (Tenant Root Management Group) が必ず既定で存在しています。その配下に管理グループを作成していきます。管理グループは複数階層持たせることができるため、管理グループの中に管理グループを追加することができます。そして管理グループにサブスクリプションを追加して管理します。(テナントルート管理グループ下にすべての管理グループ・サブスクリプションを配置できることも、シングルディレクトリ構成を採用するメリットの一つです。)

そしてアクセス制御やポリシーは上位の管理グループから下位の管理グループ・サブスクリプションに継承されるため、より共通的に利用したいアクセス権設定やポリシーは上位の管理グループに適用します。

管理グループをどう設計するか？

管理グループをどう設計するか？についてもひとつの決定的な回答はありません。組織の体制やビジネスニーズに合わせて設計いただく必要があります。

ただし、以下の考え方が一般的によく参照されるものになります。

• 事業部門、子会社、海外拠点、などの組織の単位でグループを作ることが一般的（マイクロソフト社も自社運用環境はこのような利用をしている）

• あまり階層を深くしすぎない (2-3層程度に留める) ほうが管理は容易

• テナントルート管理グループはすべてのサブスクリプションに影響するので、全社共通ルールのみを慎重に運用

下記は参考例の一つです。

リソースグループによるサブスクリプション内のリソースの管理

Azure の リソースグループ (Resource Group) は、サブスクリプション内でリソースを束ねるフォルダーとして機能します。すべてのリソースは必ずひとつのリソースグループに入ります。通常、ライフサイクルが同じリソース群を同じリソースグループ内で管理します。

サブスクリプションと違い、リソースグループが異なることによる制限はほとんどありません。 そのため、制約に依るというよりはアクセス権設定やポリシーの割り当て、コスト管理や削除のオペレーションなど、組織の運用に適するようにリソースグループは設計・運用されます。

Azure におけるガバナンス - アクセス制御とポリシー

管理グループ、サブスクリプション、リソースグループの階層構造を正しく構成できると、Azure におけるガバナンスの設計が、かなり見通し良くなります。

次にそのガバナンスを担う機能である、アクセス制御 (IAM) とポリシー (Azure Policy) を見ていきます。

Azure のアクセス制御 (IAM)

Azure のアクセス制御 (IAM) は ロールベースアクセス制御 (RBAC) になっており、特定のロールをユーザーやグループに対して割り当てます。その割り当てのスコープとして、管理グループ、サブスクリプション、リソースグループ、リソースを選んで適用します。

割り当てのスコープは上位から下位に継承されるため、たとえば特定のサブスクリプションをスコープとして割り当てられたロールはそのサブスクリプション内の全リソースグループ・全リソースにも適用されます。

Azure のロール - 組み込みロールとカスタムロール

Azure では 組み込みロール として様々なロールが定義されています。大半の業務はこの組み込みロールを割り当てることで実現できます。

もしこの組み込みロールではロールとして不十分な場合、カスタムロールを利用することができます。カスタムロールの作成については下記をご参照ください。ただしカスタムロールを作りすぎるとそのメンテナンスや管理が困難になるため、カスタムロールの利用は最小限にとどめることが推奨です。

Azure Policy

アクセス権設定と並んでガバナンスで重要になるのが Azure Policy です。Azure Policy はリソースの設定を強制したり、特定のリソースの作成を禁止したり、タグ付けを自動化したりすることができます。

すべてを Azure Policy でがちがちに固めて運用するというのは現実的ではないことも多いですが、たとえばセキュリティ機能の有効化や特定のタグの強制、一部リソースの作成禁止など、あらかじめ制御したい事項がある場合は Azure Policy を活用できます。

(補足) 命名規則

ガバナンスを考えるに際し、統合的なリソースの管理のために事前に命名規則を定めておくことがおすすめです。Azure の公式ドキュメントでは、命名規則についてのガイダンスも出しています。

サブスクリプションの管理の Next Step- Landing Zone と標準ガイドライン

本記事では管理グループやリソースグループといった最も基本的なサブスクリプションやリソース管理の仕組みをご紹介しました。ですが、実際に Azure をガバナンスやセキュリティを担保しながら利用するには、より多くの考慮点が存在します。

ここではより発展的な Azure の利用の道しるべとなる２つのリソースをご紹介します。

1. Landing Zone (ランディングゾーン)

Landing Zone (ランディングゾーン) とは、組織がクラウドを利用する際にガバナンスとセキュリティを担保するために共通の設計原則に基づき整備され、共通的に利用されるターゲットアーキテクチャを指します。

Azure の Cloud Adoption Framework (CAF, クラウド導入フレームワーク) では、以下9カテゴリを考慮したランディングゾーンを整備することを推奨しています。

また、下記に Landing Zone なしとありの場合の比較を図式化しています。この図は少し極端ではありますが、Landing Zone を用意し共通のアーキテクチャを採用することで、組織としてガバナンスをもって Azure のサブスクリプションやリソースの管理を行えることがわかるかと思います。

特定のプロジェクトの開発・検証利用を超え、Azure を組織として大規模に利用する際は、Landing Zone を組織内で整備したうえで利用拡大していくことが望ましいです。

また Landing Zone についてはマイクロソフト社のウェビナーでも学ぶことができます。

このウェビナーでも紹介されているランディングゾーンの設計・構築ガイドはこちらで展開されていらっしゃいます。

2. 標準化ガイドライン

Landing Zone と並んで、Azure のアーキテクチャ設計のガイドになるのが、Azure 標準化ガイドラインです。こちらは日本マイクロソフトのエンジニアがまとめた、ベストプラクティスベースの Azure の設計指針のテンプレートになっています。

章立てされた各項目について、基礎知識、検討のポイント、ガイドラインサンプルがまとまっています。特に組織内で Azure 利用のガイドラインを策定したい場合、こちらをご参照いただけると良いかと思います。

リリースノート

最後に

Azure の正しい始め方と題して、課金アカウントやサブスクリプション、Microsoft Entra ID のアーキテクチャ構成やそれぞれの仕組みについて、記事４本を通してご紹介してきました。(「正しい」と銘打っていますがあくまで私見にすぎない点ご了承ください。)

Azure Open AI Service をはじめ、Microsoft Azure が話題になることが増える中で、Azure をよりガバナンスやセキュリティを担保してご活用いただく一助となれば幸いです。

＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。