java - 将 AWS Lambda 函数放入 VPC，然后 "IOException: Connection reset by peer"开始发生，但只是偶尔发生

Question

我有一个通过 API Gateway 用作 API 的 Java AWS Lambda 函数。在过去的几个月里，它一直在 24/7 运行，并且之前没有出现过这个特定的错误。
今天，我做了一个更新以添加 Elasticache，这要求我将 Lambda 与 Elasticache 放在同一个 VPC 中。在此之前，Lambda 没有分配给任何 VPC，只是正常运行。
经过大量的配置调整，我似乎终于让它工作了——Lambda JAR 现在能够连接到 Elasticache，同时仍然可以连接到它需要的其他东西。
但是，在部署几分钟后，我开始从 Algorithmia 调用中收到此错误:

java.util.concurrent.ExecutionException: java.io.IOException: Connection reset by peer
at org.apache.http.concurrent.BasicFuture.getResult(BasicFuture.java:71)
at org.apache.http.concurrent.BasicFuture.get(BasicFuture.java:102)
at com.algorithmia.algo.FutureAlgoResponse.get(FutureAlgoResponse.java:41)
at <place that we invoke it>

发生错误的调用代码非常简单:

        FutureAlgoResponse futureAlgoResponse = algo.pipeAsync(<stuff>);
        AlgoResponse result = futureAlgoResponse.get(3L, TimeUnit.SECONDS);

更重要的是，它已经投入生产将近一年，从未出现过这个错误。
所以我想它一定与VPC有关!但是，它在大多数情况下都有效。我们每隔几秒钟运行一次该代码，并且每隔几分钟就会失败一次。当它失败时，它通常会连续 1-3 个请求失败。
我们的 Lambda 设置为 15 秒超时，失败的请求在约 1 秒后响应，重申一下，直到我们今天将 Lambda 移入 VPC 之前，我们从未见过这个错误。
Lambda VPC 配置感觉相当困惑和复杂，所以我确定我在某个地方搞砸了。但事实上它每隔几分钟只会发生几次，这让我很难用我有限的 AWS 知识进行调试。我希望有人可以分享一些可能的原因!
这是我进行设置的方式:

新建 VPC

在 VPC 中创建 2 个子网(和对应的路由表)，一个公有，一个私有(private)

为 VPC 创建一个 Internet 网关，为公共(public)子网创建一个 NAT 网关。

为 NAT 网关分配弹性 IP。

为安全组启用所有传入和传出(可能不需要传入，但我们会返回并修复它)

在该 VPC 中启动 Elasticache

将 Lambda 分配给该 VPC - 特别是私有(private)子网 + 上述安全组

老实说，我对如何进一步调查这一点毫 headless 绪，所以我真的希望有人知道“哦，是的，VPC 中的连接可能会超时，因为_____”。或者，将不胜感激有关如何更好地调试它的任何提示。
编辑:更多搜索表明它可能与 NAT 设置有关？我基本上只是做了一个默认的“创建 NAT 网关”并将其扔到私有(private)子网上。

Answer 1

亚马逊支持提供诊断和解决方案!
tl; dr 是的，超时是问题所在。建议的解决方法是实现 TCP 保持 Activity 以使 350 秒的空闲超时未达到(或者只是有更多的流量，这对我们来说真的不起作用)。
我们最终所做的只是摆脱了 Elasticache。这是我们需要将 Lambda 放入 VPC 的唯一原因，在考虑之后，我们决定需要一段时间才能使我们的流量达到 Elasticache 的好处对我们真正有形的水平(与简单的 EC2 托管相比) Redis 实例)。所以现在我们的缓存只是一个在 EC2 上运行的常规 Redis 实例。
这是完整的回应:
“<首先讨论我的设置的每个步骤以及这些步骤似乎是正确的>...但是，在过去的两天里，我确实看到了一些 NAT 网关空闲超时，您怀疑这可能是问题所在。请参阅到下面的 NAT 网关指标。
话虽如此，IdleTimeoutCount 指标计算从 Activity 状态转换到空闲状态的连接数。如果 Activity 连接没有正常关闭并且在最后 350 秒内没有 Activity ，则 Activity 连接将转换为空闲。大于零的值表示存在已移动到空闲状态的连接。如果 IdleTimeoutCount 的值增加，则可能表明 NAT 网关后面的客户端正在重新使用过时的连接。
如故障排除文档中所述，为防止连接断开，您可以通过连接启动更多流量。或者，如果可能，您也可以在实例上启用 TCP keepalive，其值小于 350 秒。以固定的时间间隔发送 keepalive 探测将确保有一些流量通过 NAT 网关和远程端服务器之间的连接。 keepalive 数据包将重置 350 秒空闲超时计数器，从而使连接在应用程序需要的时间内保持 Activity 状态。
回答你的问题:“这是怎么回事？”
回答:在从 VPC 的角度验证一切都适合 Lambda 函数(SG、NACL、路由表)之后，这里肯定有 NAT 网关空闲超时的可能性。上面提供的 IdleTimeoutCount 指标也证实了这一点，表明连接由于不活动而超时。”