‘底层App Service部署不支持PremiumV2’含义及升级异常问询

碰到这种情况确实挺头疼的——明明配置一模一样，结果一个能升级一个不行。结合Azure的底层机制和Terraform的部署逻辑，我帮你梳理几个最可能的原因，以及对应的排查和解决方法：

1. 区域/硬件集群限制 #

PremiumV2计划并不是在所有Azure区域或者硬件集群都支持的。有时候即使两个App Service显示在同一个区域，实际可能被分配到了不同的底层集群（比如部分老集群没有适配PremiumV2的硬件）。

你可以在Azure门户里检查两个App Service的部署位置详情：进入App Service -> 概述页面，点击位置旁边的"查看详情"，对比两者的集群信息。如果其中一个在不支持PremiumV2的集群上，自然无法升级。

2. 基础部署单元的类型差异 #

微软提示里的"underlying App Service deployment"，指的是App Service所在的底层部署单元类型。有些早期的部署模式（比如遗留的消费计划部署、非弹性部署单元）不支持升级到PremiumV2。

比如，如果你其中一个App Service是从旧的免费/基本计划一步步升级上来的，而另一个是直接通过Terraform创建在新的弹性部署单元上，就会出现这种差异。你可以用Azure CLI命令查看细节：

az webapp show --name <你的App名称> --resource-group <资源组名称> --query "siteProperties"

重点关注hostingEnvironmentProfile和reserved字段，对比两个App的输出是否有差异。

3. Terraform隐式参数或依赖的差异 #

虽然你说流程和参数完全一致，但Terraform有时候会因为部署顺序、隐式默认值或者依赖关系，导致实际创建的资源出现细微差别：

• 检查两个App Service是否依赖了不同的旧资源（比如旧的虚拟网络集成、存储账户），这些依赖可能会强制Azure将App部署到不支持PremiumV2的集群；
• 对比Terraform状态文件里的资源属性：运行terraform state show azurerm_app_service.<你的App名称>，查看两个App的site_config、hosting_environment等字段是否完全一致；
• 确认azurerm_app_service_plan的SKU配置，有没有不小心在某个计划里写错了tier（比如写成Premium而非PremiumV2）。

4. 订阅配额或资源锁定限制 #

少数情况下，订阅的区域配额不足或者资源被锁定，也会导致无法升级：

• 检查订阅的PremiumV2配额：进入Azure门户 -> 订阅 -> 使用情况 + 配额，搜索"App Service PremiumV2"，确认目标区域有足够的配额；
• 检查App Service或其所在资源组是否设置了资源锁定，锁定会阻止资源的SKU升级操作。

可行的解决方法 #

如果排查后确认是底层部署单元的问题，最直接的方式是将无法升级的App Service重新部署到支持PremiumV2的集群：

1. 先备份App的代码、配置和数据库（如果有）；
2. 通过Terraform销毁该App Service，然后重新创建；
3. 或者使用Azure门户的"克隆App Service"功能，将它克隆到同一个区域的新部署单元，再尝试升级计划。

你也可以尝试用Azure CLI强制触发升级，看是否能得到更详细的错误提示：

az webapp update --name <你的App名称> --resource-group <资源组名称> --set serverFarmId=/subscriptions/<你的订阅ID>/resourceGroups/<资源组名称>/providers/Microsoft.Web/serverfarms/<你的PremiumV2计划名称>

内容的提问来源于stack exchange，提问作者Kam