虽然只能在Lambda中构建整个网站，但必须考虑以下因素：
- API网关后面的Lambda超时限制为30秒，有效负载大小限制（接收和发送）均为6MB。虽然在大多数情况下这很好，但是如果您有一些非常大的操作或需要发送一些非常大的数据（例如高分辨率图像），则无法使用这种方法来完成，但您需要考虑一下其他的东西（例如，您可以将SNS发送到另一个具有更高超时值的Lambda函数，该函数可以异步完成所有这些操作，然后在完成后将结果发送给客户端，假设客户端能够接收事件）
- Lambda的启动很冷，换句话说，当客户端第一次调用它们时，它们会降低API的速度。冷启动时间取决于您使用Lambda的语言，因此您也可能会考虑这一点。如果您为Lambda使用C＃或Java，那么这可能不是最佳选择。从这个角度来看，随着Golang的崛起，Node.JS和Python似乎是最佳选择。您可以找到有关here的更多信息。顺便说一下，您现在可以为Lambda指定一个
Provisioned Throughput，目的是解决冷启动问题，但是我还没有使用它，所以我无法确定是否有任何区别（但是我'肯定有）
- 如果操作正确，最终将管理数百个Lambda函数，而使用ECS下的标准Docker容器，您将管理多个具有多个端点的API。这一点不应该被低估，因为一方面，它将使将来的更改变得更加容易，因为lambda很小，您将容易找到并修复该错误，但是另一方面，您必须遍历这些功能，如果您不完全知道哪个lambda负责，那可能是一个漫长的过程
- 据我所知，Lambda无法处理会话。因为一段时间后，Lambda容器被丢弃，所以您无法在Lambda本身内部存储任何会话。您将始终需要一种结构来存储会话，以便可以在多个Lambda调用之间共享该会话，例如DynamoDB表中的某些记录或其他内容，但这意味着您必须为此编写代码，而在经典模式中API（就像.NET Core一样）都是由语言本身处理的，并且您只需要（大部分时间）从会话中存储或检索项目即可。
所以...是的！可以完全使用Lambda编写支持文件。我工作的公司做到了，在速度和开发时间方面，我必须说要好得多。但是这些好处会在以后出现，因为您需要面对我之前列出的所有原因，而且看起来并不容易
是的，您可以使用AWS Lambda作为后端并在那里与Stream API集成。
直接在Lambda上构建整个应用程序将非常复杂，并且需要编写大量样板代码才能为您的项目实施一些基本的组织和结构。
我的建议是使用无服务器框架来做到这一点，以确保您的应用程序井井有条，并部署新版本（和环境）。
无服务器是一个很好的选择：https://serverless.com/framework/docs/providers/aws/guide/intro/