Terraform aws_s3_object的etag异常：每次apply重复上传未变更文件

为什么状态文件只存MD5格式的ETag？ #

这是由两个核心机制决定的：

1. S3的ETag规则：对于非分片上传的文件，AWS S3生成的ETag就是文件内容的MD5哈希值——这是S3的默认行为，你无法通过自定义配置让S3返回带桶名的ETag。
2. Terraform的状态同步逻辑：Terraform会定期从S3服务拉取对象的实际属性（包括ETag）同步到本地状态文件中，所以状态里存储的是S3真实返回的纯MD5值，而非你在配置里定义的拼接值。

为什么每次apply都会重复上传？ #

你在配置里把ETag设置为${local.bucket_name}${filemd5(local.file)}，但S3实际返回的ETag还是纯MD5。每次terraform apply时，Terraform会对比配置的预期值和状态里的实际值，发现ETag不匹配，就会触发对象更新操作（重新上传文件）。

桶重命名后文件未上传的正确解决方式 #

你最初遇到的问题，根本原因不是ETag未变更，而是要确保aws_s3_object能感知桶的变化并触发重建。正确的配置方式是让对象资源直接关联桶资源的属性：

resource "aws_s3_bucket" "my_bucket" {
  bucket = local.bucket_name
}

resource "aws_s3_object" "my_object" {
  bucket = aws_s3_bucket.my_bucket.name # 直接引用桶资源的名称属性
  key    = "my-file.txt"
  source = local.file
  etag   = filemd5(local.file) # 保持原有的纯MD5配置即可
}

当你修改local.bucket_name后，aws_s3_bucket会被销毁并重建，aws_s3_object的bucket属性会自动指向新桶。Terraform会识别这是一个新的资源实例，自动销毁旧桶中的对象，并在新桶中创建新对象，完全不需要修改ETag。

如果桶名是通过变量定义的，只要aws_s3_object的bucket参数引用变量值，修改变量后同样会触发对象资源的重建。

总结 #

拼接桶名到ETag的做法是舍本逐末，虽然临时解决了第一次上传的问题，但会导致后续每次apply都执行无意义的重复上传操作，浪费API调用和带宽。正确的做法是通过资源引用让Terraform自动感知桶的变化，触发对象的重建。

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