@Matt 答案是正确的,但不完整。
正如@Rodrigo 的回答所说,添加安全层是实现安全性的必要步骤,但不能保护您免受经过身份验证的呼叫者的侵害。
由于这篇文章,我实际上刚刚在我的一个 lambda 上遇到并解决了这个问题:https ://itnext.io/the-everything-guide-to-lambda-throttling-reserved-concurrency-and-execution-limits -d64f144129e5
基本上,我在我的文件中添加了一行serverless.yml
,在我的函数中,由所述授权的第 3 方调用:
reservedConcurrency: 1
这是整个功能:
refresh-cache:
handler: src/functions/refresh-cache.refreshCache
# XXX Ensures the lambda always has one slot available, and never use more than one lambda instance at once.
# Avoids GraphCMS webhooks to abuse our lambda (GCMS will trigger the webhook once per create/update/delete operation)
# This makes sure only one instance of that lambda can run at once, to avoid refreshing the cache with parallel runs
# Avoid spawning tons of API calls (most of them would timeout anyway, around 80%)
# See https://itnext.io/the-everything-guide-to-lambda-throttling-reserved-concurrency-and-execution-limits-d64f144129e5
reservedConcurrency: 1
events:
- http:
method: POST
path: /refresh-cache
cors: true
当refresh-cache
任何数据发生变化时,第三方服务触发的 webhook 会调用 lambda。例如,在导入数据集时,它会触发多达 100 次对refresh-cache
. 这种行为完全是在向我的 API 发送垃圾邮件,而 API 又运行对其他服务的请求以执行缓存失效。
添加这一行大大改善了这种情况,因为一次只有一个 lambda 实例在运行(没有并发运行),调用次数除以 ~10,而不是 50 次调用refresh-cache
,它只触发了 3-4,并且所有这些调用都有效(由于超时问题,200 而不是 500)。
总的来说,还不错。对我的工作流程来说还不完美,但向前迈出了一步。
不相关,但我使用了https://epsagon.com/,它极大地帮助我弄清楚 AWS Lambda 上发生了什么。这是我得到的:
在对 lambda应用reservedConcurrency
限制之前:

您可以看到大多数调用因超时(30000 毫秒)而失败,只有少数第一次成功,因为 lambda 尚未超载。
对 lambda应用reservedConcurrency
限制
后:
您可以看到所有调用都成功了,而且它们的速度要快得多。没有超时。既省钱又省时间。
正如@Rodrigo 在他的回答中所说,使用reservedConcurrency
并不是解决这个问题的唯一方法,还有很多其他方法。但它是一个可行的,可能适合您的工作流程。它应用于 Lambda 级别,而不是 API Gateway(如果我正确理解文档)。