AWS Lambda Web Functions 实测：Next.js 部署能否替代 Amplify？

AWS 近期发布了 Lambda Web Functions，试图为 Web 应用提供更直接、更高效的托管方式。一位长期与 Amplify 缠斗的开发者用同一个 Next.js 应用在两者上做了对比测试，结果颇具参考价值。

为什么 Web Functions 值得关注

传统 Lambda（AWS 现在称之为 Lambda Event Functions）接收事件、返回响应，而标准 Next.js 生产服务器监听 HTTP 端口、持续服务请求——两者模型并不匹配。Lambda Web Functions 直接运行一个 HTTP 服务器，应用监听 Lambda 提供的主机和端口，AWS 负责 HTTPS 端点、执行环境和扩缩容。没有 API Gateway 伪装 HTTP 请求，也不需要框架专属适配器。

更关键的变化在并发模型上。一个预热后的 Web Function 可以同时服务多个请求，而非传统 Event Function 的单次单并发调用。AWS 文档显示每个环境最高可支持 128 个并发请求，实际并发动态管理。这对需要等待数据库或其他 AWS 服务的 Web 应用来说很有价值。计费模型也相应调整：Web Functions 按活跃 CPU 时间计费，等待 I/O 期间 CPU 消耗低，内存仍按环境生命周期计费。

此外，Web Functions 支持原生响应流式传输，启动时提供 Node.js 24 on Arm64，并附带不可变修订版本、流量路由端点以及可选的多区域路由。

Lambda 的并发模型经历了重要演变。传统 Lambda 每个实例一次只处理一个请求，若并发量高，AWS 需启动大量实例，导致冷启动频繁、资源利用率低。Web Functions 引入了“每环境多并发”机制——单个执行环境可同时处理最多 128 个请求，由 AWS 在环境内动态调度。这类似于 Node.js 的事件循环：当某个请求等待 I/O（如数据库查询）时，CPU 可切换去处理其他请求。这种模型更贴近典型 Web 服务器的行为，能显著降低等待时间，但需要应用代码是并发安全的，避免依赖全局可变状态。

实测设计：一个应用，两种部署

作者用 AI 构建了一个名为 Fin & Feast 的虚构外卖应用，使用 Next.js 15、TypeScript 和 App Router。首页动态渲染并读取请求信息，菜品页静态生成，结账流程通过 /api/orders 在服务端校验购物车并计算价格，订单确认页使用签名的 HttpOnly cookie 做个性化。首页可用性面板和订单进度面板放在 React Suspense 边界后，并刻意加入约 1 秒延迟，以区分“流式输出页面片段”和“等全部就绪再输出”。

两套部署都用 Terraform 管理。Amplify 方案连接 GitHub 仓库，由 AWS 构建并托管，内含 CloudFront 分发。Web Functions 方案则需自行处理：在 Linux Arm64 构建容器中以 standalone 模式构建 Next.js，打包成 ZIP 上传 S3，Terraform 创建指向特定对象版本的 Web Function 修订，并将 HTTPS 端点指向该修订。

测试用 Playwright 驱动相同流程：加载动态首页并等待可用性、打开静态菜品页、通过 Next.js 预取导航、加入购物车、结账、刷新个性化订单页。主运行包含 1600 次测量旅程和 800 次预热旅程，交替平台顺序以减少偏差。

测试结果：静态交付 vs 动态渲染

指标	Amplify 中位数	Web Functions 中位数	Amplify p95	Web Functions p95
首页首字节	1803 ms	297 ms	1893 ms	369 ms
静态菜品页首字节	43 ms	288 ms	108 ms	355 ms
预取导航到菜品页	44 ms	44 ms	60 ms	60 ms
结账到订单摘要可见	1582 ms	244 ms	1684 ms	296 ms
直接刷新订单页到摘要可见	1410 ms	121 ms	1524 ms	171 ms
订单刷新摘要到进度间隔	24 ms	1192 ms	25 ms	1288 ms

静态菜品页 Amplify 仅 43 ms，远快于 Web Functions 的 288 ms，作者认为这主要归功于 Amplify 内置的 CloudFront CDN。重复浏览器测试中该静态页 Amplify 约 16 ms，Web Functions 约 96 ms。这证明 CDN 确实有用——大概不算意外。

真正拉开差距的是需要服务端计算的页面。结账后 Web Functions 展示订单摘要和进度页的速度反复快于 Amplify。直接刷新订单页时 Web Functions 摘要出现更快，但摘要到进度组件的间隔达 1192 ms，而 Amplify 仅 24 ms——后者意味着两块内容一起到达，但用户等待首个有用字节的时间长得多。这与 Web Functions 流式响应的行为一致，也吻合 AWS 文档中 Amplify 不支持 Next.js streaming 的说明。

作者的同事认为主要差异可能来自 Web Functions 的并行请求模型，类似 Vercel 为降低托管成本、提升响应速度所实现的方案：一个 Lambda 实例连接路由层并处理多个请求。他怀疑 Amplify 仍是每个请求一个 Lambda 实例，导致大量冷启动。预取导航在两端均为 44 ms，说明这一路径由浏览器而非托管环境决定。

流式响应（Streaming）是 React 18 和 Next.js App Router 的核心特性。它允许服务器先发送页面外壳和已就绪的静态部分，再通过 HTTP 分块传输逐步发送 Suspense 边界后的动态内容。浏览器可边接收边渲染，用户无需等待全部数据准备完毕就能看到部分内容，从而改善感知性能。在测试中，Web Functions 订单页摘要到进度组件的间隔长达 1192 ms，正是因为摘要先被流式发送，而进度数据仍在异步加载。Amplify 不支持流式传输，因此它会等待所有组件数据就绪后一次性发送，导致首个有用字节出现时间更晚，但各组件看起来是同时出现的。

流式传输与 CDN 的取舍

Amplify 的优势集中在静态交付和内置 CDN 上，Web Functions 的优势集中在动态服务端渲染和流式传输上。作者坦言，Web Functions 未附带 CloudFront 分发，他本次也没有部署，事后觉得或许应该加上。AWS 支持将 Web Functions 作为 CloudFront 源，包括源访问控制，因此补上 CDN 是几分钟的事。

另一个值得注意的细节是，Amplify 的环境变量不会自动对 Next.js 服务端组件可见，必须在构建时显式写入，这是 Amplify 专属的额外心智负担。此外 Amplify 的 Next.js 支持文档列出支持至 Next.js 15，但明确排除流式传输和按需 ISR。

按需 ISR（Incremental Static Regeneration）允许 Next.js 在运行时按需重新生成静态页面：当请求到达时，若缓存已过期，服务器会在后台重新生成页面并更新缓存，同时立即返回旧版本。这与传统的构建时静态生成不同，更适合内容频繁更新但访问量大的场景。Amplify 文档明确表示不支持该特性，主要是因为其托管模型在接收到请求时无法触发 Next.js 的重新验证逻辑。若应用依赖按需 ISR，迁移到 Lambda Web Functions 或其他支持完整 Next.js 服务器功能的平台会是更稳妥的选择。

能否告别 Amplify？

作者的态度比实验前更倾向于迁移。Web Functions 直接运行 Next.js standalone 服务器，不试图用另一套托管模型重新解释框架。构建部署更简单，Terraform 描述清晰，修订版本指向特定版本化产物。加上 CloudFront 只是几分钟工作。

代价是原本 Amplify 帮你处理的 CDN、构建托管、环境集成都变成自己的责任。对于追求可预测性和流式能力的团队，这笔交换可能值得；对于只想点几下就跑起来的小团队，Amplify 的托管包装仍有价值。应用代码、Terraform 和 Playwright 基准测试脚本都已开源，可以自行复现。