AWS Elasticache与API Gateway缓存比较

Question

我刚开始接触使用AWS Lambda的无服务器体系结构，仍在努力弄清一些组件如何相互配合。我已将我的网站从EC2（React客户端和Node API）转换为无服务器体系结构。现在React客户端使用s3静态Web托管，API已转换为使用AWS Lambda和API Gateway。

在之前的实现中，我使用redis作为缓存来缓存其他第三方API的响应。

API Gateway有启用缓存的选项，但我也研究了Elasticache作为一个选择。它们的价格都差不多，只是API Gateway缓存略微昂贵一些。

当我尝试使用Elasticache时遇到的问题是它需要在VPC中运行，而我不能再调用我的第三方API。

我想知道使用其中一个是否有任何好处？目前我的缓存的主要目的是减少对API的请求，但随着时间的推移可能会改变。是否有意义专门有一个Lambda检查Elasticache是否有存储的值，如果没有则触发另一个Lambda从API中检索信息，或者这是否可能。或者针对我的用例，API Gateway缓存是否更好？

或者完全不同的解决方案。这有点可惜，因为几乎所有其他东西都符合免费层级，但有某种缓存将增加大约15美元/月的费用。

我仍然非常新于这种设置，因此任何帮助或指导都将不胜感激。谢谢！

- Trevor Glass

Answer 1

请问使用两者之一有什么好处吗？

API网关内部使用Elasticache来支持缓存，所以它们在功能上的表现是相同的。使用API网关缓存的好处是，ApiGateway在调用后端Lambda之前会检查缓存，因此可以节省已由缓存服务的响应的Lambda调用成本。

另一个区别是，当您使用API网关缓存时，缓存查找时间不会计入缓存未命中情况下“29秒集成超时”限制。

现在我的缓存的主要目的是减少对API的请求，但这可能会随着时间的推移而改变。

我建议根据当前的用例来做出有关缓存的决策。您可能需要为其他缓存需求使用全新的缓存或不同的解决方案。

将Lambda专用于首先检查Elasticache是否存储某个值，如果没有触发另一个Lambda从API中检索信息，这样做有意义吗？或者对于我的用例，API Gateway缓存是更好的选择？

总的来说，我不建议再增加一个Lambda仅用于检查缓存值（以避免延迟和更新Lambda的冷启动问题）。无论哪种方式，如上所述，您最终将为即使是由缓存服务的请求而发生的Lambda调用付费。如果使用API网关缓存，则已缓存的请求甚至不会到达Lambda。

- Vishal

---

"Apigateway内部使用Elasticache来支持缓存，因此它们在功能上的行为方式是相同的。您能否指出一个AWS参考文献，其中说明了这一点？尽管这很可能是情况，但我还没有找到任何API网关文档提到这一点。谢谢" - numX

我支持这个答案。最好使用API网关进行缓存以节省成本，而不是使用Elasticache。后者会增加复杂性并需要额外的资源配置。但要注意API网关缓存的限制。 - Waleed93

@numX 是的，这不是公开文档中的信息，但作为 API 网关团队的开发人员，我可以确认这一点。 - Vishal