CloudFront搭配S3后端：S3硬编码HTML头与Lambda@Edge改响应头的区别

以下是直接在S3对象元数据硬编码响应头、用Lambda@Edge修改源站响应头两种方案的核心差异：

• 维护成本差异
  硬编码S3元数据的方案依赖逐个对象修改配置，你用到的aws s3 cp --content-type 'text/html' --cache-control 'no-cache' s3://my_bucket/index.html s3://my_bucket/index.html --metadata-directive REPLACE就是典型实现方式。如果存储桶内对象数量多、或者后续要统一调整响应头规则（比如更新安全头规则、修改Cache-Control值），需要全量执行覆写操作，不仅耗时长还容易出现遗漏，新增对象时也需要在上传环节提前配置好元数据，否则会出现响应头不一致的问题。
  Lambda@Edge方案只需要编写一次函数逻辑，所有回源请求的响应都会统一按规则修改头，存量、新增对象都能自动生效，调整规则仅需修改函数代码，无需操作S3内的对象，维护成本低很多。
• 额外成本差异
  硬编码方案除了修改对象时产生的少量S3请求费用外，没有后续的额外运行成本，也不会给请求链路增加任何耗时。
  Lambda@Edge方案会在每次缓存未命中、CloudFront回源拿到S3响应时触发函数执行，会产生对应的Lambda调用费用，虽边缘执行的耗时极低几乎可忽略，但流量规模大的时候会产生持续的额外开销。
• 灵活性差异
  硬编码方案仅能给每个对象配置固定的响应头，无法根据请求特征动态调整，比如给不同路径、不同客户端返回不同的响应头，也无法实现删除冗余响应头这类操作，适配场景非常有限。
  Lambda@Edge方案支持自定义逻辑，可以灵活根据请求、响应的各类属性动态调整响应头的增删改，适配复杂的业务规则、安全规则需求。
• 缓存生效差异
  硬编码方案修改元数据后，CloudFront已经缓存的旧内容不会自动更新响应头，需要主动提交缓存失效请求才能让用户拿到更新后的响应，对象数量多的时候失效操作也会产生额外费用。
  Lambda@Edge在源响应阶段修改的头会和内容一起被CloudFront缓存，规则调整后新的回源请求会自动应用新的响应头规则，无需额外做缓存失效即可逐步对用户生效。
• 适用场景
  硬编码方案更适合对象数量少、响应头规则长期固定不会调整的场景，比如只有几个静态页面的小型站点。
  Lambda@Edge更适合对象规模大、响应头规则需要频繁迭代、或者有动态配置响应头需求的场景，比如中大型站点统一配置全站安全头的场景。

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