如何在AWS CloudFront搭配API Gateway源时无缓存返回压缩内容？

• CloudFront原生边缘压缩仅对可缓存且TTL≥1的响应生效，TTL=0的响应完全绕过缓存模块，不会触发压缩逻辑，这是AWS平台的内置规则，没有配置绕过的空间。
• Accept-Encoding属于CloudFront预留的逐跳头，在源站请求链路中为只读属性，不允许通过源站请求策略透传、自定义源站头覆盖、Lambda@Edge/CloudFront Functions修改，因此无法直接把客户端的压缩请求透传给后端Regional API Gateway触发它的原生压缩。
• 若配置源站请求策略透传所有查看器头，CloudFront会直接转发客户端携带的Host头，而同一个自定义域名无法同时绑定到CloudFront和Regional API Gateway，导致API Gateway无法识别该Host头返回403错误，该路径天然不可行。

• 方案1：替换为边缘优化型API Gateway（最简便）
  直接将现有Regional API Gateway切换为边缘优化型，其底层默认集成CloudFront能力，无需额外部署独立的CloudFront分发。只需在API Gateway控制台开启压缩功能、设置合适的最小压缩阈值，不需要缓存的端点直接关闭API Gateway侧缓存即可，压缩逻辑会自动生效，无需处理头透传问题。
• 方案2：Lambda@Edge源站响应阶段做压缩（保留现有架构）
  不需要修改源站请求的Accept-Encoding头，直接在Lambda@Edge的源站响应触发阶段，读取客户端请求携带的Accept-Encoding头支持的压缩格式（gzip/brotli），对API Gateway返回的未压缩响应体做实时压缩，再修改响应的Content-Encoding、Content-Length头后返回给客户端即可。该阶段没有响应体和响应头的只读限制，仅会产生额外的Lambda调用成本，适合中小流量场景。
• 方案3：新增中间反向代理层（适合大流量场景）
  在CloudFront和Regional API Gateway之间新增一层反向代理（如Nginx、ALB+ECS），将反向代理设置为CloudFront的源站。由反向代理主动给转发到API Gateway的请求加上Accept-Encoding头，接收API Gateway返回的压缩响应后直接透传给CloudFront，无需做额外处理。该方案不会产生高昂的Lambda调用成本，但需要额外维护中间代理层的资源。

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