Lambda 可直接跑 HTTP 服务，单环境并发达128

Lambda Web Functions 把 Lambda 的运行单元从事件处理函数扩展成了监听端口的 HTTP 服务。按原文介绍，Express、Fastify、Hono 可以直接运行，单个执行环境默认承载 64 个并发请求，最高 128 个。对做 Node API 和流式响应的团队，这比「又多一种部署方式」更值得研究。

关键变化在于连接如何共享资源，以及等待如何计费。不过，原文的演示更能说明它适合什么负载，还不足以证明迁移后一定省钱。判断之前，需要把并发、状态和账单放在一起看。

普通 HTTP 服务进了 Lambda，应用边界怎么变

原文引用的 AWS 文章发表于 2026 年 10 月 13 日，介绍了与 Event Functions 并列的 Web Functions；2026 年 10 月 19 日的周报又将 MicroVMs 纳入，合计三种形态。Web Functions 沿用 Firecracker 隔离机制，开发入口则从接收事件的 handler，变成了监听端口的服务进程。

因此，原本围绕 HTTP 服务编写的框架，无需在前面加适配层，就能交给 Lambda 托管。进程可以持续处理请求、保持响应流，也能在主请求路径之外执行后台工作。

部署仍然走托管路线。按原文描述，一条部署命令或 CloudFormation 就能完成构建、创建函数和 HTTPS endpoint，并返回访问地址，同时创建执行角色和区域内 CLI 部署函数共享的版本化 S3 bucket。原文没有给出命令文本，不能据此补出可复制的部署指令。

流量入口由 endpoint 管理，包括域名、认证类型和路由规则。revision 是代码与配置的不可变快照，回滚通过把路由切回旧 revision 完成。

认证有两条路：公开 endpoint，由应用处理 OAuth、JWT 或 session cookie；IAM endpoint，由 Lambda 校验签名，单区域使用 SigV4，多区域使用 SigV4a。公开入口并不免除应用自身的认证责任。

128 个并发请求，为什么不等于 128 倍处理能力

单环境并发上限提高，首先改善的是等待型请求共享资源的方式。

Web Functions 每个执行环境默认允许 64 个并发请求，最高可设为 128。环境接近上限时，Lambda 增加环境；流量下降时再回收。多个连接可以共处一个环境，不必各占一个。

原文转述的演示发起了 300 个流式请求，同时最多保持 200 个连接。平台日志显示，总共使用了 5 个环境，其中一个环境的连接峰值为 59，接近默认上限 64。另一个汇总口径显示，484 个请求合计消耗约 4.8 秒 CPU。

原文拿 Event Functions 作比较：一个环境同一时间服务一个请求，因此 200 个打开的流，在这种模型下可能占用最多 200 个环境。这里的价值是减少等待期间占用的环境数量，不能直接推导成吞吐提升或成本下降的倍数。

还要留意两个边界。第一，300 个流式请求与 484 个汇总请求不是同一数字，原文没解释差额来源，不宜拼成一组严格的性能结论。第二，环境可能在达到上限之前扩容，不能用「200 除以 64」预测实际环境数。

endpoint 还有独立的每秒请求数上限。超出的流量直接收到 HTTP 429，平台不会在后面排队。这让过载行为比较明确，也可能帮助保护数据库，但调用方必须考虑失败处理；无节制重试会把被拒绝的流量重新压回来。

等待几乎不吃 CPU，但连接仍然占内存

Web Functions 把计费拆成请求数、实际消耗的内存和 CPU 时间。原文用一个哈希循环展示差别：CPU 使用持续约 1.5 秒，随后回落到接近零，而进程仍然保持运行。

这对等待数据库、外部 API 或推理调用的服务有吸引力。连接开着，不代表 CPU 一直忙。浏览器等待服务端逐步返回内容时，多个连接可以共享环境中的计算资源。

但等待并非免费。连接、缓冲区和应用状态仍然占内存，请求本身也计费。原文没有列出单价，更没有给出与传统 Lambda、容器或常驻服务的完整账单对照，因此「等待型负载可能更合适」有依据，「一定更便宜」没有。

发布时的配置边界也很具体：Node.js 24、Arm64，每个环境 2 vCPUs 和 2 GB 内存，支持访问 VPC 内资源。128 是并发请求上限，不是可以同时满速执行的 CPU 密集任务数。压缩、持续哈希等工作仍然要争用这 2 vCPUs。

多区域 endpoint 会复制代码和 revision 配置，提供全局域名与基于延迟的路由，并把日志集中到 home region。AWS 从英国一台笔记本测得，访问 London 为 16 ms，Northern Virginia 为 90 ms。原文明确说这是单地点的单次测量，没有延迟分布，不能当成普遍性能承诺。

我的判断

我认为最有价值的变化，是熟悉的 Node HTTP 服务模型与多请求共享环境结合了起来。已有 Express、Fastify 或 Hono 应用的团队，迁移入口可能更直接；但「不用适配层」不代表应用可以不改运行假设。

最先要检查的是状态。Web Functions 没有会话亲和性，同一用户的两次请求可能落到不同环境。购物车、全局限流计数、需要跨请求一致的权限状态，都不能只依赖进程内存。把这些内容放到外部存储后，还要承担存储的延迟、容量和运维成本。

后台工作也有类似限制。进程可以在响应之外继续执行，并不保证任务能在环境回收后存活。必须完成的操作，需要持久队列或数据库记录来保存进度。

与常驻容器相比，这套方案提供了托管扩缩容和不同的计费方式，同时要求应用适应环境回收与请求独立路由。与 Event Functions 相比，它更贴近多连接 HTTP 服务。原文没有同负载、同区域的对照数据，环境更少究竟能省多少钱，仍然需要实测。

能拿来做什么

• 挑一个现有 Node 流式接口做小范围验证，保持几百个连接，记录环境数量、单环境峰值并发、CPU 秒数和请求持续时间，再结合内存占用估算费用。
• 检查 Express、Fastify 或 Hono 服务里的进程内状态，优先处理 session、共享限流和需要一致性的业务数据，并明确后台任务如何在环境回收后恢复。
• 给前端调用链补上 HTTP 429 的处理，检查重试间隔、次数和用户提示，同时观察后端依赖是否先于函数环境达到容量上限。
• 迁移前核对 Node.js 24、Arm64 与原生依赖的兼容性；对 CPU 密集接口单独压测，不用流式连接的演示结果替代计算性能评估。