MENU

ServerFarmCreationNotAllowedでAzure FunctionsのApp Service Plan（Consumption Y1）をARMテンプレートから作成できない時の対処法｜FortiGate Autoscale対応

Azure

FortiGate Autoscale を Pay‑As‑You‑Go サブスクリプションへ ARM テンプレートで展開した際、App Service Plan（ServerFarm）だけが ServerFarmCreationNotAllowed で失敗し、ポータルや CLI の手動作成だと成功する――。本記事では原因の正体（サブスクリプションのバックエンド制限）、解除依頼の進め方、Consumption（Y1）を確実に作るテンプレ設計、VMSS コア数クォータの同時対応までを一気通貫で解説します。

目次

現象の全体像と再現条件

FortiGate Autoscale の公式 ARM テンプレートを Pay‑As‑You‑Go（従量課金）サブスクリプションにデプロイすると、Function App 用の App Service Plan（Microsoft.Web/serverfarms）作成が失敗し、次のようなエラーが返ることがあります。

{
  "status": "Failed",
  "error": {
    "code": "ServerFarmCreationNotAllowed",
    "message": "The server farm cannot be created for this subscription in this region."
  }
}
  • 同一の構成を Azure ポータルや Azure CLI（az functionapp plan create --sku Y1 ...）で手動作成すると成功。
  • VMSS（仮想マシン スケール セット）など他のリソースはデプロイされる（またはクォータ不足で別途失敗）。
  • 利用したいプランは Consumption（Y1, tier=Dynamic）。

この矛盾を生む直接原因はテンプレートの記述ではなく、「サブスクリプションに対して特定リージョンでの Microsoft.Web/serverfarms の ARM デプロイを抑止する内部フラグ（バックエンド制限）」が効いているためです。手動作成経路では通る（※同じ RP でも内部の経路差異や判定タイミング差異がある）ため、テンプレート経由のみ失敗しているように見えます。

結論：Microsoft サポートでバックエンド制限を解除してもらう

最短の解決は、Microsoft サポートに依頼して対象サブスクリプションの該当リージョンでの Microsoft.Web/serverfarms ARM デプロイ制限を解除してもらうことです。実際の対応例として、East US リージョンについて内部解除後にテンプレート再実行で正常デプロイを確認しています（2025‑09 時点で East US 限定の運用）。

サポート依頼フロー（例）

  1. Azure Portal → Help + support → New support request。
  2. Issue type：Technical（技術）、Service：App Service または Functions を選択。
  3. Problem type：Resource deployment via ARM/Bicep を選び、以下を記載して送信。
    • エラー コード：ServerFarmCreationNotAllowed
    • 影響リソース：Microsoft.Web/serverfarms（App Service Plan for Function App）
    • サブスクリプション ID、リソース グループ、リージョン（例：East US）
    • 手動（Portal/CLI）では作成成功、ARM テンプレートのみ失敗する旨
    • テンプレートの Sku：Y1（Consumption）/tier=Dynamic
    • 解除希望：「該当サブスクリプションにおける Microsoft.Web/serverfarms の ARM デプロイ制限の解除」

解除が反映されたら、テンプレートをリトライします。特に East US は解除実績があるため、まず同リージョンでの再試行が推奨です。

再デプロイ前のチェックポイント

項目推奨設定／確認方法
リージョンEast US（解除実績あり）。他リージョンで失敗する場合は同様の解除依頼を検討。
プラン SKUsku.name="Y1" / sku.tier="Dynamic"（Consumption）。capacity は不要。
プラン種別（Linux/Windows）Linux 消費プランは kind="functionapp,linux" ＋ properties.reserved=true、Windows は kind="functionapp" ＋ reserved=false。
RP 登録az provider show --namespace Microsoft.Web --query "registrationState" が "Registered"。未登録なら az provider register -n Microsoft.Web。
ストレージ アカウント同一 RG・リージョンに Standard GPv2 LRS を事前作成（Function App の AzureWebJobsStorage 用）。
API バージョンテンプレート内の Microsoft.Web / Microsoft.Storage の API バージョンを揃え、古すぎるものは更新。
デプロイ前検証az deployment group what-if で差分と作成順序（dependsOn）を確認。
VMSS クォータ別途「Virtual Machine Scale Sets」コア数の増枠を申請（後述）。

ARM テンプレート設計：Consumption（Y1）を確実に通す書き方

以下は Linux 消費プラン（Y1）＋ Function App の最小構成例です。Windows 消費プランにしたい場合は kind と reserved を調整してください。

最小構成（JSON）

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": { "type": "string", "defaultValue": "eastus" },
    "planName": { "type": "string" },
    "functionAppName": { "type": "string" },
    "storageAccountName": { "type": "string", "minLength": 3, "maxLength": 24 }
  },
  "variables": {},
  "resources": [
    {
      "type": "Microsoft.Storage/storageAccounts",
      "apiVersion": "2023-01-01",
      "name": "[parameters('storageAccountName')]",
      "location": "[parameters('location')]",
      "kind": "StorageV2",
      "sku": { "name": "Standard_LRS" },
      "properties": {
        "allowBlobPublicAccess": false,
        "minimumTlsVersion": "TLS1_2"
      }
    },
    {
      "type": "Microsoft.Web/serverfarms",
      "apiVersion": "2022-03-01",
      "name": "[parameters('planName')]",
      "location": "[parameters('location')]",
      "kind": "functionapp,linux",
      "sku": { "name": "Y1", "tier": "Dynamic" },
      "properties": {
        "reserved": true,
        "perSiteScaling": false
      }
    },
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2022-03-01",
      "name": "[parameters('functionAppName')]",
      "location": "[parameters('location')]",
      "kind": "functionapp,linux",
      "dependsOn": [
        "[resourceId('Microsoft.Web/serverfarms', parameters('planName'))]",
        "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
      ],
      "properties": {
        "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', parameters('planName'))]",
        "httpsOnly": true,
        "clientAffinityEnabled": false,
        "siteConfig": {
          "linuxFxVersion": "DOTNET|8.0",
          "ftpsState": "FtpsOnly",
          "appSettings": [
            { "name": "FUNCTIONS_WORKER_RUNTIME", "value": "dotnet-isolated" },
            { "name": "FUNCTIONS_EXTENSION_VERSION", "value": "~4" },
            {
              "name": "AzureWebJobsStorage",
              "value": "[concat('DefaultEndpointsProtocol=https;AccountName=', parameters('storageAccountName'), ';AccountKey=', listKeys(resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName')), '2023-01-01').keys[0].value, ';EndpointSuffix=', environment().suffixes.storage)]"
            }
          ]
        }
      }
    }
  ]
}

ポイント

  • sku は { name: "Y1", tier: "Dynamic" } のみ。capacity を書かない。
  • Linux の場合は kind="functionapp,linux" と properties.reserved=true を忘れない。
  • Consumption では alwaysOn は無効（設定しない）。
  • AzureWebJobsStorage は本番では Key Vault 参照を推奨。例では簡潔さを優先し listKeys() を利用。

Windows 消費プランに切り替える場合

"kind": "functionapp",
"properties": { "reserved": false }

既存プラン参照で回避する（暫定策）

一時的なワークアラウンドとして、先にポータル/CLI で Y1 プランを作成し、その resourceId をテンプレートに渡して serverfarms の新規作成を行わない方法が有効です。JSON ARM では「既存リソース宣言」はできないため、sites.properties.serverFarmId に文字列で resourceId() を渡します。

{
  "parameters": {
    "existingPlanResourceId": { "type": "string" }
  },
  "resources": [
    {
      "type": "Microsoft.Web/sites",
      "apiVersion": "2022-03-01",
      "name": "[parameters('functionAppName')]",
      "properties": {
        "serverFarmId": "[parameters('existingPlanResourceId')]"
      }
    }
  ]
}

デプロイが安定する依存関係（dependsOn）設計

  • Function App は App Service Plan と Storage に依存させる。
  • FortiGate Autoscale のテンプレートに組み込む場合、VMSS → VNET → LB/NSG → Diagnostics/Log Analytics の依存も崩さない。
  • what-if で作成順序と差分（置換/更新）を毎回検証する。

CLI/Portal での事前確認コマンド集

# Microsoft.Web の登録状態
az provider show --namespace Microsoft.Web --query "registrationState"

# 必要に応じて登録

az provider register -n Microsoft.Web

# Storage API キーの動作テスト

az storage account keys list -g  -n 

# デプロイ検証（what-if）

az deployment group what-if -g  -f main.json -p @parameters.json

# 実デプロイ（詳細ログ）

az deployment group create -g  -f main.json -p @parameters.json --verbose

VMSS コア数クォータの引き上げ（補足）

FortiGate Autoscale は VMSS を伴うため、リージョンあたりの vCPU 上限に達していると VMSS が割り当て失敗します。以下の順序で対応してください。

  1. 現在の使用量と上限を確認 # 従来の使用量確認 az vm list-usage -l eastus -o table #（必要に応じて）クォータ拡張コマンドを使う場合は拡張機能を追加 az extension add --name quota # 標準 vCPU の現状 az quotas list --scope "/subscriptions//providers/Microsoft.Compute/locations/eastus"
  2. ポータルから申請
    Azure Portal → Help + support → New support request → Quota → Virtual Machine Scale Sets を選択し、リージョンと必要コア数を入力して送信。
  3. 反映後に ARM を再実行。スケールセットの VM サイズ別上限（ファミリ クォータ）がある場合は、汎用上限とは別に増枠が必要です。

他リージョンでも同じエラーが続く場合の対処

  • 手動作成は成功、ARM だけ失敗なら、同様に リソースプロバイダー（Microsoft.Web/serverfarms）のアンブロック をサポートへ依頼。
  • 解除前の回避として、先にポータル/CLI で Y1 プランを作成し、テンプレートでは 既存プラン参照に切り替える（前述）。
  • テンプレートの API バージョンや kind/reserved の取り違いも併発しやすいので合わせて点検。

よくある誤設定とエラーメッセージの対応表

症状/エラー原因対処
ServerFarmCreationNotAllowedサブスクリプションに ARM 経由の ServerFarm 作成制限Microsoft サポートにアンブロック依頼。East US は解除実績あり。
One or more resource providers failed to registerMicrosoft.Web 未登録az provider register -n Microsoft.Web を実行し、登録完了を待つ。
Function App が起動しない／スケーリングしないkind と reserved の不一致（Linux/Windows）Linux: kind="functionapp,linux" + reserved=true、Windows: kind="functionapp" + reserved=false。
VMSS の割り当て失敗地域の vCPU 上限やファミリ クォータに到達「VMSS クォータ増枠」を申請。サイズ別の上限も併せて増枠。
ストレージ接続でランタイム エラーAzureWebJobsStorage のキー/接続文字列不備Key Vault 参照または listKeys() の有効性を再確認。StorageV2, LRS を推奨。

セキュリティと運用のベストプラクティス

  • マネージド ID を標準化：Function App にシステム割り当て ID を付与し、ストレージ/Key Vault 参照に RBAC を活用。
  • Key Vault 参照：AzureWebJobsStorage を含む機密情報はアプリ設定から直接持たず、Key Vault 参照へ移行。
  • タグ運用：project=autoscale、env=prod など、課金/管理の切り分けを明確化。
  • デプロイ ロック：安定稼働後は不要な削除を防ぐためリソース ロック（CanNotDelete）を検討。
  • パラメータ ファイル：リージョン, Plan 名, Storage 名は環境別に分離し、ヒューマンエラーを防止。
  • 監視：Application Insights (Classic) ではなく workspace-based を推奨。Function の失敗と VMSS のスケール/割当失敗を同一ワークスペースに可視化。

FortiGate Autoscale テンプレートへの組み込みヒント

  • テンプレートの モジュール化：network.bicep、vmss.bicep、functions.bicep と論理分割して、ServerFarm 制限の影響範囲を局所化。
  • App Service Plan の作成可否で失敗する場合でも、他モジュールは what-if と分割デプロイで検証を継続。
  • 関数コードのデプロイは run-from-package を採用し、ARM ではサイトと設定のみを作成。コード更新は CI/CD に切り出す。

トラブル時の切り分け手順（現場で効く順番）

  1. 手動作成の再検証：同じ SKU/リージョン/名前で az functionapp plan create --sku Y1 が通るか。
  2. RP 登録：Microsoft.Web と Microsoft.Storage が Registered か。
  3. テンプレ API の整合：serverfarms と sites でバージョン差がないか。
  4. サポート依頼：ServerFarmCreationNotAllowed と事象差（手動は成功）を添えて解除申請。
  5. 暫定回避：既存 Y1 プランを作成し、テンプレから参照させて先に関数基盤を立てる。
  6. VMSS クォータ：別件で止まらないよう、増枠を並行申請。

サンプル：パラメータ ファイル

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "location": { "value": "eastus" },
    "planName": { "value": "fg-aux-y1-plan" },
    "functionAppName": { "value": "fg-aux-func-app" },
    "storageAccountName": { "value": "fgauxstorxxxxxx" }
  }
}

社内/顧客向けに使える連絡テンプレ（日本語）

件名: ARM 経由で App Service Plan (serverfarms) が作成できない件の解除依頼
現象: FortiGate Autoscale の ARM テンプレートを Pay-As-You-Go にデプロイすると、
      East US リージョンで serverfarms の作成が "ServerFarmCreationNotAllowed" により失敗。
      同条件のポータル/CLI 手動作成は成功。
希望: 該当サブスクリプションの East US における Microsoft.Web/serverfarms の ARM デプロイ制限解除
補足: プラン SKU は Consumption (Y1), tier=Dynamic。解除後の再試行を予定。

まとめ

  • 原因はテンプレートではなく、サブスクリプション単位のバックエンド制限。サポート経由で解除すれば ARM でも作成可能。
  • East US は解除実績があるため、まず同リージョンで再試行するのが近道（2025‑09 時点）。
  • テンプレートでは Y1（Dynamic）、Linux は kind/reserved を一致、StorageV2 LRS を事前用意。
  • VMSS の展開と運用を止めないために、クォータ増枠を並行申請しておく。
  • 解除までの暫定策として、既存 Y1 プラン参照で関数面のブロッカーを回避できる。

付録：Bicep 版（参考）

// main.bicep（Linux Consumption）
param location string = 'eastus'
param planName string
param functionAppName string
param storageAccountName string

resource stg 'Microsoft.Storage/storageAccounts@2023-01-01' = {
name: storageAccountName
location: location
sku: { name: 'Standard_LRS' }
kind: 'StorageV2'
properties: {
allowBlobPublicAccess: false
minimumTlsVersion: 'TLS1_2'
}
}

resource plan 'Microsoft.Web/serverfarms@2022-03-01' = {
name: planName
location: location
kind: 'functionapp,linux'
sku: { name: 'Y1', tier: 'Dynamic' }
properties: {
reserved: true
perSiteScaling: false
}
}

resource app 'Microsoft.Web/sites@2022-03-01' = {
name: functionAppName
location: location
kind: 'functionapp,linux'
dependsOn: [
plan
stg
]
properties: {
serverFarmId: plan.id
httpsOnly: true
clientAffinityEnabled: false
siteConfig: {
linuxFxVersion: 'DOTNET|8.0'
ftpsState: 'FtpsOnly'
appSettings: [
{ name: 'FUNCTIONS_WORKER_RUNTIME', value: 'dotnet-isolated' }
{ name: 'FUNCTIONS_EXTENSION_VERSION', value: '~4' }
{ name: 'AzureWebJobsStorage', value: 'DefaultEndpointsProtocol=https;AccountName=${storageAccountName};AccountKey=${listKeys(stg.id, '2023-01-01').keys[0].value};EndpointSuffix=${environment().suffixes.storage}' }
]
}
}
}

チェックリスト（印刷用）

チェックYes/Noメモ
East US で解除済みか（または解除依頼を提出済みか）
Microsoft.Web が Registered
StorageV2 LRS を同一 RG/リージョンに作成済み
serverfarms は Y1/Dynamic、capacity 未指定
Linux は kind/reserved が一致（functionapp,linux / true）
what-if で差分と依存関係を確認
VMSS の vCPU/ファミリ クォータを増枠済み

これで「手動だと成功するのに ARM では作れない」という一見不可解な状況を、再現性のある手順と堅牢なテンプレ設計で乗り越えられます。FortiGate Autoscale の導入を安全に前進させるため、まずは East US での解除確認と Consumption（Y1）の正しい宣言から着手してください。

Azure
Azure Functions ARMテンプレート App Service Plan クォータ ServerFarmCreationNotAllowed FortiGate Autoscale VMSS

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次