Azureの“スコープ”を基礎から理解する：VM作成エラーから学ぶサブスクリプション管理

本記事は新人ブログマラソン2025 2/9付の記事です。

こんにちは。2025年にSCSKへ入社した出口です。

本記事では、Azure の重要概念である「スコープ」をテーマに、AZ-900 ラーニングパスの演習中に実際に発生した仮想マシン（VM）作成エラーを題材として解説します。単なるエラー紹介ではなく、「なぜサブスクリプションというスコープが影響したのか」を整理することで、Azure におけるリソース管理の理解を深めることを目的としています。

演習の内容と環境
発生したエラーと表面的な原因
Azureの重要概念：スコープ
解決策
まとめ
振り返り(学びと所感)

演習の内容と環境

この演習は、AZ-900 ラーニングパス内の「Azure コンピューティングサービスとネットワークサービス：演習 – Azure 仮想マシンを作成する」が対象です。

社内アカウントではリソース作成に必要な権限が不足していたため、検証には個人用の Azure サブスクリプションを新たに作成して実施しました。

演習の流れは次のとおりです。
1. リソースグループの作成

2. 仮想マシン（VM）の作成

3. VM 上に Nginx をインストール

リソースグループ作成は問題なく完了したため、本記事では②仮想マシン(VM)の作成にフォーカスして解説します。

以下のコマンドを使用して、仮想マシンの作成を試みました。

az vm create --resource-group "IntroAzureRG" --name my-vm --size Standard_D2s_v5 --public-ip-sku Standard --image Ubuntu2204 --admin-username azureuser --generate-ssh-keys

発生したエラーと表面的な原因

エラーメッセージの要点は次のとおりです。

(QuotaExceeded) Operation could not be completed as it results in exceeding approved standardDSv5Family Cores quota.

Location: eastus

Current Limit: 0

Additional Required: 2

このメッセージから、eastus リージョンで Standard_D2s_v5（DSv5 ファミリ）に割り当てられている vCPU クォータが 0 のため、必要な 2 vCPU を確保できないことが分かります。

つまり、このサブスクリプションでは eastus リージョンにおいて Standard_D2s_v5 の VM を作成できない状態であることが分かります。

az vm list-usage コマンドでも確認したところ、DSv5 ファミリの vCPU クォータは CurrentValue / Limit ともに 0 であることが分かりました（下図）。

Azureの重要概念：スコープ

Azure では、リソース管理とアクセス制御のために 階層構造（スコープ） を採用しており、主に次の 4 階層で構成されています。今回のエラーは、このうち サブスクリプションというスコープ に設定されているクォータが影響していました。

管理グループ：複数のサブスクリプションをまとめて管理し、ポリシーや RBAC を一括適用できる最上位のスコープ
サブスクリプション：課金単位となるスコープであり、リソースのデプロイ制限（クォータ）や RBAC の適用単位となる
リソースグループ：同じライフサイクルを持つ関連リソースを論理的にまとめる単位
リソース：仮想マシン、ストレージアカウント、仮想ネットワークなどの実体

以下の図では、管理グループ → サブスクリプション → リソースグループ → リソースという階層構造を視覚的に確認できます。今回、私が操作していたのは リソースグループとリソースのみでしたが、エラーの原因はその上位である サブスクリプション にありました。

また、公式ドキュメントでも、スコープは「必要なアクセスのみを付与する」ための重要な概念であると説明されています。RBAC のロールをどのスコープに割り当てるかによって、アクセス可能なリソースの範囲が決まります。

Azure RBAC のスコープについて

スコープ は、アクセスが適用されるリソースのセットです。ロールを割り当てるときは、実際に必要なアクセスのみをセキュリティプリンシパルに付与できるように、スコープを理解することが重要です。スコープを制限することで、セキュリティプリンシパルが侵害された場合に危険にさらされるリソースを制限します。(公式ドキュメントより引用)

RBAC（ロールベースアクセス制御）は、これらのスコープに対してアクセス権限を割り当てる仕組みです。今回のエラーの直接原因は RBAC ではありませんが、クォータも「サブスクリプション」というスコープに紐づく設定 である点が重要です。

私はリソースグループと VM（リソース）の作成を行っていましたが、その上位スコープであるサブスクリプションに設定された vCPU クォータ（DSv5 ファミリ：0）によって作成がブロックされていました。リソースグループ側をいくら確認しても原因が見つからなかったのは、確認すべきスコープが一段上だったためです。

解決策

VM サイズを Standard_D2s_v5 から Standard_B1sに変更することで、クォータ制限によるエラーを解消できました。Standard_B1s は B シリーズに属しており、今回使用したサブスクリプションでは eastus リージョンに十分な vCPU クォータが割り当てられていたためです。

演習手順では、サブスクリプション固有のクォータ設定について説明がありません。そのため、利用しているサブスクリプションごとに使用可能な VM ファミリやサイズが異なる点を理解し、必要に応じてサイズ変更やクォータ確認を行うことが重要だと感じました。

まとめ

今回実行したコマンドは、既存のリソースグループ内に新しい仮想マシン（VM）を作成・起動するためのものです。

しかし、指定した VM サイズ（Standard_D2s_v5）が属する DSv5 ファミリに対して、対象リージョン（eastus）におけるサブスクリプションの vCPU クォータが 0 に設定されていたため、必要な vCPU 数（2 vCPU）を確保できず、VM の作成に失敗しました。

この事象はリソースグループの設定ではなく、サブスクリプションという上位スコープで管理される「リージョン別・VM ファミリ別の vCPU クォータ制限」に起因するものです。

解決策としては、主に次の 2 つが考えられます。

1. すでに利用可能な vCPU クォータが割り当てられている VM ファミリ（例：B シリーズ）を利用する
2. 対象リージョンにおける DSv5 ファミリの vCPU クォータ増加申請を行う

クォータの増加申請自体は無料ですが、審査に時間がかかる、または却下される場合があるため、今回は 1 の方法を採用しました。

いずれも、「どのスコープにどのような制限がかかっているか」を意識して確認することが重要です。

振り返り(学びと所感)

・Azure では必要に応じてクォータ増加申請が必要であり、「料金を払えばリソースを無制限に利用できるわけではない」という点を学びました。

・この演習の目的は、Azure で仮想マシンを作成し、Web サーバーをインストールする一連の流れを CLI で体験することでした。AWS と比較すると、Azure はサブスクリプション単位でのクォータ管理や RBAC の適用スコープが明確に体系化されており、リソース作成時の制約がより“見えやすい”と感じました。

・最終的に AZ-900 試験には無事合格できました。演習では実際の Azure ポータルや CLI を操作することで理解が深まりましたが、短時間の利用でも少額の課金が発生する点には注意が必要だと感じました。

・Azureコンピューティングサービスとネットワークサービスについて説明する

・クウォータの概要

・Azure RBAC のスコープについて