我通过S3 Bucket从我的CloudFront提供静态JS文件，我想监视访问它们的人，我不希望它通过CloudWatch完成等等，我想自己记录它。
对于CloudFront的每个请求，我想触发一个lambda函数，将有关请求的数据插入到我的MySQL RDS实例中。
但是，CloudFront限制查看者请求查看器响应触发器太多，例如1秒超时（连接到MySQL太少），没有对lambda的VPC配置（因此我甚至无法访问RDS子网）等。
实现这一目标的最佳方式是什么？设置API Gateway，我将如何向那里发送请求？
这似乎是次优策略，因为CloudFront在触发器代码运行时暂停请求/响应处理 - Lambda @ Edge触发器中的Lambda代码必须在处理请求或响应继续之前完成执行，因此短暂超时。
CloudFront提供每小时多次删除的日志（取决于流量负载）到您选择的存储桶中，您可以从S3事件通知中捕获，解析并插入到数据库中。
然而...
如果你真的需要实时捕获，最好的办法是在你的VPC中创建第二个Lambda函数，它接受提供给Lambda @ Edge触发器的数据结构。
然后，在查看器请求或查看器响应触发器的代码内部，您需要做的就是使用内置的AWS SDK异步调用第二个Lambda函数，并将事件传递给它。
这样，日志记录任务就会被切换，您不会等待响应，CloudFront处理可以继续。
我建议如果你真的想采取这条路线，这将是最好的选择。即使第二个函数不在同一个帐户，区域或VPC中，一个Lambda函数也可以轻松调用第二个函数，因为调用是通过与Lambda服务的端点API进行通信来完成的。
但是，仍然有一些优化空间，因为你必须考虑Lambda @ Edge的另一个方面，它与此间接相关：
没有对lambda的VPC配置
这有一个重要原因。您的Lambda @ Edge触发器代码在最靠近处理每个特定查看器的流量的边缘位置的区域中运行。您的Lambda @ Edge功能在us-east-1中配置，但随后会复制到所有区域，如果CloudFront需要它，则可以运行。
因此，当您调用上面提到的第二个Lambda函数时，您实际上将在第二个函数的区域中接触Lambda API - 从处理此特定请求的Lambda @ Edge触发器的任何区域开始。
这意味着延迟将越多，两个区域越远。
这个真正的最佳解决方案（出于性能目的）稍微复杂一点：通过向Lambda API发出请求而不是异步调用第二个Lambda函数的L @ E函数...您可以在每个区域中创建一个SNS主题，并为每个人订阅第二个Lambda函数。 （SNS可以跨区域边界调用Lambda函数。）然后，您的Lambda @Edge触发器代码只是在其自己的区域中向SNS主题发布消息，该消息将立即返回响应并异步调用远程Lambda函数（第2个函数，这是在您的VPC中的一个特定区域）。在Lambda @ Edge代码中，环境变量process.env.AWS_REGION为您提供当前正在运行的区域，因此您可以使用它来确定如何以最小的延迟将消息发送到正确的SNS主题。 （测试时，这总是us-east-1）。
是的，这有点令人费解，但它似乎是在不对请求处理施加大量延迟的情况下完成您要做的事情的方法 - Lambda @ Edge尽快将信息交给另一个承担实际责任的服务在数据库中生成日志消息。
处理从CloudFront访问的静态内容（或任何内容）的典型方法是启用日志记录，然后处理日志文件。
要启用CloudFront Edge事件（包括处理和更改事件），请查看Lambda @ Edge。
我会先启用日志记录并监控流量一段时间。当坏演员进入您的网站（CloudFront Distribution）时，他们将产生大量流量。这可能导致使用Lambda Edge的一些相当大的账单。我还建议查看Amazon WAF以帮助缓解可能有助于Lambda处理量的拒绝服务攻击。
Lambda和关系数据库对并发，连接和连接池提出了严峻挑战。有关更多信息，请参阅此Lambda databases guide。
我建议使用Lambda @ Edge与为更高并发性构建的服务进行通信，作为记录访问的第一步。例如，您可以让Lambda @ Edge函数将访问记录写入SQS，然后让后台工作程序从SQS读取到RDS。
这是一个example of Lambda@Edge interacting with STS to read some config。写入SQS很容易被重构。