你应该通过SNS链接你的Lambda函数。这种方法以最小的工作量提供了良好的性能、延迟和可伸缩性。

你的第一个Lambda发布消息到你的SNS主题，第二个Lambda订阅了这个主题。一旦消息到达主题，第二个Lambda将以消息作为输入参数执行。

参见使用Amazon SNS通知调用Lambda函数。

您还可以使用这种方法通过SNS调用跨帐户Lambda函数。

我一直在考虑删除SNS，直到我在Lambda客户端文档(Java版本)中看到了这个:

访问AWS Lambda的客户端。使用此客户端进行的所有服务调用都是阻塞的，直到服务调用完成才返回。

所以SNS有一个明显的优势:它是异步的。你的lambda不会等待后续的lambda完成。

我也有同样的问题，但我实现的Lambda函数将在DynamoDB中插入一个条目，所以我的解决方案使用DynamoDB触发器。

我让DB对表中的每一次插入/更新都调用一个Lambda函数，这样就分离了两个Lambda函数的实现。

文档在这里: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.Lambda.html

下面是一个有指导的攻略: https://aws.amazon.com/blogs/aws/dynamodb-update-triggers-streams-lambda-cross-region-replication-app/

我正在使用blueskin提供的答案，但我无法读取有效负载响应，因为InvocationType='Event'是异步的，所以我更改为InvocationType='RequestResponse'，现在一切正常。

其他人指出使用SQS和步骤函数。但这两种解决方案都增加了额外的成本。阶跃函数的状态转换应该是非常昂贵的。

AWS lambda提供了一些重试逻辑。它尝试某件事3次。我不确定当你使用API触发它时，它是否仍然有效。

有很多答案，但没有一个是强调调用另一个lambda函数不是同步调用的推荐解决方案，你应该使用的是真正的步骤函数

不建议解决的原因:

当两个函数相互等待时，你为它们支付了费用 你的代码负责重试

您还可以将它用于相当复杂的逻辑，例如并行步骤和捕获失败。每次执行都被注销，这使得调试更加简单。