Lambda Web Functions 选型指南：新 Web 应用的适用场景、快速上手与成本对比
内容提要
Lambda Web Functions（2026年10月推出）支持Node.js Web应用直接以HTTP server运行，无需适配，单环境可并发处理最多128个请求，仅按实际CPU时间计费，空闲时可缩容至零。适用于LLM流式代理、BFF、SSR等以等待为主的负载；月请求量上亿、CPU利用率稳定在40%以上的核心服务宜选用ECS Express Mode；事件驱动任务仍使用Event Function。目前仅支持Node.js 24/Arm64及5个Region，不支持WebSocket和中国区。
延伸解读
计费逻辑决定选型：等待时间是否收费是关键
Web Function 与 Event Function 的核心差异不在单价，而在计费维度。Event Function 按请求从开始到结束的整段时长计费，等待数据库或下游服务的时间也要付费；Web Function 只按实际消耗的 CPU 时间计费，等待期间几乎不产生 CPU 费用。因此，LLM 流式代理这类连接开很久、CPU 用得很少的负载，Web Function 可便宜约 20 倍；普通 API 也能便宜约 2.8 倍。但纯 CPU 计算型请求，Event Function 反而略便宜。选型时应先估算请求
与 ECS Express Mode 的成本分水岭是 CPU 利用率
文章给出的月成本对比显示，月请求量在 1000 万以内时 Web Function 基本最便宜；ECS Express Mode 因至少常驻 1 个 task 和 ALB，每月固定成本约 45 美元。两者谁更便宜，关键看 Fargate 的平均 CPU 利用率：低于约 30% 时 Web Function 更划算，稳定在 40% 以上时 ECS Express Mode 更便宜。此外，每个请求消耗的 CPU 越少，Web Function 的请求费占比越高，盈亏点会向更低的利用率移动。新应用不宜直接按 50% 利用
上线前需重点关注的限制与运维差异
Web Function 超出并发限制时直接返回 429 而不排队，maxEnvironments 设得太小，突发流量会大量报错。它没有 Provisioned Concurrency，空闲环境约 5 分钟后回收，冷启动仍可能发生；也没有 Lambda Extensions API，依赖 Extension 的 APM 方案需改为进程内 SDK 或 OpenTelemetry 上报；且无会话粘性，应用须按无状态设计。日志会先写入运行 Region 的 .local 组再复制到 home Region，多 Regio
迁移前先核对前提条件，避免为迁而迁
Web Function 目前仅支持 Node.js 24 / Arm64、固定 2 vCPU / 2 GB 规格，且只开放美东 1、美东 2、美西 2、东京、爱尔兰五个 Region，不支持 WebSocket 和中国区。从 Event Function + LWA 迁移需改为监听 AWS_LAMBDA_HTTP_ENDPOINT，并删除 LWA 相关配置；原先由 API Gateway 提供的 authorizer、按路由限流、usage plan 等能力要改由应用、CloudFront 或 WAF 实现。从
Q&A
Lambda Web Functions 和原来的 Lambda Event Functions 在并发处理上有什么不同？
Lambda Web Functions 的一个执行环境默认能同时处理 64 个请求，最多可配置到 128 个；而 Event Function 的一个执行环境同一时间只处理一个请求。
哪些场景适合用 Lambda Web Functions？
适合以等待为主的负载，例如 LLM 流式代理、BFF/聚合 API、SSR（如 Next.js standalone），以及面向多个地区用户的 Web API。这些场景大部分时间在等数据库或下游服务，CPU 实际使用时间短，Web Function 只按实际 CPU 时间计费，成本优势明显。
Lambda Web Functions 目前有哪些限制？
目前仅支持 Node.js 24（nodejs24.x）和 Arm64 架构，每个执行环境固定 2 vCPU / 2 GB；只开放美东1、美东2、美西2、东京、爱尔兰五个 Region，中国区不可用；不支持 WebSocket，仅支持 HTTP/1.1 和流式响应；没有 Provisioned Concurrency、Lambda Extensions API 和会话粘性。
Lambda Web Functions 和 ECS Express Mode 在成本上怎么选？
关键看 CPU 利用率：Fargate 平均 CPU 利用率低于约 30% 时 Web Function 更便宜；稳定在 40% 以上时 ECS Express Mode 更便宜。月请求量在 1000 万以内 Web Function 基本最便宜；按 50% 利用率算，月请求量约 2600 万时 ECS Express Mode 才开始更便宜。
如何从零部署一个 Lambda Web Function？
先写一个监听 AWS_LAMBDA_HTTP_ENDPOINT 环境变量指定 host:port 的标准 HTTP server（Express、Hono、Fastify 等无需适配）；然后用 AWS CLI v2.37.13+ 执行 aws lambda-web deploy 快速验证；生产环境建议用 SAM 的 AWS::Serverless::WebFunction 资源管理，代码需放在开启版本控制的 S3 存储桶中。
Lambda Web Functions 的流式响应（SSE）怎么计费？和 Event Function 有什么区别？
Web Function 无需额外配置，应用直接写 chunked 响应或 SSE 即可，多个流可共用一个执行环境，没有单独的流式传输费，只按实际 CPU、内存、请求数和数据传输计费；Event Function 需要专门开启流式模式，每个流独占一个执行环境，流开着的整段时间都按时长计费，且超过 6 MB 的部分按 $0.008/GB 收流式传输费。
已有的 Node.js Web 应用迁移到 Lambda Web Functions 需要注意什么？
需先确认满足语言、Region、规格、协议四个前提条件。从 Event Function + LWA 迁移要改成监听 AWS_LAMBDA_HTTP_ENDPOINT，删除 LWA 扩展和相关环境变量；从 Event Function + handler 迁移要把 handler 改写成标准 HTTP server；从 ECS/EC2 容器迁移要把交付物改为代码包，并评估依赖粘性会话、本地状态、WebSocket 或后台 worker 的部分是否需改造或保留在 ECS。
