Pulumi Azure存储账户迁移至Azure-Nextgen时Aliases失效问题问询

核心结论 #

本次迁移完全具备可行性，当前Alias未生效、触发受保护资源删除拦截的问题，均属于跨提供程序迁移的常见配置偏差，不存在流程上的不可行障碍。

报错本质 #

你当前遇到的refusing to delete protected resource报错，核心原因是新配置的Alias完全没有命中状态库中的旧资源身份，触发了Pulumi的默认资源清理逻辑：

1. Pulumi扫描栈内存量资源，发现旧版提供程序创建的azure:storage/account:Account资源，没有任何新代码定义的资源通过Alias指向它
2. 将无引用的旧资源标记为待删除
3. 因旧资源开启了Protect = true配置，删除操作被直接拦截抛出报错

常见配置偏差点 #

• 硬编码拼接的Alias URN存在字符、大小写、项目名/栈名不匹配问题：你目前手写的完整Urn字符串，只要和状态文件中存储的旧资源Urn存在1个字符的差异（比如项目名写错、栈名拼写偏差），就会完全失效
• 对Alias的映射逻辑理解偏差：Alias的作用是将新资源的身份绑定到旧资源上，不是单纯给新资源加一个“旧标签”，必须保证新旧资源的逻辑名、类型映射完全对齐
• 迁移流程顺序错误：没有先验证Alias的匹配效果，直接开启受保护配置后执行预览，导致资源清理逻辑提前触发拦截

正确配置步骤 #

1. 替换容易出错的硬编码Urn写法，使用Pulumi原生的Alias构造方式
   不要手动拼接完整Urn，直接通过资源类型+逻辑名的方式定义Alias，Pulumi会自动补全当前栈名、项目名的部分，从根源避免拼写错误：

   new CustomResourceOptions()
   {
       Protect = true,
       Aliases =
       {
           // 无需硬拼Urn，直接映射旧版Azure提供程序的资源类型与逻辑名
           new Alias 
           { 
               Type = "azure:storage/account:Account", 
               Name = $"storage_{storageName}" 
           }
       }
   }
   

2. 校验存量状态中的旧资源真实Urn
   若仍需要使用硬编码Urn的方式，先导出当前栈的完整状态，逐字复制旧存储账户对应的Urn字段，不要自行拼接：
   • 执行pulumi stack export --file stack-state.json
   • 打开导出文件，搜索对应存储账户的条目，一字不差复制urn字段值到Alias配置中
3. 验证预览结果是否符合预期
   重新执行pulumi preview，必须确认输出不存在以下两类提示：
   • 不存在+ azure-native:storage:StorageAccount（新建资源）的计划
   • 不存在- azure:storage/account:Account（删除旧资源）的计划
     只有当预览输出为~ azure-native:storage:StorageAccount（基于存量资源更新配置）时，才说明Alias映射生效。
4. 对齐资源参数避免不必要的重建
   当Alias映射生效后，检查新旧代码的核心参数是否一致，避免触发资源重建：
   • 存储账户名必须和旧资源完全一致（新旧代码中的Name/AccountName值无偏差）
   • 资源组名称、位置必须和旧资源匹配
   • 旧代码中的LRS、Standard层级、HNS开启、TLS1.2配置，要完整映射到新版StorageAccount的Sku、Kind、IsHnsEnabled、MinimumTlsVersion参数中

迁移收尾 #

当验证预览结果正确后，执行pulumi up完成迁移。迁移完成后，可删除Alias配置（后续部署不需要再保留旧资源的身份映射），新资源会自动承接旧资源的状态、受保护配置等所有属性。

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