最近我一直在研究AWS Lambdas以及如何使用.Net Core构建无服务器API。据我了解，您可以通过两种不同的方式做到这一点。
1( 用 C# 编写多个单独的 Lambda 并将它们部署到 AWS。请求通过 API 网关传入，每个 lambda 充当终端节点。
2( 使用 .Net 核心构建无服务器 Web API。当您创建无服务器 Web API 项目时，将自动创建一个 Lambda，它将成为 Web API 的入口点。
是否存在 1 对 2 的限制，或者一种方法可能优于另一种方法的用例？或者只是实现同一件事的两种不同方式？
我认为你的选择不正确。构建 Lambda 支持的 API 的两个选项是：
1- 构建 lambda 并将其独立部署到一个或多个项目中的 AWS。然后手动创建指向一个或多个 lambda 的 API 网关终端节点。
2-使用无服务器项目将您的lambda合并到一个项目中。在该项目中定义您的终端节点，并让 Cloudformation 创建 API 网关终端节点，并在部署时将它们挂接到您的 lambda。
就利弊而言，
选项 1：
优点：具有独立部署 lambda 的灵活性，您也可以根据需要配置您的 API 网关终端节点，而无需了解 Cloudformation 定义语法，根据我的经验，这需要一些时间。
缺点：如果你有很多lambda，这将成为一场管理噩梦。此外，终结点定义不在源代码中，并且不会跟踪对终结点配置的更改。
选项 2：
优点：如果您弄清楚了 Cloudformation，或者如果您想使用默认配置部署 lambda 并将其挂接到 API 网关终端节点是非常容易的。AWS 将为您创建终端节点，并创建开发和生产阶段、策略、IAM 角色等。Cloudformation 直接从 Visual Studio 部署这会导致整个部署和所有相关对象都属于 AWS Cloudformation 中的同一"堆栈"，可以非常轻松地进行更改、回复或删除。此外，您的基础架构现在是代码，对它的更改可以在您的 git 存储库中审核。
缺点：在我看来，最大的缺点是堆栈不跨越VS解决方案，而只是跨越项目，所以你所有的lambda都必须存在于同一个项目中，这意味着如果你有很多，它们最终将全部在一个整体lambda二进制文件中。生成的大型项目二进制文件将消耗您在 AWS 上的内存运行时间和效率问题。另一个缺点是，如果您想拥有特定的或非常规的 API 网关，则需要了解 Cloudformation 语法来更改您的 serverless.template 文件。
结论：我的首选解决方案是根据 API 对象将我真正的应用程序划分为较小的相关 lambda 块，并将这些 lambda 放置在几个无服务器应用程序项目中。例如，我有一个订单项目，其中包含与订单 API 相关的所有 lambda，还有一个包含与产品 API 等相关的 lambda 的产品项目。它们将位于同一解决方案中，并将单独部署。我目前正在研究一种一次部署整个解决方案的方法。