Azure存储账户托管Terraform状态如何减少冗余blob版本生成

Azure Blob开启版本控制后，只要Blob的内容、关联元数据发生一次提交级别的修改，就会自动生成一个不可变的历史版本，而Terraform使用Azure存储账户作为状态后端时，单次apply流程并非只对状态Blob做一次写入，多次写入操作直接对应多个版本生成，具体触发场景包括：

• 锁操作冗余写入：旧版本AzureRM后端实现状态锁时，没有直接使用Blob原生租约接口，而是通过覆写Blob内容写入锁标记、全量更新Blob元数据的方式加锁，这一步会生成第一个版本；解锁时清除锁标记的操作同理，会额外生成一个版本。
• 中间状态增量写入：默认配置下，Terraform在apply执行过程中不会等所有资源变更完成才写状态，每完成一批资源的创建/修改/删除，就会把当前的增量进度写入状态Blob，每一次增量写入都会触发新Blob版本生成，变更的资源越多，这部分生成的冗余版本就越多。
• 校验类写入：部分版本的后端在写入最终状态前，会先写入校验值、做写入权限探测，这类短连接的小写入也会触发版本生成。

• 升级Terraform及AzureRM后端版本：使用1.5及以上版本的Terraform，新版AzureRM后端已经重构了状态交互逻辑，加解锁直接调用Blob原生租约接口，不会产生额外的内容覆写，同时合并了过程中的校验写入，能直接把单次apply生成的版本数压到最低。
• 关闭后端中间快照配置：在AzureRM后端配置块中添加snapshot = false参数，关闭apply过程中的增量中间状态持久化，Terraform只会在所有资源变更完成、校验通过后写入一次最终的完整状态文件，单次apply仅会生成1个对应最终状态的Blob版本。配置示例：

terraform {
  backend "azurerm" {
    resource_group_name  = "tfstate-rg"
    storage_account_name = "tfstate存储账户名"
    container_name       = "tfstate"
    key                  = "prod/terraform.tfstate"
    snapshot             = false
  }
}

• 配置Blob生命周期规则降本：不需要完全追求只保留单版本，直接在存储账户中配置生命周期管理策略：将创建超过3天的非当前版本Blob自动转入冷存储层，创建超过30天（可根据自身回滚需求调整时长）的历史版本自动删除，既保留了出问题时回滚到近期历史状态的能力，又能把存储成本降低90%以上。
• 避免无关操作触发生成：不要把日志、临时执行文件、Plan输出文件和状态文件放在同一个存储容器中，这类文件的频繁写入也会产生大量无意义的版本占用存储成本。

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