摘要

AWS 宣布推出 Lambda Web Functions，一种新的形态，让标准 HTTP Web 应用可以直接跑在 Lambda 上，而无需把代码改写成事件处理器。开发者可以用 Express、Hono、Fastify、Next.js 或任何 Node.js 框架写就的监听端口的标准服务，通过一条命令部署，由 Lambda 自动处理扩缩容、多区域分发与活跃 CPU 计费，无需适配器、无需管理基础设施、无框架锁定。至此 Lambda 提供三种形态：Event Functions（既有事件驱动模型）、Web Functions（本次新增）、MicroVMs（隔离有状态沙箱），三者同基于 Firecracker 隔离技术。单个执行环境最高支持 128 个并发请求，突发流量可共享热环境；计费按活跃 CPU 时间计量，等待数据库或 API 响应的 I/O 时间几乎不耗 CPU。上线区域为美东（弗吉尼亚北部）、美东（俄亥俄）、美西（俄勒冈）、亚太（东京）与欧洲（爱尔兰），运行 Node.js 24（nodejs24.x）on Arm64，并支持 VPC 连接。

正文（译文）

现代 Web 应用需要以快速、一致的响应时间为全球用户提供服务，同时让开发者有自由去使用标准框架并快速迭代。今天要构建这样的应用，通常需要拼装多个基础设施组件、配置多区域部署、设置基于延迟的路由，并调整计费模型以避免为 I/O 等待付费。开发者常常发现自己在把应用代码改造成适配某种特定计算模型，而不是直接部署他们本来就有的那个 HTTP 服务器。

Lambda Web Functions 消除了这种复杂性。每个执行环境可同时处理多个请求（每个环境最多 128 个并发请求），这意味着突发流量可以共享热环境，而不是把每个请求映射到一个新环境。Web Functions 按你代码实际使用的 CPU 时间计量，因此花在等待数据库查询或 API 调用上的时间几乎不消耗 CPU。内存则按执行环境的存续时间计量。对于 I/O 密集的 Web 工作负载——如服务端渲染、API 后端，以及流式输出 token 响应的 AI 推理端点——这可以降低计算成本。

先说我写的一个简单 Express.js 服务。这和我在本地运行的代码完全一样，不需要任何 Lambda 专用的适配器或包装层。

const [host, port] = process.env.AWS_LAMBDA_HTTP_ENDPOINT.split(':'); app.get('/', (req, res) => { res.json({ message: 'Hello from Lambda Web Functions!' }); app.listen(port, host, () => { console.log(Server running on port ${port});

与本地运行唯一的区别是 AWS_LAMBDA_HTTP_ENDPOINT 这个环境变量，Lambda 会把它设为你的服务器必须监听的主机和端口。要在本地运行，你自己设置即可，例如：

AWS_LAMBDA_HTTP_ENDPOINT=127.0.0.1:3000 node index.js

代码就绪后，我用 AWS 命令行界面（AWS CLI）进行部署：

aws lambda-web deploy --name my-web-app --code ./my-app

一条命令，无需预先创建任何资源。CLI 打包了我的源码、创建了 Web Function、发布了它的第一个 revision、挂接了一个 Web Function 端点，并在一分钟内返回了一个可用的 HTTPS URL。

一个 revision 是我所部署代码的不可变快照。端点是那个把流量路由到某个 revision、或在多个 revision 之间分配流量的 HTTPS URL。这些就是我用来迭代和控制流量如何迁移到新代码的资源。

$ curl https://<domain-id>.<shard-id>.lambda-web.us-east-1.on.aws/ {"message":"Hello from Lambda Web Functions!"}

接下来，我想让我的应用以更低延迟服务欧洲和亚洲的用户。我用多区域重新部署：

aws lambda-web deploy --name my-web-app --code ./my-app --regions us-east-1,eu-west-1,ap-northeast-1

Lambda Web Functions 把我的代码复制到全部三个区域，并自动配置了基于延迟的路由。现在，每个请求都会以尽力而为的方式，通过同一个全局 URL 路由到对该调用方延迟最低的区域：

<domain-id>.lambda-web.global.on.aws

当我更新代码并再次运行同一条部署命令时，CLI 检测到已有的函数，上传了新的 revision，并把端点指向它。从代码变更到上线的总耗时：几秒钟。

对于需要更渐进式发布的生产流程，我可以用一次 API 调用在 revision 之间切换流量：

aws lambda-web update-web-function-endpoint --function-name my-web-app --auto-deployment-mode Disabled --revision-weights '[{"revisionId": "<current-revision-id>", "weight": 90}, {"revisionId": "<new-revision-id>", "weight": 10}]'

这会把端点 90% 的流量发给当前 revision、10% 发给新 revision，从而无需额外工具就实现金丝雀部署。

与 Amazon CloudFront 协同更佳

对于同时包含静态与动态内容的应用，Web Functions 与 Amazon CloudFront 配合良好。你可以选择一个 Web Function 端点作为 CloudFront 分配的源站。静态资源从缓存提供，而动态请求路由到你的 Web Function，从而让静态内容获得 CDN 性能，同时动态部分由无服务器计算承载。

Web Functions 还改进了 CloudFront 的私有源站体验。在此次发布后，你可以把 CloudFront 源访问控制（OAC）挂接到一个 Web Function 端点上。CloudFront 对发往源站的请求签名，而该端点只允许你的分配来调用它。你获得的是 CloudFront 为 Amazon Simple Storage Service（Amazon S3）已经提供的同款私有源站模式，无需暴露端点，也不必在你的应用中加入自定义鉴权。

AWS Lambda Web Functions 今天已在以下区域可用：美国东部（弗吉尼亚北部）、美国东部（俄亥俄）、美国西部（俄勒冈）、亚太地区（东京）和欧洲（爱尔兰）。Web Functions 在发布时运行 Arm64 上的 Node.js 24（nodejs24.x），并支持 Amazon Virtual Private Cloud（VPC）连接，使你的函数能够访问 VPC 内的资源。

立即开始，在一分钟内部署你的第一个 Web Function：

aws lambda-web deploy --name hello-world --hello-world