使用AWS CloudFront记录自定义请求头的最优方案咨询

嘿，我来给你梳理几个实际可用的方案，帮你解决CloudFront记录自定义请求头的问题～

首先你说的没错，CloudFront的标准访问日志确实只能记录预定义的字段，自定义请求头比如X-Foo确实不会出现在里面。针对这个需求，我推荐按优先级试试下面这些方案：

• 优先考虑实时日志（Real-time Logs）
  其实这是AWS官方推荐的自定义日志方案，配置起来也没你想的复杂。你可以在CloudFront控制台里开启实时日志，然后在字段配置里直接指定要记录的自定义请求头，比如填requestHeaders.X-Foo就行。日志会实时推送到Kinesis Data Streams或者Kinesis Data Firehose，之后你可以把数据存到S3、Elasticsearch或者直接用CloudWatch Analytics分析。这个方案不需要写任何代码，配置完成就能自动采集自定义头，效率和可靠性都很高，适合大多数生产场景。

• CloudFront Functions/Lambda@Edge（适合需要额外处理的场景）
  如果你不仅要记录，还需要对自定义头做一些轻量处理（比如格式转换、过滤），可以用CloudFront Functions。在viewer request阶段读取X-Foo的值，然后你可以把它注入到一个标准日志会记录的字段里（比如临时添加一个查询参数?custom-x-foo=bar，不过这种会修改请求，要谨慎使用）。
  要是需要更复杂的逻辑（比如把日志直接发送到CloudWatch或者第三方日志服务），那Lambda@Edge更合适。在viewer request事件里读取自定义头，然后调用console.log()把内容输出到CloudWatch Logs，或者调用你的日志API。不过要注意Lambda@Edge有冷启动的情况，小流量场景影响不大，大流量的话可能会增加一点延迟。

• 临时测试方案：返回自定义头到客户端
  如果只是测试阶段需要验证自定义头是否被CloudFront接收，你可以在CloudFront配置里添加一个响应头，把X-Foo的值原封不动返回给客户端。这样你用浏览器开发者工具或者curl就能看到，但这个方案只适合测试，绝对不能用于生产环境，因为会把敏感信息暴露给用户。

总结一下：如果只是单纯记录自定义头，实时日志是最省心高效的选择；如果需要额外处理逻辑，再考虑CloudFront Functions或者Lambda@Edge。

备注：内容来源于stack exchange，提问作者Greendrake