目录

AWS 发布了 AWS Lambda Web Functions，可将 Node.js Web 应用直接部署到 Lambda。根据所提供的 2026 年 10 月 20 日 Publickey 文章，该服务支持 Next.js、Express、Hono、Fastify 等框架，现已在包括东京在内的 5 个区域推出。

要点#

  • Web Functions 可在 Lambda 上运行 Node.js Web 应用，无需单独管理 HTTP 适配器。
  • 每个执行环境使用 Node.js 24，配备 2 GB 内存，最多支持 128 个并发请求。
  • 请求超时时间默认为 30 秒，可在 3 秒至 15 分钟之间设置。
  • 用于生产环境前，需要查阅 AWS 文档，确认定价、框架功能支持范围和部署要求。

Web 应用会有哪些变化#

Web Functions 提供 Node.js 框架所需的 Web 服务器功能。无需将 HTTP 请求转换为传统 Lambda 函数处理程序所需的格式，即可部署围绕 Node.js Web 服务器构建的应用。

公告明确支持 Next.js、Express、Hono 和 Fastify。此外，据文章介绍，现有的事件驱动函数模型将采用“Lambda Event Functions”这一名称。

实际好处是，已有 Node.js 应用的团队可以简化部署方式。不过，“可直接部署”并不保证所有框架功能、依赖项和托管集成都能无需配置即可运行。

了解运行限制#

文章列出的配置揭示了迁移应用前需要评估的具体限制。

| 设置 | 文中列出的值 | |---|---| | 运行时 | Node.js 24 | | 每个执行环境的内存 | 2 GB | | 默认 JavaScript 堆大小 | 1,024 MB | | 每个环境的并发请求数 | 最多 128 个 | | 默认超时时间 | 30 秒 | | 可配置的超时时间 | 3～900 秒 |

这里的并发数指单个执行环境内同时处理的请求数，并不代表整个应用的处理能力、吞吐量或响应时间。这些指标取决于工作负载特征、扩缩容和服务配额，但所提供的文章未说明相关细节。

并发请求共享执行环境的资源，因此需要留意内存。处理大型负载或执行服务端渲染的应用，需要在实际预期的并发请求数下进行测试。此外，请勿混淆 2 GB 的内存分配量与默认的 JavaScript 堆上限。

确认可用区域#

文章列出了以下 5 个受支持的 AWS 区域。

  • 亚太地区：东京。
  • 美国东部：弗吉尼亚北部、俄亥俄。
  • 美国西部：俄勒冈。
  • 欧洲：爱尔兰。

由于东京区域已可用，为日本用户提供服务的团队可以立即考虑采用。不过，仅选择东京并不一定能获得可接受的延迟。数据库所在位置、外部 API 调用以及应用处理也会影响响应时间。

规划迁移前，请确认所需区域是否支持 Web Functions。对于有区域故障恢复要求的应用，还应确认是否有合适的备用区域可用。

迁移生产环境前先测试#

从小型应用或可独立验证的路由入手。查阅 AWS 文档中的部署步骤，并验证以下 4 项。

1. 运行时兼容性： 确认依赖项是否支持 Node.js 24，包括原生模块和构建产物。 2. 框架行为： 测试应用实际使用的功能，例如服务端渲染、中间件、流式传输和静态资源。 3. 负载下的表现： 逐步增加并发请求数，测量延迟、错误和内存使用量。 4. 运维要求： 检查日志、机密信息、身份验证、部署回滚，以及与数据库或私有服务的连接。

部署成功只能确认应用能够启动，尚不能证明生产工作负载适合该执行模型。

所提供的文章未明确说明定价、冷启动行为、扩缩容配额以及与框架的详细兼容性。尤其是在与现有托管服务比较时，需要确认这些事项。仅支持 Next.js，并不足以认定相关部署流程和托管功能也具有同等水平。

下一步#

在受支持的区域部署一个有代表性的路由，通过负载测试记录响应延迟、错误率和内存使用量，再决定是否迁移应用的其余部分。

来源: https://www.publickey1.jp/blog/26/aws_lambdanextjshononodejsaws_lambda_web_functions.html

目录