亚马逊AWS官方博客
·
基于 Amazon CloudFront 和 Lambda@Edge 实现失败请求的完整记录与异步重放
内容提要
本文介绍了一种基于Amazon CloudFront和Lambda@Edge的架构方案，用于记录被WAF拦截及源站返回错误的请求。该方案无需修改源站代码，能够记录失败请求的headers和body，并通过CloudWatch Logs和Kinesis Data Firehose汇聚至S3，支持异步重放。其核心价值在于信息完整性、零侵入性和成本可控，适用于无法修改代码的非AWS环境。
关键要点
-
本文介绍了一种基于 Amazon CloudFront 和 Lambda@Edge 的架构方案，用于记录被 WAF 拦截及源站返回错误的请求。
-
该方案无需修改源站代码，能够记录失败请求的 headers 和 body。
-
通过 CloudWatch Logs 和 Kinesis Data Firehose 汇聚至 S3，支持异步重放。
-
方案的核心价值在于信息完整性、零侵入性和成本可控，适用于无法修改代码的非 AWS 环境。
-
失败请求包括被 AWS WAF 拦截的请求和源站响应 4xx/5xx 的请求。
-
方案采用双 Lambda@Edge 函数架构，分别在 origin-request 和 origin-response 阶段进行处理。
-
每个请求触发两个 Lambda@Edge 函数，月均约 6,000 万次执行，估算月度成本约为 $60.60。
-
该方案的实施步骤包括创建 Lambda@Edge 函数、配置 Amazon CloudFront Distribution 和日志汇聚管道。
-
方案支持记录完整的请求信息，便于后续的数据补偿和请求重放。
延伸解读
方案适用场景
该方案特别适合那些源站部署在非AWS环境且无法修改代码的企业。通过使用Amazon CloudFront和Lambda@Edge，企业可以在不干扰现有系统的情况下，完整记录失败请求的信息。这种零侵入性的特性使得企业能够在保持系统稳定性的同时，提升故障排查和数据恢复的能力。
成本控制与效益
方案的成本控制是其一大亮点。通过仅记录失败请求，成功请求不产生额外开销，企业可以有效管理日志存储和处理成本。在日均百万请求的情况下，月度成本约为60美元，这对于大多数企业来说是可接受的，尤其是在需要高可用性和数据完整性的场景中。
技术细节与限制
在实施过程中，需注意Lambda@Edge的请求体大小限制和日志分散问题。请求体通过自定义header传递时，受20KB的总请求大小限制，且日志可能分散在多个区域的CloudWatch中，需逐一配置汇聚。这些技术细节可能影响方案的实施效率和后续的日志管理。
延伸问答
如何在不修改源站代码的情况下记录失败请求？
可以通过基于 Amazon CloudFront 和 Lambda@Edge 的架构方案，记录被 WAF 拦截及源站返回错误的请求，完全在 CloudFront 层实现。
该方案的核心价值是什么？
方案的核心价值在于信息完整性、零侵入性和成本可控，适用于无法修改代码的非 AWS 环境。
如何实现日志的统一存储？
通过配置 Amazon Kinesis Data Firehose，将从 Amazon CloudWatch Logs 收集的日志统一投递到 Amazon S3 存储桶。
该方案的实施步骤有哪些？
实施步骤包括创建 Lambda@Edge 函数、配置 Amazon CloudFront Distribution 和日志汇聚管道。
该方案的月度成本大约是多少？
在日均百万请求的场景下，方案的月度成本约为 $60.60。
如何处理被 AWS WAF 拦截的请求？
被 AWS WAF 拦截的请求会通过 AWS WAF 的独立日志记录机制写入 Amazon CloudWatch Logs，包含 headers 和 body 前 8KB。
