我如何导致了Amazon API Gateway的拒绝服务

在一次项目中，我参与了基于无服务器架构开发工作。我们使用了AWS Lambda来运行函数代码，DynamoDB作为数据库表的存储服务，并通过应用程序编程接口（API）。API Gateway的主要作用是提供一个端点URI，将HTTP请求的有效负载转发至Lambda函数。Lambda函数随后查询DynamoDB表获取数据，并将结果返回给API Gateway，最终由API Gateway将数据发送至客户端。

优化过程中的初衷与问题

在开发过程中，我们发现大多数情况下，API返回的数据内容是相同的。这意味着每次调用API时，Lambda函数都会重复查询DynamoDB表以获取相同的数据。为了减少对Lambda函数和DynamoDB表的压力，我们决定启用API Gateway的缓存功能。

启用缓存后，API Gateway可以直接返回缓存数据，而无需将请求转发给Lambda函数。这一优化在初期看起来效果不错。然而，我们很快发现了一个问题：即使DynamoDB表中的数据已经更新，API Gateway仍然会提供过期的缓存数据，直到缓存到期为止。这显然无法满足我们提供最新数据的需求。

尝试解决方案与意外后果

为了应对这一问题，我们设计了一个解决方案：通过订阅DynamoDB表流的Lambda函数来清除缓存。当DynamoDB表发生写入、删除或更新操作时，DynamoDB Streams会生成事件。我们让第二个Lambda函数订阅这些事件，并在接收到事件时调用AWS SDK的API来清除API Gateway的缓存。

起初，这个解决方案看起来是合理的。然而，问题很快显现：DynamoDB Streams开始批量发送旧的事件，导致第二个Lambda函数接收到大量过时的流事件。每个事件都会触发一次清除缓存的请求，最终导致API Gateway的速率限制。

由于API端点的性能受到严重影响，甚至停止响应HTTP请求。这种情况类似于内部拒绝服务（DoS）攻击，导致了系统的不可用。

反思与改进建议

这一事件表明，即使是看似合理的设计，也可能在实际运行中产生意想不到的负面影响。在使用事件驱动架构和无服务器架构时，必须充分考虑非理想情况下可能发生的情况。

改进措施

输入验证

Lambda函数应对接收到的事件进行严格的输入验证。例如，仅处理“X”分钟前的事件，且事件必须来自正确的表并具有特定的操作类型（如更新）。
架构审查

在架构设计阶段，应明确DynamoDB表的更新时间和API Gateway缓存的清除策略。例如，如果表仅在CI/CD部署管道中更新，可以让CI/CD管道直接调用AWS SDK API清除缓存，而不是依赖事件驱动的Lambda函数。
负面路径场景分析

在设计过程中，应进行全面的负面路径场景分析，评估系统在非理想或恶意输入情况下的表现。这可以通过代码审查和团队头脑风暴来实现。

总结

这个案例说明了一个善意的设计如何在实际运行中导致不希望的结果。在本例中，DynamoDB Streams发送的过时事件触发了大量AWS SDK API调用，最终导致API Gateway的拒绝服务问题。通过加强架构分析、代码审查和负面路径场景分析，可以有效避免类似问题的发生。

原文链接: https://medium.com/serverlessciso/how-i-caused-an-amazon-api-gateway-denial-of-service-cba93810e18f

我如何导致了Amazon API Gateway的拒绝服务 - Medium

文章目录