Lambda Web Functions 选型指南：新 Web 应用的适用场景、快速上手与成本对比

摘要：2026 年 10 月推出的 Lambda Web Functions 提供了在 AWS 无服务器环境下运行 Web 应用的新方式。本文介绍了 Lambda Web Functions 和现有 Lambda Event Functions / Amazon ECS 的功能和成本对比，以及 Web 应用如何选择合适的运行环境。

一、在 AWS 上运行 Web 应用的几种选择

在 AWS 上部署 Web 应用或 API 后端，常见的计算选项有这几种：

LWA 的原理和用法可以参考 使用 Lambda Web Adapter 在 Lambda 上构建 Web 应用。

在 Web Functions 推出之前，如果既想不管服务器、没流量时不花钱，又想直接用标准 Web 框架，基本只能二选一：用 ECS，接受资源一直开着的成本；或者用 Lambda + LWA，接受一个环境只处理一个请求、等待时间也要付费。

2026 年 10 月推出的 Lambda Web Functions 把两边的好处合在了一起：代码直接监听端口，Express、Hono、Fastify 这些框架不用适配；一个执行环境默认能同时处理 64 个请求（最多 128 个）；CPU 只按实际用掉的时间收费，等数据库或下游服务的时候不收 CPU 费用；没流量时可以缩到零。原来的 Lambda 函数同时改名为 Event Functions。

下面围绕 Web 应用回答三个问题：

1. 什么样的负载适合用 Web Function，什么时候该选 ECS Express Mode 或 Event Function？
2. 怎么从零上手，并用 IaC 管理生产部署？
3. 和其他方案比成本如何，什么情况下反而更贵？

二、先看能不能用：四个前提条件

下面任何一条不满足，就暂时不适合用 Web Function：

另外，设计应用时还要注意三点：

• 没有 Provisioned Concurrency：Web Function 没有常驻的预热容量，空闲一段时间后的第一个请求可能会遇到冷启动。不过多个请求可以共用已经热起来的环境，冷启动次数会少很多。
• 没有 Lambda Extensions API：靠 Extension 采集数据的 APM 方案用不了，要改成在进程里用 SDK 或 OpenTelemetry 上报。
• 没有会话粘性：同一个用户的连续请求可能落到不同的执行环境，应用要按无状态来设计。

三、场景选型：三种方案怎么分工

3.1 典型场景与推荐

常见的组合是：面向用户的 HTTP 流量放在 Web Function，异步任务交给 Event Function，长期大流量、负载平稳的核心服务放在 ECS Express Mode。三者可以在同一个账号里一起用。

3.2 流式响应（streaming）

LLM 对话、SSR 这类场景经常需要边生成边返回。两种 Lambda 函数都能做流式响应，但支持方式和计费不一样：

所以对 LLM 流式代理这种“连接开很久、CPU 用得很少”的负载，Web Function 在成本和并发上都占优势。第五节的“LLM 流式代理”一行就是按这个模式算的。

3.3 三种方案的关键差异

最后一行要特别注意：Web Function 超出限制时不排队，直接返回 429。maxEnvironments 设得太小，流量突然上涨时就会出现大量报错。具体见后面的“上线前检查清单”。

四、快速上手：从零部署一个 Web Function

下面用两个常见场景做例子：

• 场景 A：AI 对话应用。浏览器把问题发给 Web Function，Web Function 调用 Amazon Bedrock，把模型的回答用 SSE 一段段推回浏览器。
• 场景 B：业务应用的前后端。Web Function 负责前端页面和 /api/* 接口（BFF），具体的业务逻辑放在 Event Function 里，由 Web Function 调用。业务后端写成 Event Function，同一份逻辑以后还能被 SQS、EventBridge 等事件直接触发。

两个场景里，Web Function 大部分时间都在等 Bedrock 或后端返回，等待的这段时间不收 CPU 费用，同一个执行环境还能继续接别的请求。

4.1 Step 1：写一个监听端口的 HTTP Server

Express、Hono、Fastify 这类自己启动 HTTP server 的框架不用任何适配；Next.js standalone 模式需要加一个设置 host 和端口的入口文件。运行时会通过环境变量 AWS_LAMBDA_HTTP_ENDPOINT 告诉应用该监听哪个 host:port。两个场景共用下面这个骨架，和 Lambda 有关的只有监听地址那一行：

// index.js（放在代码包根目录；如果入口文件不在这里，用 AWS_LAMBDA_NODEJS_ENTRYPOINT 指定）
import express from 'express';
const app = express();
app.use(express.json());
app.use(express.static('public'));   // 前端页面
// ……下面场景 A / B 的路由加在这里
const [host, port] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || '127.0.0.1:3000').split(':');
const server = app.listen(Number(port), host);
// Web Function 回收环境时，SIGTERM 之后只给约 1 秒，收尾逻辑要尽量短
process.on('SIGTERM', () => server.close(() => process.exit(0)));

4.1.1 场景 A：调用 Bedrock，流式返回

import { BedrockRuntimeClient, ConverseStreamCommand } from '@aws-sdk/client-bedrock-runtime';
const bedrock = new BedrockRuntimeClient({});
app.post('/api/chat', async (req, res) => {
  const out = await bedrock.send(new ConverseStreamCommand({
    modelId: process.env.MODEL_ID,
    messages: [{ role: 'user', content: [{ text: req.body.prompt }] }],
  }));
  res.setHeader('content-type', 'text/event-stream');
  for await (const ev of out.stream) {
    const text = ev.contentBlockDelta?.delta?.text;
    if (text) res.write(`data: ${JSON.stringify({ text })}\n\n`);
  }
  res.end();
});

4.1.2 场景 B：调用 Event Function 处理业务

Web Function 这一侧：

import { LambdaClient, InvokeCommand } from '@aws-sdk/client-lambda';
const lambda = new LambdaClient({});
app.post('/api/orders', async (req, res) => {
  const out = await lambda.send(new InvokeCommand({
    FunctionName: process.env.ORDER_FUNCTION,
    Payload: JSON.stringify({ items: req.body.items }),
  }));
  res.json(JSON.parse(Buffer.from(out.Payload).toString()));
});

Event Function 这一侧，就是普通的 Lambda handler：

export const handler = async (event) => {
  // 校验库存、写数据库……
  return { orderId: `o-${Date.now()}`, items: event.items.length };
};

两个场景都用执行角色的临时凭证调用 AWS 服务，代码里不需要写密钥；部署前要给执行角色加上对应权限：场景 A 是 bedrock:InvokeModelWithResponseStream，场景 B 是对订单函数的 lambda:InvokeFunction。SDK 依赖要随代码一起打包，npm install 之后部署整个目录即可。

本地执行 node index.js 就能调试；没设置 AWS_LAMBDA_HTTP_ENDPOINT 时，应用监听 127.0.0.1:3000。客户端 IP 等信息可以从 Lambda 加上的 x-forwarded-for、x-forwarded-proto 请求头里读取。

4.2 Step 2：先用 CLI 跑通

# 需要 AWS CLI v2.37.13 或更新版本，旧版本没有完整的 lambda-web 子命令
aws lambda-web deploy --name my-app --code . \
  --env MODEL_ID=<Bedrock 模型或推理配置文件 ID> \
  --env ORDER_FUNCTION=order-service

第一次创建时，命令会在终端里让你确认；在 CI 等非交互环境里，需要加上 --create。

我们按上面的代码实际部署了一遍（us-west-2，模型用 Amazon Nova Lite）：deploy 从打包到拿到 HTTPS URL 用了约 25 秒；/api/orders 调用 Event Function 返回约 0.3 秒；/api/chat 约 0.3 秒收到第一段文字，SSE 按段持续推送。

这条命令会自动创建执行角色、开启了版本控制的 S3 存储桶、函数、revision，以及名为 dev 的 endpoint，然后返回一个 HTTPS URL。用来验证代码能不能跑起来很方便，但生产环境不建议直接用 CLI 管理资源。

4.3 Step 3：用 SAM 管理生产部署

SAM 新增了 AWS::Serverless::WebFunction 资源，部署时会展开成 WebFunction、WebFunctionRevision、WebFunctionEndpoint 和 IAM 角色：

Transform: AWS::Serverless-2016-10-31
Parameters:
  CodeBucket:  { Type: String }
  CodeKey:     { Type: String }
  CodeVersion: { Type: String }
Resources:
  Api:
    Type: AWS::Serverless::WebFunction
    Properties:
      Runtime: nodejs24.x
      AuthType: IamAuth            # 放在 CloudFront + OAC 后面；如果由应用自己鉴权，改成 ApplicationManaged
      CodeUri:
        Bucket: !Ref CodeBucket
        Key: !Ref CodeKey
        Version: !Ref CodeVersion
      Timeout: 60
      MaxConcurrencyPerEnvironment: 64
      EnvironmentVariables:
        MODEL_ID: <Bedrock 模型或推理配置文件 ID>
        ORDER_FUNCTION: order-service
Outputs:
  Domain:
    Value: !GetAtt ApiEndpoint.DomainName

目前有两点要注意：

• 代码必须放在开启了版本控制的 S3 存储桶里，不能像 Event Function 那样直接上传 zip；存储桶策略还要允许 lambda.amazonaws.com 读取。截至 SAM CLI 1.168.0，sam build / sam deploy 还不会帮你打包上传 Web Function 的代码，CI 里要先 zip，用 s3api put-object 拿到 VersionId，再作为参数传给模板。
• CloudFormation 每次更新都会新建 revision，并删掉旧的。所以如果想用原生的 revision-weights 做 canary，光靠 CloudFormation 不够，还要在 CI 里调用 update-web-function-endpoint 调整权重。

4.4 用 AI 编程助手生成和部署

上面两个场景的代码，也可以直接让 AI 编程助手来写。Web Function 跑的就是标准 Node.js HTTP server，模型最熟悉的正是 Express、Hono 这类代码，生成出来基本可以直接部署，不需要模型去理解 Lambda 的事件格式。

AWS 官方的 Agent Toolkit for AWS 提供了专门的 Lambda Web Functions skill。最省事的装法是直接用 AWS CLI（需要 v2.35.9 或更新版本），它会识别本机已有的 Kiro、Claude Code 等编程助手，一并配置 AWS MCP Server 和默认 skill：

aws configure agent-toolkit --yes --region us-east-1
aws agent-toolkit add-skill --skill-name aws-lambda-web-functions --region us-east-1

Agent Toolkit 的 API 目前只在 us-east-1 提供，所以这两条命令要带 --region us-east-1，和应用部署在哪个 Region 无关。也可以用 npx skills add 安装，或在 Claude Code 里安装 aws-core 插件，各编程助手的装法见 Lambda 开发者指南的 Agent setup guide。

另外，用 aws lambda-web deploy --name my-app --hello-world 生成的 starter 项目里自带一份 AGENTS.md，写明了 Web Function 的运行约定，比如不要改成 handler 写法、监听端口、怎么写流式响应，编程助手打开项目就能读到。

装好之后，用一句需求描述就能让它从代码一直做到部署，例如：

生成的代码和模板上线前，仍要按下面的清单检查一遍，特别是鉴权方式（AuthType）、执行角色权限和 maxEnvironments。

4.5 上线前检查清单

五、价格对比：省在哪里，什么时候反而更贵

5.1 单价（us-east-1，Arm64）

Web Function 的 CPU 和内存都按 1 ms 粒度计费。按官方定价页的说明，内存按每个执行环境实际占用的量计费，覆盖环境存活的整段时间，包括请求之间的空闲时间；同一个环境里同时处理的请求分摊这部分费用。

不同 Region 的单价不一样。以东京 Region（ap-northeast-1）为例：和 us-east-1 相比，Web Function 贵约 16%，Fargate 贵约 25%，Event Function Arm 的单价一样。所以在东京，Web Function 相对 Event Function 的优势会小一点，相对 ECS Express Mode 的优势会大一点，后面的结论方向不变：

只看 CPU 单价，Web Function 让 1 个 vCPU 满负荷跑一小时约 $0.10，大约是 Fargate 的 2.5 倍。它便宜不是因为单价低，而是因为等待的时间不收 CPU 费，没流量时也不为闲着的资源付钱。

5.2 按请求类型：每百万次请求的计算费用

经验规则：Event Function 配 1 GB 内存时，只要一个请求的总耗时超过它实际用 CPU 时间的 2 倍左右，Web Function 就更便宜。大多数 Web API 都是这种情况。

5.3 按月请求量：三种方案的月成本

统一假设：Node.js API，每个请求用 50 ms CPU、等数据库 250 ms；流量均匀分布，每月按 730 小时算；不算免费额度和数据传输费用。Web Function 按每个执行环境实际占用 0.3 GB 内存、至少 1 个环境全月在线估算，结果偏保守。ECS Express Mode 每个 task 为 0.5 vCPU / 1 GB，至少 2 个 task，ALB 由这个服务独占。

画成图更直观（两轴都是对数刻度）：

[图 1：月成本随请求量变化]

拿月请求量 1 亿这一档拆开看，钱花在哪里一目了然：

[图 2：月请求量 1 亿时的费用构成]

• Event Function：96% 是计算费，基本都花在等数据库上。
• Web Function：大头是真正用掉的 CPU（$138），请求费（$30）占了约六分之一，内存只有 $6。
• ECS Express Mode：主要是 Fargate 的 vCPU 和内存，再加上 ALB 每月固定的约 $16。利用率从 50% 降到 25%，要的 task 数翻倍，总价也跟着从 $130 涨到 $240。

从表和图能看出三点：

1. 月请求量在 1000 万以内，Web Function 基本是最便宜的。ECS Express Mode 光是 ALB 加 2 个 task，每月就要约 $45。按 50% 利用率算，月请求量到约 2,600 万时 ECS Express Mode 才开始比 Web Function 便宜；按 25% 算，ECS Express Mode 在整个区间都比 Web Function 贵。
2. 和 ECS Express Mode 谁更便宜，看的是 CPU 利用率，不是请求量。Fargate 平均 CPU 利用率低于约 30% 时，Web Function 更便宜；稳定在 40% 以上时，ECS Express Mode 更便宜。实际生产里，很多 ECS 服务的平均 CPU 利用率只有 20%–30%。新应用很难提前知道利用率，可以参考同类服务在 CloudWatch 里的真实数据，别直接按 50% 估。
3. 每个请求用的 CPU 越少，ECS Express Mode 越占优。因为 Web Function 每百万次请求要收 $0.30，CPU 费用越低，请求费占的比例就越高。比如每个请求只用 10 ms CPU 时，盈亏点会降到约 19% 的 CPU 利用率。

5.4 账单里容易漏算的项目

• 日志存储：多 Region 部署时日志会存 N+1 份。不设保留期的话，日志费可能比计算费还高。
• 内存按执行环境存活时长计费：空闲的执行环境大约 5 分钟后才会被回收。如果流量很稀疏，每次请求都唤醒一个环境，内存费会比只按请求时长估的高。不过金额很小，每个环境每月最多几美元。
• 数据传输：Web Function 按标准 AWS 数据传输费率收费；函数和 VPC 之间的数据传输也按同 Region 数据传输的规则计费。访问 VPC 里的数据库而且流量大时，要把这部分算进去。
• 免费额度与 Savings Plans：Event Function 每月有 100 万次请求和 40 万 GB-s 的免费额度。目前 Web Function 暂无免费额度，Savings Plans 也未生效。ECS 可以用 Compute Savings Plans 或 Fargate Spot 进一步降低成本。
• 入口费用：Web Function 自带 endpoint，不用额外付入口费。需要自定义域名或 WAF 时，要在前面加 CloudFront，按 CloudFront 的标准价格计费。

六、已有应用的迁移

已有的 Node.js Web 应用也可以迁到 Web Function，但要先确认满足第二节的前提条件。不同来源的迁移重点如下：

非 Node.js 应用、依赖 x86 原生库的应用，以及部署在中国区的应用，在 Web Function 支持之前继续用现有方案。

七、总结

• 新建的 Node.js Web 或 API 项目，只要离用户最近的 Region 已经开放，可以优先考虑 Web Function。LLM 流式代理、BFF 和 SSR 这类大部分时间都在等的负载，省得最多。
• 月请求量上亿、负载平稳、CPU 利用率能稳定在 40% 以上的核心服务，用 ECS Express Mode 更划算。非 Node.js 语言、WebSocket、中国区部署这些 Web Function 暂时不支持的场景，选 ECS Express Mode 或 Event Function + LWA。
• 事件驱动的任务继续用 Event Function，和 Web Function 在同一个账号里配合使用。
• 已有应用要不要迁，先看前提条件，再对照第六节的差异和第五节的成本估算，不必为了迁而迁。

➡️ 下一步行动：

相关产品：

• AWS Lambda — 无需服务器即可运行代码
• Amazon ECS — 完全托管的容器编排服务
• Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
• Amazon API Gateway — 完全托管的 RESTful API 服务
• Amazon Fargate — 适用于容器的无服务器计算

相关文章：

• 宣布推出 AWS Lambda Web Functions
• 构建无服务器Kiro调度平台：用Kiro CLI + EventBridge + ECS Fargate实现定时AI任务
• 用 AWS Lambda MicroVMs 快速部署多人游戏服务器：让 Colyseus 实时服务”无服务器化”
• AWS 正式发布 Lambda MicroVMs：面向 AI 时代的无服务器安全代码执行环境
• AWS DevOps Agent × MCP Server：打通混合云网络排障的最后一公里

八、参考资料

• Lambda Web Functions Developer Guide
• Scaling behavior for Lambda Web Functions
• Lambda Web Functions logging
• AWS Lambda 定价
• Announcing AWS Lambda Web Functions（AWS News Blog）
• Exploring AWS Lambda Web Functions for building web applications（AWS Compute Blog）
• Amazon API Gateway now supports response streaming for REST APIs
• Agent setup guide（AWS Lambda Developer Guide）
• Agent Toolkit for AWS（GitHub）
• Some notes on Lambda Web Functions（Aidan Steele，社区实测：配额、日志、SIGTERM、空闲回收）
• Announcing Amazon ECS Express Mode
• AWS Lambda Web Adapter（GitHub）
• 使用 Lambda Web Adapter 在 Lambda 上构建 Web 应用（亚马逊 AWS 官方博客）

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用