宣布推出 AWS Lambda Web Functions

今天，我们宣布推出 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 MicroVM 提供隔离、有状态的沙盒环境，其生命周期由客户管理，用于运行不可信代码或用户生成的代码。

这三者相辅相成。应用程序可能会使用 Event Functions 进行异步后端处理，使用 Web Functions 用于面向用户的 API 和服务器端渲染层，使用 MicroVM 来实现交互式代码执行功能，所有这些都位于同一 AWS 账户内并共享相同的运营模型。

为什么选择 Web Functions
现代 Web 应用程序需要以快速、一致的响应时间为全球受众提供服务，同时让开发人员可以自由使用标准框架并快速迭代。如今构建此功能通常需要组装多个基础设施组件、配置多区域部署、设置基于延迟的路由，以及调整计费模型，以避免为 I/O 等待付费。开发人员经常发现自己正在调整应用程序代码以适应特定的计算模型，而不是部署他们已经拥有的 HTTP 服务器。

Lambda Web Functions 消除了这种复杂性。每个执行环境同时处理多个请求（每个环境最多 128 个并发请求），这意味着大量的传入流量可以共享热环境，而不是将每个请求映射到一个新的环境。Web Functions 会计量代码使用的 CPU 时间，因此等待数据库查询或 API 调用的时间消耗的 CPU 很少。只要执行环境存在，就会计量内存。对于服务器端渲染、API 后端和人工智能推理端点流式传输令牌响应等 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 文档。