Lambda Web Functions来了：空闲内存仍收费，端点默认公开

Express可以直接跑，先核语言和区域

AWS于2026年10月12日发布Lambda Web Functions：代码像普通HTTP服务器一样监听端口并处理请求。Express、Hono等Node.js框架无需Lambda专用适配器，适合API后端、服务端渲染网页、webhook和流式响应。这里的服务端渲染是收到请求后在服务器生成页面。

当前仅支持Node.js，不把Python、Java或.NET推定为同样可用。首发区域为US East (N. Virginia)、US East (Ohio)、US West (Oregon)、Asia Pacific (Tokyo)和Europe (Ireland)。后续区域变化以AWS当前区域能力和文档为准，不把海外读者默认限定在美国。

一个温热的执行环境可以同时服务多个请求。Lambda按流量管理环境并在无流量时缩减到零；请求重新到来可能等待环境初始化，不能把自动扩缩容理解成每个请求都没有冷启动。

等待200毫秒，只计50毫秒CPU也不是全部免费

Web Functions按请求数、活跃CPU时间、执行环境存续期间消耗的内存，以及标准AWS数据传输计费。计算资源以1毫秒为计量粒度；多个并发请求共享同一环境的CPU和内存，不应把每个请求的内存重复相加。

调用数据库或下游API时，等待阶段使用的CPU很少。但只要执行环境还存在，内存继续累积费用，包括两个请求之间的空闲时间。缩减到零会移除空闲环境，不能据此认定一次请求结束后所有费用立即停止。

AWS的官方假设例子是每月1000万请求，每次200毫秒，其中50毫秒为活跃CPU，环境使用约0.29GB内存。以Arm、美国北弗吉尼亚价格计算，CPU13.85美元、内存2.76美元、请求3美元，合计19.61美元。

这个例子假设流量均匀分布在30天、始终恰好一个环境运行，排除了免费额度和数据传输。它是官方演算，不是本站实测或你的报价；其他区域、架构、扩容数量、账户免费资格与传输费用应分别核算。

默认HTTPS链接公开，先选谁来鉴权

当前文档说明，aws lambda-web deploy默认创建ApplicationManaged端点。这个模式由应用实现登录与授权；Lambda不执行端点调用的IAM鉴权，也不以调用资源策略阻止访问。知道端点域名的人可以向它发起请求，应用仍可按自己的规则拒绝未授权业务操作。

需要AWS IAM控制调用时，部署参数明确选择--auth-type IamAuth，并核调用者权限及签名要求。IamAuth使用AWS签名请求验证身份；它不是应用登录的自动替代品。本文只说明配置选择，没有执行部署、修改IAM或调用真实端点。

在端点前加CloudFront可承接自定义域名或AWS WAF，但CloudFront本身不会隐藏原端点。ApplicationManaged原域名仍公开可达，不能靠调用资源策略把它限制为仅CloudFront访问。

若使用CloudFront Origin Access Control，也就是CloudFront向源站证明身份的机制，官方要求IamAuth、lambda源站类型、always-amz-auth签名行为及正确资源策略。还要核获准直接签名调用的主体，不能把有CloudFront分发当作源站已经私有。

接入CloudFront后，404、登录头丢失和403分别查哪里？

出现404时，先核源站请求策略是否转发了访问者的Host。Web Functions端点需要Host包含源站端点域名，而不是CloudFront分发域名。使用托管源站请求策略时，选择AllViewerExceptHostHeader，不要照搬AllViewer。

应用依赖Authorization登录头时，把它加入每个使用该源站的缓存行为所采用的缓存策略。GET和HEAD请求若未这样配置，CloudFront会在转发前移除Authorization；选了always-amz-auth也不能代替这项转发设置。

区域端点使用sigv4签名，全局端点使用sigv4a。全局端点关联的区域必须都是默认启用区域；若包含需要自行启用的opt-in区域，CloudFront无法为该区域签名，源站会返回403。不要把多区域支持理解成任意区域组合都适用OAC。

新配置还需等待CloudFront分发部署完成；多区域端点的资源策略也要完成各区域复制。在这两个过程结束前，部分请求可能暂时收到403。官方没有给出固定等待时长，应核部署与策略传播状态，不承诺等待几分钟就一定恢复。

已有Lambda@Edge源站请求或源站响应触发器时，先检查兼容性。使用Lambda Web Function加OAC的缓存行为不能同时配置这些触发器，CloudFront会拒绝该组合；限制覆盖区域和全局端点，以及直接源站或源站组方式。以上是建议配置检查，本站未执行部署或真实端点测试。

现有Lambda需要迁移吗？先按任务类型选择

AWS同时把现有Lambda函数改称Lambda Event Functions。公告明确这是名称变化，不要求现有函数修改代码或重新部署。队列消息、文件上传等事件处理仍应按Event Functions的使用方式选择，不因新名称就改写运行中的流程。

Web Functions面向直接收到HTTP请求的应用。代码以.zip文件部署，Lambda创建HTTPS端点，并用不可变的revision保存代码与配置；端点可把流量路由到一个或两个revision。读者应按当前创建与部署指南准备应用和权限，而不是照搬旧函数的事件处理入口。

如果现有Express API主要等待数据库响应，可以把活跃CPU、环境内存存续时间、请求量和传输量放进同一份成本估算，再评估是否试点。这是尚未执行的评估场景，不能仅凭CPU计费方式保证一定比原方案便宜。

能流式返回，不等于所有HTTP协议都兼容

Web Functions可把响应逐步流式发送给客户端，适合增量返回模型输出。当前HTTP指南明确端点接收并转发HTTP/1.1请求，HTTP/1.0会返回505；支持GET、HEAD、POST、PUT、PATCH、OPTIONS和DELETE。

请求行、请求头和结尾空行合计上限为128KiB，超过时返回431。这是头部范围，不是请求体大小；这里尚不能给出请求体大小、运行时长和全部配额，应在当前完整指南核对，不照搬其他函数类型的限制。

端点会移除Upgrade、Connection及Proxy-Authorization等部分头部。原生HTTP流式响应不能据此推定WebSocket升级、任意代理协议或SOCKS连接受支持；依赖这些行为的应用应先查对应协议文档，再做隔离验证。

试点前，按三步确认适用性

第一步，在AWS当前文档核语言、目标区域、权限与应用监听方式。选择已获授权的隔离环境和非敏感样例；先确认Web Functions适合直接HTTP请求，保留原有服务的恢复路径。

第二步，在任何部署前明确端点鉴权模式。如果采用ApplicationManaged，检查应用自己的认证；如果采用IamAuth或CloudFront OAC，按完整官方指南核签名及策略，而不是只看到HTTPS就认定访问受保护。

第三步，把预计活跃CPU、环境内存与存续时间、请求数、扩容和数据传输一起估算。若后续执行试点，分别核已授权请求、未授权请求、响应流及账单观察结果；保存脱敏证据，避免记录凭据或私人请求内容。以上是建议流程，本站没有执行云账户操作或性能实测。