我对服务器世界比较陌生，所以请原谅我，如果其中一些是基本的（第一位文本将是我解释我的逻辑，以确保没有缺陷）。 我的所有问题都会以粗体显示，让你的帮助变得更简单:)
我一直在研究和教授自己的一些AWS技术，并且我在他们的Mobile Hub中注意到，如果您需要云逻辑，他们只允许“自动”设置Lambda函数。 在阅读和研究之后，我发现了一些指向“无服务器”体系结构（Lambda支持）的资源。 过去，我的理解是引入了Elastic Beanstalk，使服务器pipe理（尤其是移动设备）的pipe理更为简单。
对于移动开发，有2个选项（显然更多，但为简单起见，我们会同意）：
所有这一切使我相信，一个完整的Lambda后端将是完全可能的，并且容易创build，其成本只有服务器全天候运行的一小部分。 那是对的吗？
现在，假设上述是正确的，我们需要确定使用Lambda是否真的比Elastic Beanstalk有利。
对于简单的服务器，我们可以设置一些Lambda函数，并在一天内调用它（与使用Elastic Beanstalk相比，它可能更简单，更便宜（至less对于小型项目））。
但是，对于具有更多url和数据库连接的更复杂的服务器，情况会变得更加有趣。
这些是我在上述情况下使用Lambda所看到的问题
避免前两个问题的唯一方法就是创build一个充当调度的健壮函数（主函数从API网关获取参数，并确定在Lambda函数中运行哪个文件）。
有没有什么重要的一点，我想确定如果使用Elastic Beanstalk上的Lambda是值得的？
为了让每个人都在循环中，我没有得到回应，所以我问StackOverflow并从mbaird得到以下回应 。 在评论中有一些讨论，所以请随时检查一下，并给他信用。
这听起来像你已经知道了。 您正确地使用Lambda而不是让服务器24/7全天候运行可以节省大量成本。 本文提出的主张是：
而且这也节省了一些亚马逊客户的大笔资金，至less有一位快乐的Lambda客户可以节省80％的云账单。 你可能想看看pipe理一些痛点的无服务器框架。
我认为随着时间的推移，许多痛点将消失，亚马逊增加更多function到Lambda和更多的第三方工具为它build立。 我不断发现Lambda的新用途，但我也不断地发现用起来看起来不错的用途，但是对Lambda来说并不真正起作用，至less现在还不行。 例如，我真的需要一些方法来限制可同时运行的Lambda函数的实例数量，以防止最大化可用的数据库连接或达到第三方API的使用限制。 我也非常需要Lambda函数在我的VPC中运行，但是这应该很快就会到来。