Azure で VM やコンテナー、Web アプリをデプロイしたときに、どのテンプレートでも一律に InvalidTemplateDeployment と RequestDisallowedByAzure が返ってしまうと、「自分のテンプレートが悪いのか？」「East US がおかしいのか？」と原因の切り分けに時間がかかりがちです。本記事では、このエラーの正体と Azure Policy によるリージョン制限の仕組み、具体的な確認手順と対策、再発を防ぐための設計のポイントまでまとめて解説します。
Azure で VM／コンテナー／Web アプリ作成時に起こる症状
まずは、実際によくある症状を整理します。ここでは、例として次のような状況を想定します。
- Azure Resource Manager テンプレート（ARM）、Bicep、Terraform、ポータルいずれで作成しても失敗する
- デプロイ先リージョンは East US（
eastus） - 作成しようとしているリソース例
- VM：名前例
hkn8n - App Service プラン：名前例
ASP-N8nResources-b25c - Web App：その他の任意の名前
- VM：名前例
- デプロイ結果は毎回
InvalidTemplateDeploymentで失敗し、詳細を見るとRequestDisallowedByAzureが含まれている
Azure ポータルのデプロイ エラー詳細では、次のようなメッセージが表示されます（例）。
Code: InvalidTemplateDeployment
Message: The template deployment 'xxxxx' is not valid according to the validation procedure.
The tracking id is 'xxxxx'.
See inner errors for details.
InnerError:
Code: RequestDisallowedByAzure
Message: The resource action 'Microsoft.Compute/virtualMachines/write'
is disallowed by one or more policies.
テンプレートの構造を変えても、別リソースを作っても、East US であればすべて同じように落ちるため、「Azure 側の障害？」と考えてしまいがちですが、根本原因は別にあります。
根本原因：Azure Policy によるリージョン制限
この症状の原因は、サブスクリプションに割り当てられた Azure Policy が、デプロイ可能なリージョンを制限しているためです。
特に次のような環境では、この制限に引っかかるケースが多く見られます。
- 教育・試用系サブスクリプション（例：Azure for Students）
- 企業テナント配下のサブスクリプション（コンプライアンスのためリージョンを絞っている場合）
- 管理グループ単位でセキュリティ／コンプライアンス ポリシーが強く設定されている環境
典型的には、Azure Policy の「Allowed resource deployment regions」ポリシーがサブスクリプションに割り当てられており、そのパラメーター「Allowed locations」に記載されたリージョン以外ではリソースを作成できないようになっています。East US がその許可リストに含まれていない場合、どんなテンプレートであっても RequestDisallowedByAzure でブロックされます。
| 項目 | 内容 |
|---|---|
| 制限の単位 | サブスクリプション / 管理グループ（※リソース グループの場所は無関係） |
| 判定に使われる値 | 各リソースの location プロパティ（VM、App Service プラン、ストレージ アカウントなど） |
| 代表的なポリシー名 | Allowed resource deployment regions |
| 代表的なパラメーター名 | Allowed locations（許可されたリージョンの一覧） |
| よくある環境 | Azure for Students、教育機関テナント、コンプライアンス重視の企業テナント |
RequestDisallowedByAzure と InvalidTemplateDeployment の関係
InvalidTemplateDeployment は、ARM テンプレート／Bicep デプロイの「ラッパー」的なエラーです。実際の原因はその内側の innerError に書かれたコードとメッセージになります。
今回のケースでは、内側に RequestDisallowedByAzure があり、メッセージ中に「disallowed by one or more policies」と出ているのが重要なヒントです。この文言が出ている場合、テンプレート構文の誤りではなく、ポリシー違反によるブロックと判断できます。
| エラーコード | 意味 | 確認すべきポイント |
|---|---|---|
InvalidTemplateDeployment | テンプレート デプロイ全体が無効 | innerError のコードとメッセージを最後まで確認する |
RequestDisallowedByAzure | Azure Policy 等により操作が禁止 | どのポリシーに違反しているか（リージョン・SKU・タグなど）を特定する |
ポータルから許可されているリージョンを確認する手順
自分が使っているサブスクリプションで、どのリージョンが許可されているかを確認するには、Azure ポータルの「ポリシー」機能を使います。
ポリシー割り当ての確認手順
- Azure ポータルにサインインする。
- 検索ボックスに「ポリシー」または
Policyと入力し、「ポリシー」を開く。 - 左メニューから 「割り当て」（Assignments）を選択する。
- 割り当て一覧の中から、表示名が 「Allowed resource deployment regions」 もしくは類似の名前（日本語 UI では「許可されたリソースのデプロイ先リージョン」など）になっているものを探してクリックする。
- ポリシー割り当ての詳細画面で、「パラメーター」 タブを開き、「Allowed locations」 の値を確認する。
「Allowed locations」には、実際にデプロイを許可されているリージョンが一覧で表示されます。ここに East US が含まれていない場合、先ほどのようなエラーが必ず発生します。
| UI 表示例 | 意味 | 補足 |
|---|---|---|
| Allowed resource deployment regions | デプロイ可能なリージョンを制限するポリシー | 管理グループ／サブスクリプション単位で割り当てられることが多い |
| Allowed locations | 許可されるリージョンのリスト | このリストに含まれない location を持つリソースは全てブロックされる |
| East US が未登録 | East US では一切デプロイ不可 | VM / App Service / Storage などすべてに影響 |
許可されたリージョンに変更して再デプロイする
Allowed locations が分かったら、次はテンプレートやポータルで指定している location を、その許可リージョンのいずれかに変更します。
ポータルから作成する場合
- VM、コンテナー、App Service などを新規作成する画面で、「リージョン」または 「場所」 のプルダウンから、先ほど確認した許可リージョンを選択する。
- 同一デプロイ内で複数リソースを作る場合は、すべて同じ許可リージョンに統一する。
- 特に App Service 関連では、App Service プランと Web App のリージョン不一致がよくあるので注意する。
ARM テンプレート／Bicep の場合
ARM テンプレートや Bicep では、各リソースの location を許可リージョンに変更します。さらに、再発防止の観点から、location をパラメータ化しておくと便利です。
Bicep の例：
param location string = 'japaneast' // 許可リージョンのひとつをデフォルトに
resource myPlan 'Microsoft.Web/serverfarms@2023-01-01' = {
name: 'ASP-N8nResources-b25c'
location: location
sku: {
name: 'B1'
tier: 'Basic'
}
}
resource myWebApp 'Microsoft.Web/sites@2023-01-01' = {
name: 'hkn8n'
location: location // App Service プランと同じ location を指定
properties: {
serverFarmId: myPlan.id
}
}
このように location を変数化しておけば、許可リージョンが変更になった場合も、パラメーターだけ差し替えることで対応できます。
Terraform の場合
Terraform でも同様に、location（または region）用の変数を用意しておくと柔軟に変更できます。
variable "location" {
description = "Allowed Azure region"
type = string
default = "japaneast"
}
resource "azurerm_app_service_plan" "example" {
name = "ASP-N8nResources-b25c"
location = var.location
resource_group_name = azurerm_resource_group.rg.name
kind = "Linux"
reserved = true
sku {
tier = "Basic"
size = "B1"
}
}
resource "azurerm_linux_web_app" "example" {
name = "hkn8n"
location = var.location
resource_group_name = azurerm_resource_group.rg.name
service_plan_id = azurerm_app_service_plan.example.id
}
App Service で特に起こりやすい落とし穴
App Service（Web App）関連のデプロイでは、次のようなパターンで RequestDisallowedByAzure が発生しやすくなります。
- App Service プランは許可リージョン内だが、Web App の location が別リージョンになっている
- 既存の App Service プランが非許可リージョンにあり、それを参照して新しい Web App を作成しようとしている
- テンプレートの一部のリソースだけ location をハードコードしており、他と不一致になっている
| ケース | 状態 | 結果 |
|---|---|---|
| プランも Web App も許可リージョン | 両方とも japaneast など許可リスト内 | デプロイ成功 |
| プランのみ許可リージョン | プラン：japaneast、Web App：eastus | Web App 作成時に RequestDisallowedByAzure |
| 既存プランが非許可リージョン | 既存プラン：eastus、新規 Web App：eastus | プランの location 自体が非許可のため Web App も作成不可 |
App Service 関連では、「App Service プランと Web App は必ず同じリージョン」「かつそのリージョンがAllowed locations に含まれている」ことを確認するのがポイントです。
CLI からポリシーと許可リージョンを確認する
閲覧権限がある場合は、Azure CLI や PowerShell からポリシー割り当てを確認することもできます。大量のポリシーがある組織環境では、こちらの方が探しやすい場合があります。
Azure CLI の例
# ポリシー割り当ての一覧（表示名とスコープを確認）
az policy assignment list \
--query "[].{name:name, displayName:properties.displayName, scope:properties.scope}" -o table
# 「Allowed」や「Location」を含む割り当てだけ絞り込み
az policy assignment list \
--query "[?contains(properties.displayName, 'Allowed') || contains(properties.displayName, 'Location')].{name:name, displayName:properties.displayName}" -o table
# 特定の割り当ての許可リージョン（パラメーター）を見る
az policy assignment show --name "<AssignmentName>" --query "properties.parameters"
最後のコマンドで表示される properties.parameters の中に、allowedLocations や Allowed locations というキーが含まれていれば、その値が許可リージョンの一覧です。
PowerShell (Az モジュール) の例
Get-AzPolicyAssignment |
Where-Object { $_.Properties.DisplayName -match 'Allowed|Location' } |
Select-Object Name,
@{L='DisplayName';E={$_.Properties.DisplayName}},
@{L='Parameters';E={$_.Properties.Parameters}} |
Format-List
こちらも同様に、パラメーターの中から Allowed locations に相当する項目を探します。必要に応じて、特定のスコープ（サブスクリプション ID や管理グループ）で絞り込むと分かりやすくなります。
Azure for Students でのリージョン制限の特徴
Azure for Students のような教育向けサブスクリプションでは、次のような特徴があります。
- 利用可能なリージョンが 5 前後 に限定されていることが多い
- 許可されているリージョンは、ユーザーやテナントによって異なる場合がある
- サポートを通じて追加リージョンを開放できるかどうかは、契約形態や運用ポリシーに依存する
そのため、「他の人のブログで East US を使っていたから、同じように East US にデプロイしよう」といったやり方はうまくいかないケースがあります。必ず自分のサブスクリプションの Allowed locations を確認し、その中のリージョンを使うようにしましょう。
組織・テナントで別リージョンを使いたい場合の対応
自分のアカウントではポリシーを変更できない（ロールが「共同作成者」「読者」など）場合は、管理者に対応を依頼する必要があります。代表的なパターンは次のとおりです。
- Azure for Students の場合：サポート チームに問い合わせ、追加リージョンを開放できるか相談する
- 企業テナントの場合：テナント／管理グループ／サブスクリプションの管理者に、ポリシーの見直しまたはエクゼンプション（例外設定）を依頼する
なお、セキュリティやコンプライアンスの観点から、特定のリージョンのみ使用を許可しているケースも多いため、「どこでも使えるようにしてください」といったお願いは通らないこともあります。業務・学習目的を整理したうえで、なぜそのリージョンが必要なのかを説明できるようにしておくと良いでしょう。
リソース グループの場所とリソースの location の違い
Azure では、リソース グループの場所と各リソースの location は別々に設定されます。リージョン制限の評価で使われるのは、あくまで「各リソースの location」であり、リソース グループの場所は関係ありません。
| 項目 | 例 | ポリシー評価対象か |
|---|---|---|
| リソース グループの場所 | westeurope | 通常は対象外（※特定ポリシーで制限している場合を除く） |
| VM の location | eastus | 対象（Allowed locations の対象） |
| App Service プランの location | japaneast | 対象 |
| Storage アカウントの location | centralus | 対象 |
そのため、「リソース グループを許可リージョンに作ったから大丈夫」と思っていると、実際には VM や Web App の location が別リージョンになっていて、RequestDisallowedByAzure で失敗する…ということが起こり得ます。テンプレート設計時には、リソース グループとリソースの location をセットで管理することを意識しましょう。
再発防止のための設計・運用のコツ
最後に、同じ問題を繰り返さないための設計・運用上のポイントをまとめます。
location をパラメータ化する
- ARM テンプレート／Bicep／Terraform などの IaC では、location を必ずパラメータ化する
- デフォルト値として、現在の Allowed locations のうち 1 つ（例：
japaneast）を設定しておく - 環境ごと（開発／検証／本番など）に location の値を切り替えられるようにする
パイプラインで事前チェックを行う
CI/CD パイプラインを使っている場合、デプロイ前に使用予定の location が Allowed locations に含まれているか自動チェックすることで、エラーの早期検出が可能になります。
- Azure CLI で Allowed locations を取得し、テンプレートの location パラメータと突き合わせる
- 許可されていない場合は、デプロイ ステップに進む前にパイプラインを失敗させる
複数リソースの location を統一する
特に App Service や VM + ディスク + NIC など、複数リソースがセットになっている場合は、テンプレート内で参照を使って 1 箇所の location を共有する設計がおすすめです。
param location string = 'japaneast'
resource rg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
name: 'rg-example'
location: location
}
resource vm 'Microsoft.Compute/virtualMachines@2023-03-01' = {
name: 'vm-example'
location: location
...
}
このようにしておけば、「VM だけ East US になっていて気づかなかった」といった人的なミスを減らせます。
| 対策 | 期待できる効果 |
|---|---|
| location のパラメータ化 | 環境ごとのリージョン違いに柔軟に対応できる |
| パイプライン前段での Allowed locations チェック | デプロイ実行前にポリシー違反を検出し、無駄なデプロイ試行を防止 |
| 複数リソースの location 統一（参照共有） | テンプレート変更時の location 不整合を防止し、App Service などのエラーを減らす |
実際の解決結果のまとめ
冒頭のケースでは、Azure Policy の割り当てを確認したところ、サブスクリプションに「Allowed resource deployment regions」ポリシーが設定されており、その「Allowed locations」に East US が含まれていませんでした。
そこで、テンプレートの location を Allowed locations に含まれるリージョン（例：japaneast、eastasia 等）に変更して再デプロイしたところ、VM／コンテナー／Web アプリは問題なくデプロイに成功しました。
このように、RequestDisallowedByAzure が出た場合は、テンプレート自体を疑う前に、Azure Policy によるリージョン制限を最優先で確認するのが効率的です。
トラブルシューティングのチェックリスト
最後に、同様のエラーに遭遇したときに確認すべきポイントをチェックリスト形式でまとめます。困ったときはここを一つずつ潰していくと、原因にたどり着きやすくなります。
- エラー詳細で innerError を確認したか？
InvalidTemplateDeploymentだけでなく、その内側にRequestDisallowedByAzureやdisallowed by one or more policiesの文言がないか調べる。
- ポータルの「ポリシー → 割り当て」でリージョン制限ポリシーを確認したか？
Allowed resource deployment regionsや「許可されたリソースのデプロイ先リージョン」がないか、Allowed locations の内容を確認する。
- テンプレートの location が Allowed locations に含まれているか？
- VM、App Service プラン、Web App、ストレージ アカウントなど、すべてのリソースの location を確認する。
- App Service プランと Web App のリージョンは一致しているか？
- リソース グループの場所とリソースの location を混同していないか？
- Azure for Students など教育／試用サブスクリプション固有の制限を把握しているか？
- 自分でポリシーを変更できない場合、管理者やサポートに相談したか？
- 今後のために location をパラメータ化し、パイプラインでの事前チェックを検討したか？
これらを順番に確認していけば、「どのテンプレートを使っても East US で RequestDisallowedByAzure が出てしまう」といった状況でも、落ち着いて原因を切り分け、最短ルートで解決にたどり着くことができます。
Azure で VM やコンテナー、Web アプリを安心してデプロイするためには、リソース設計だけでなく、サブスクリプションに適用されているポリシーやリージョン制限の仕組みを理解しておくことが非常に重要です。今回のポイントを押さえておけば、似たようなエラーに対しても素早く対応できるようになるはずです。
コメント