我对服务器世界还比较陌生，所以如果其中有些内容比较基础，请原谅我（第一句话我会解释我的逻辑，以确保没有缺陷）。我所有的问题都会加粗，以便于您更轻松地获得帮助 :)。
我一直在研究和自学一些 AWS 技术，我注意到在他们的 Mobile Hub 中，如果您想要云逻辑，他们只允许“自动”设置 Lambda 函数。在阅读和研究之后，我发现了一些指向“无服务器”架构（Lambda 的引入支持该架构）的资源。在过去，我的理解是 Elastic Beanstalk 的引入有助于显著简化服务器管理（尤其是移动服务器管理）。
对于移动开发，有 2 个选项（显然还有更多，但为了简单起见，我们同意）：
- 设置一个 Elastic Beanstalk，其中至少有 1 个实例全天候运行，并且每个 URL 有多个端点
- 使用 API 网关，我们可以轻松地将 URL 路由到特定的 Lambda 函数。这样，我们就可以处理任何请求（就像设置 Elastic Beanstalk 应用程序一样）。
所有这些都让我相信，一个完整的 Lambda 后端是完全有可能的，而且很容易创建，成本只是全天候运行的服务器的一小部分。对吗？
现在，假设上述内容是正确的，我们需要确定使用 Lambda 是否真的比 Elastic Beanstalk 有益。
对于简单的服务器，我们可以设置一些 Lambda 函数并完成一天的工作（它可能比使用 Elastic Beanstalk 更简单、更便宜（至少对于小型项目而言）。
然而，对于具有更多 URL 和数据库连接的更复杂的服务器，事情会变得更加有趣。
以下是我在上述情况下使用 Lambda 时遇到的问题
- 每个 URL 都有自己的 API 网关和 Lambda 函数。如果任何代码或模块在多个函数中使用，我们必须将其复制并粘贴到每个函数中。
- 管理多个 Lambda 函数（和 API 网关）比管理单个项目/repo/任何您想调用的代码库的工作量都要大得多。
- 每个需要 DB 连接的函数都必须在函数内进行连接（相对于在 Node.js 应用程序内进行持续连接而言）。
我能想到的避免前两个问题的唯一方法是创建一个充当调度的强健函数（主函数从 API 网关获取参数并确定在 Lambda 函数中运行哪个文件）。
我是否遗漏了哪些要点来确定使用 Lambda 而不是 Elastic Beanstalk 是否值得？
答案1
为了让大家了解情况，我没有得到回复，所以我在 StackOverflow 上提问，并得到了以下回应从姆贝尔德。评论中有一些讨论，所以请随意查看并给予他赞扬。
听起来你已经明白了。你说得对，使用 Lambda 而不是让服务器 24/7 全天候运行可以节省大量成本。这篇文章声称：
而且它还为亚马逊的一些客户节省了大笔费用，至少有一位满意的 Lambda 客户节省了 80% 的云费用。您可能想看看 Serverless Framework，它可以解决一些痛点。
我认为，随着亚马逊为 Lambda 添加更多功能并为其构建更多第三方工具，许多痛点将随着时间的推移而消失。我不断发现 Lambda 的新用途，但我也不断发现一些用途，这些用途最初似乎很合适，但实际上在 Lambda 上不起作用，至少现在还不起作用。例如，我确实需要某种方法来限制可以同时运行的 Lambda 函数实例数，以防止数据库连接达到最大可用量或第三方 API 的使用限制。我还确实需要在我的 VPC 内运行 Lambda 函数，但这应该很快就会实现。