AWS 发布 Lambda Web Functions，可直接运行标准 HTTP Web 应用

今天，我们宣布推出 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 后端，以及以多个并发请求和 I/O 密集型处理为常态的交互式 HTTP 工作负载。

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

这三种形态相辅相成。一个应用可能使用 Event Functions 进行异步后端处理，使用 Web Functions 作为面向用户的 API 和服务器端渲染层，并使用 MicroVMs 实现交互式代码执行功能，所有这些都在同一个 AWS 账户内，并共享相同的运维模型。

为什么需要 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 命令行界面（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 源访问控制（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 定价页面。要了解更多信息，请参阅 Lambda Web Functions 文档。