AWS 发布 Lambda Web Functions，新增 HTTP 原生无服务器形态

今天，我们宣布推出AWS Lambda Web Functions，这是一种全新形态，让您无需将代码改写为事件处理程序，即可在 Lambda 上运行标准的 HTTP Web 应用程序。您可以直接使用由 Express、Hono、Fastify、Next.js 或任何 Node.js 框架构建的标准端口监听服务器，通过一条命令完成部署，Lambda 会自动负责扩缩容、多区域分发以及活动 CPU 计费。无需适配器，无需管理基础设施，也不会被框架锁定。

借助此次发布，AWS Lambda 现在提供三种截然不同的形态，它们都基于相同的 Firecracker 隔离技术，并针对不同的编程模型而设计。

Lambda Event Functions 就是您所熟知的 Lambda 函数。它们采用事件驱动、单一并发的处理程序模型，并按实际耗时计费。我们引入 "Event Functions" 这一名称，是为了突出这种编程模型：您的函数接收事件、处理事件，并返回响应。事件驱动编程模型非常适合事件处理、队列消费者，以及由其他 AWS 服务触发的调用场景。

Lambda Web Functions 采用原生 HTTP 的编程模型，支持多并发执行和活动 CPU 计费。您的代码监听一个端口并处理标准 HTTP 请求。该编程模型非常适合 Web 应用程序、API 后端以及交互式 HTTP 工作负载，在这些场景中，多个并发请求和 I/O 密集型处理是常态。

Lambda MicroVMs 提供隔离的、有状态的沙箱环境，生命周期由客户自管理，可用于运行不受信任或由用户生成的代码。

三者相辅相成。一个应用程序可以在同一个 AWS 账户中，使用 Event Functions 处理异步后端任务，使用 Web Functions 处理面向用户的 API 和服务端渲染层，使用 MicroVMs 提供交互式代码执行功能，并共享相同的运维模型。

为什么要推出 Web Functions
现代 Web 应用需要以快速、一致的响应时间服务全球用户，同时让开发者能够自由地使用标准框架并快速迭代。如今要构建这样的系统，通常需要拼凑多种基础设施组件、配置多区域部署、设置基于延迟的路由，并调整计费模型以避免为 I/O 等待付费。开发者常常不得不改造自己的应用代码去适配特定的计算模型，而不是直接部署他们已有的 HTTP 服务器。

Lambda Web Functions 消除了这种复杂性。每个执行环境可同时处理多个请求（每个环境最多 128 个并发请求），这意味着突发流量可以共享已预热的环境，而无需为每个请求都新建一个环境。Web Functions 按您的代码实际使用的 CPU 时间计费，因此等待数据库查询或 API 调用所消耗的 CPU 几乎可以忽略不计。只要执行环境存在，内存就会持续计费。对于服务端渲染、API 后端，以及流式输出 token 响应的 AI 推理端点等 I/O 密集型 Web 工作负载而言，这可以降低计算成本。

动手试一试
为了上手，我编写了一个简单的 Express.js 服务器。这与我在本地用 node index.js 运行的代码完全相同，无需任何 Lambda 专用的适配器或包装层。

import express from 'express';

const app = express();
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 Command Line Interface (AWS CLI) 进行部署：

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

一条命令。无需事先设置资源。CLI 打包了我的源代码，创建了 Web Function，发布了其第一个版本，附加了 Web Function 端点，并在不到一分钟内返回了可用的 HTTPS URL。

版本是我所部署代码的不可变快照。端点是将流量路由到某个版本、或在多个版本之间分配流量的 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 检测到现有的函数，上传了新版本，并将端点指向它。从代码改动到上线的总周转时间：数秒。

对于需要更渐进式发布的生产工作流，我可以通过一次 API 调用在各版本之间转移流量：

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

这会将端点流量的 90% 发送到当前版本、10% 发送到新版本，从而让我无需额外工具即可实现金丝雀部署。

与 Amazon CloudFront 强强联合
对于同时包含静态和动态内容的应用程序，Web Functions 与 Amazon CloudFront 配合得很好。您可以选择一个 Web Function 端点作为 CloudFront 分发的来源。静态资产从缓存提供，而动态请求则路由到您的 Web Function，使您为静态内容获得 CDN 性能，并为动态部分提供无服务器计算。

Web Functions 改善了与 CloudFront 配合使用的私有来源体验。 通过此次发布，您可以将 CloudFront origin access control (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

有关定价详情，请访问 AWS Lambda pricing page。要了解更多信息，请参阅 Lambda Web Functions documentation。