TerraformでAzureにリソースを作成しようとすると「RequestDisallowedByAzureMessage」で失敗することがあります。ドキュメント上は利用可能なリージョンでも、サブスクリプションやテナントに適用されたAzure Policyが原因で拒否されるケースが多いです。本記事では原因の切り分けから、許可リージョンの確認手順、Terraform側の実装例、学生/教育アカウントでの注意点までまとめます。
発生するエラーの意味：Azureが「リージョン」をポリシーで拒否している
Terraformでリソース グループ（Resource Group）やVNetを作ろうとした際、次のようなエラーが返ってくることがあります。
Error Code: RequestDisallowedByAzure
Message: Resource was disallowed by Azure: This policy maintains a set of best available regions...
このRequestDisallowedByAzureは、Azure側で「この要求は受け付けない（disallowed）」と判断されたことを示すエラーです。特にメッセージにpolicy（ポリシー）に関する文言が含まれている場合、ほぼ例外なくAzure Policy（または同等のガバナンス設定）によってリージョンが制限されている状況です。
ポイントは、Azure全体としてそのリージョンが存在することと、あなたのサブスクリプションでそのリージョンにデプロイできることは別物だという点です。
「利用可能リージョン」と「自分の契約で使えるリージョン」がズレる理由
Azureのリージョン一覧ページやサービス別の提供状況は、あくまで「Azureとして提供しているか」を示します。しかし実運用では、サブスクリプションやテナントに以下のような制約がかかることが珍しくありません。
| 制約の種類 | 起きること | 典型的な対象 |
|---|---|---|
| Azure Policy（Allowed locations / Allowed resource locations） | 指定リージョン以外への作成がDenyされる | 会社・学校・組織のサブスクリプション、管理グループ配下 |
| 教育/学生向けサブスクリプションの制限 | 利用可能リージョンが最初から絞られている | Azure for Students、教育機関向け環境など |
| コンプライアンス/データ所在地要件 | 特定の地理（Geo）以外を禁止する運用がある | 金融・公共・医療など |
| クォータ/リソース上限 | リージョンやSKUごとの上限で作れない | VM vCPU、Public IP、特定SKUなど |
今回のようにリソース グループの作成時点で落ちる場合は、クォータというよりリージョン制限ポリシーが原因であることが多いです（リソース グループ自体にもlocationがあり、ポリシー評価の対象になり得ます）。
最短で切り分けるチェックリスト
遠回りしないために、まずは次の順番で確認します。
- どのリソースで失敗しているか（リソース グループ作成で失敗するのか、VM作成で失敗するのか）
- エラー詳細に「policy」「allowed locations」「denied」などが含まれているか
- 許可されているリージョン一覧がエラー本文に出ていないか（出るケースがあります）
- ポリシー割り当て（Assignments）でAllowed locations系が割り当てられていないか
| 見る場所 | 確認ポイント | 見つかると嬉しい情報 |
|---|---|---|
| Terraformのエラー出力 | policy関連の文言、policy assignment / definitionのID | どのポリシーがDenyしたか |
| Azureポータルの「アクティビティ ログ」 | 失敗イベントの詳細 | ポリシー評価結果、Deny理由 |
| Azureポータルの「ポリシー」 | 割り当て（Assignments）一覧 | Allowed locations系の設定値（許可リージョン） |
| デプロイ履歴（リソース グループ > デプロイ） | 検証エラー/操作ログ | 許可リージョンの一覧が表示される場合がある |
AzureポータルでAllowed locations（許可された場所）を確認する手順
ポータルでの確認は、慣れていない人でも確実です。次の流れで「どのリージョンが許可されているか」を見に行きます。
- Azureポータルで「サブスクリプション」を開く
- 対象サブスクリプションを選択
- 左メニューから「ポリシー」を開く
- 「割り当て（Assignments）」を表示
- 検索欄でlocationやAllowedで絞り込み
- 「Allowed locations」「Allowed resource locations」などを開き、Parametersの値（許可リージョン）を確認
ここで表示されるリージョン（例：westeurope、eastus、japaneastなど）のみが、あなたの環境で許可されている候補です。ドキュメントに載っているitalynorthやfrancecentralがあっても、割り当て側で除外されていれば作れません。
Azure CLIで「何がDenyしているか」を素早く把握する
GUIが使いづらい環境や、管理者にエビデンスを渡したい場合はCLIが便利です。以下は代表的な確認例です（権限が不足していると取得できないことがあります）。
| 目的 | コマンド例 | ポイント |
|---|---|---|
| Azureが提供するリージョン一覧（参考） | az account list-locations -o table | これは「Azure全体の一覧」で、許可/禁止は反映されません |
| サブスクリプションスコープのポリシー割り当て確認 | az policy assignment list --scope /subscriptions/<SUBSCRIPTION_ID> -o table | Allowed locations系があれば要チェック |
| 割り当ての詳細（Parameters確認） | az policy assignment show --name <ASSIGNMENT_NAME> --scope /subscriptions/<SUBSCRIPTION_ID> | parametersにallowedLocationsなどが入ることが多い |
| ポリシー評価（何がDenyしたか）の追跡 | az monitor activity-log list --status Failed --max-events 20 | 失敗イベントにpolicy関連の詳細が付くことがあります |
注意：管理グループ（Management Group）配下でポリシーが割り当てられている場合、サブスクリプションでの一覧だけでは見えないことがあります。その場合は、管理者に「管理グループ側の割り当て」を確認してもらう必要があります。
Terraformでの解決策：locationを一元管理して「許可リージョン」に合わせる
リージョン制限に引っかかっているなら、基本方針はシンプルです。Allowed locationsに含まれるリージョンを使うこと。Terraform側では、locationを変数化して一括で切り替えられるようにしておくと運用が楽になります。
変数化して切り替える（最小構成）
variable "location" {
type = string
default = "westeurope" # ポリシーで許可されているリージョンを指定
}
resource "azurerm_resource_group" "main" {
name = "rg-tf-vm-ping"
location = var.location
}
resource "azurerm_virtual_network" "main" {
name = "vn-ettf-vm"
address_space = ["10.0.0.0/16"]
location = azurerm_resource_group.main.location
resource_group_name = azurerm_resource_group.main.name
}
resource "azurerm_subnet" "main" {
name = "subnettf-vm"
resource_group_name = azurerm_resource_group.main.name
virtual_network_name = azurerm_virtual_network.main.name
address_prefixes = ["10.0.1.0/24"]
}この形にしておけば、locationを1か所変えるだけで、関連リソースに同じリージョンを適用できます（VNetなどlocationを持つリソースが対象）。
入力ミスを防ぐ：allowed listでvalidationする
チーム運用では「うっかり禁止リージョンを指定してapplyが失敗する」事故が起きがちです。ポリシーで許可されたリージョンを把握したら、Terraform側でバリデーションしておくと、plan段階で止められます。
variable "allowed_locations" {
type = list(string)
default = ["westeurope", "eastus", "japaneast"] # 実環境の許可リージョンに合わせる
}
variable "location" {
type = string
default = "westeurope"
validation {
condition = contains(var.allowed_locations, var.location)
error_message = "指定したlocationは許可されていません。allowed_locationsの範囲で指定してください。"
}
}allowed listは、環境ごとにterraform.tfvarsやワークスペース別のtfvarsで管理すると現実的です。
表記の落とし穴：リージョン名は「表示名」ではなく「内部名」を使う
Azureの画面やドキュメントでは「Italy North」「France Central」のように表示されますが、Terraform（azurermプロバイダ）では多くの場合、内部名のitalynorth、francecentralのような形式を使います。大小文字やスペースの差で別エラーになることがあるため、ポータルのlocation名（内部名）やCLI出力に合わせるのが安全です。
学生・教育向けサブスクリプションでの注意点
Azure for Studentsや教育機関向けのサブスクリプションでは、次のような「利用者側では変更できない制限」が付いていることがあります。
- 利用できるリージョンが限定されている（Allowed locationsが固定されている）
- 特定のリソース種別やSKUが制限される
- クォータが小さく、VM作成などで詰まりやすい
このタイプの環境では、希望のリージョン（例：italynorth）が使えないなら、実務的には「許可リージョンで設計し直す」のが最短です。どうしてもリージョンを自由に選びたい場合は、従量課金（Pay-As-You-Go）等の別サブスクリプションを用意する、または学校/組織の管理者に相談してポリシー変更を検討してもらいます。
リージョン制限以外にもある「似た症状」：許可されていても作れないパターン
Allowed locationsを守っているのにデプロイが失敗する場合、次の要因も疑います。特にVMやマネージドサービスを追加した途端に失敗するなら、こちらの可能性が上がります。
| 原因 | ありがちなエラー/症状 | 対処の方向性 |
|---|---|---|
| VMサイズ（SKU）がリージョン未提供 | 選択したサイズがそのリージョンに存在しない | 別サイズに変更、提供リージョンに変更、SKU確認（az vm list-skus） |
| クォータ不足（vCPUなど） | QuotaExceeded、OperationNotAllowed等 | クォータ申請、別リージョン/サイズ、リソース削減 |
| リソースプロバイダー未登録 | The subscription is not registered to use namespace … | Provider登録（az provider register） |
| ポリシーがリージョンだけでなく種類やSKUも制限 | Allowed SKUs、Allowed resource types等でDeny | 割り当て内容を確認し、例外設定やポリシー更新を依頼 |
| ゾーン要件（Availability Zones）とリージョンの不一致 | ゾーン指定があると作成できない | ゾーン指定を外す、ゾーン対応リージョンへ |
VMサイズ確認の例（Azure CLI）
VMを作る段階で詰まる場合は、リージョンごとのSKUを確認してからTerraformに落とすと手戻りが減ります。
az vm list-skus --location westeurope --all -o table
対処パターンを整理：誰が何をすれば解決に近づくか
| 状況 | 最も現実的な対処 | 補足 |
|---|---|---|
| Allowed locationsが設定されている（自分で変更できない） | 許可リージョンに変更してデプロイ | Terraformのlocationを変数化して切替 |
| 組織ポリシーで禁止されているが、業務上必要 | 管理者にポリシー変更/例外の相談 | データ所在地や監査要件もセットで説明すると通りやすい |
| 学生/教育サブスクリプションでリージョンが限定 | 許可リージョンで設計する、または別サブスクリプションを用意 | 利用者側での解除は基本不可 |
| リージョンは許可されているのにVMだけ作れない | SKU/クォータ/ゾーン対応を再確認 | まずは小さいサイズで検証すると切り分けやすい |
管理者・サポートに相談するときに伝えると早い情報
ポリシー系の問題は、情報が揃っているほど解決が速いです。次を控えて共有すると、やり取りの往復が減ります。
- 失敗した操作（例：Resource Group作成 / VNet作成）と実行日時
- 対象サブスクリプションID、リソース グループ名、指定したlocation
- Terraformのエラーメッセージ全文（policy名やIDが含まれることがある）
- アクティビティ ログの失敗イベント詳細（可能ならJSON）
- もし表示されていれば「許可されているリージョン一覧」
特にエラーメッセージにPolicyAssignmentやPolicyDefinitionの識別子が出ている場合、それをそのまま渡すと管理者はすぐに割り当てを特定できます。
よくある質問
Q. ドキュメントで「利用可能」なのに、なぜ自分だけ使えないのですか？
A. Azure全体の提供状況と、あなたのサブスクリプションのガバナンス（Azure Policy、教育サブスクリプションの制限、組織のコンプライアンス要件など）は別管理です。特にAllowed locationsが割り当てられていると、提供されているリージョンでもDenyされます。
Q. リソース グループのlocationって実体がないのに、なぜ制限されるのですか？
A. リソース グループのlocationは「メタデータの保管場所」として扱われますが、Azure Policyの評価対象になり得ます。Allowed locationsが「リソース グループも含めて制限」する設定だと、最初のリソース グループ作成で止まります。
Q. Terraform側で自動的に「許可リージョン」を取得して選べますか？
A. 理想としては「ポリシーのparametersを読み取って反映」ですが、実務では権限やスコープの問題で難しいことが多いです。まずはポータル/CLIで許可リージョンを確認し、Terraformは変数化・validationで事故を防ぐ運用が現実的です。
Q. どうしてもItaly Northに作りたい場合は？
A. Allowed locationsに入っていない限り、同一サブスクリプションでは作れません。選択肢は（1）管理者にポリシー変更/例外を依頼、（2）別サブスクリプション（従量課金など）で作る、（3）許可リージョンで設計を調整のいずれかになります。
まとめ：RequestDisallowedByAzureMessageは「自分の環境のリージョン制限」を疑う
- RequestDisallowedByAzure（RequestDisallowedByAzureMessage）は、ポリシー等で要求が拒否されたサイン
- まずはAllowed locations（許可された場所）が割り当てられていないか確認し、許可リージョンを特定する
- Terraformはlocationを変数化して一元管理し、validationで禁止リージョン指定を早期に防ぐ
- 学生/教育サブスクリプションでは利用可能リージョンが固定されやすく、解除できないことが多い
- リージョンが許可されていても、VMのSKU・クォータ・プロバイダー未登録など別要因で失敗する場合がある
「ドキュメントに載っているから使えるはず」という前提で詰まったときは、まず契約（サブスクリプション/テナント）のポリシーを疑うのが近道です。許可リージョンが分かれば、Terraformのlocationを合わせるだけでスムーズに解決できるケースがほとんどです。
コメント