Lambda 冷启动又快了，默认并发也提了：这次不用改代码

之前为了避免 Lambda 冷启动，我给 API 后端的函数配了 Provisioned Concurrency。效果确实好，但每月多出一笔固定费用——哪怕凌晨没流量也在烧钱。这次 AWS 直接从平台层优化了冷启动，不用改配置，自动生效。

两个变化

亮马逊云科技 5 月更新了 Lambda 两个关键能力：

1. 冷启动时间缩短

Python 3.12、Node.js 22、Java 21（SnapStart）的冷启动初始化时间改善。自动生效，不需要改代码或配置。

2. 默认并发限制提升

新账号的默认并发执行上限提升。老账号不需要再频繁提交 Service Limit Increase 请求。

实际影响

场景 1：API 后端

之前：为了保证 P99 延迟，配 Provisioned Concurrency = 50。
现在：冷启动本身变快了，可能只需要 Provisioned Concurrency = 20 甚至 0。

省多少钱？ 取决于你的流量曲线。如果高峰只占一天的 30%，剩下 70% 的 Provisioned Concurrency 费用就是浪费。去掉后这笔费用直接归零。

场景 2：事件驱动架构

之前：流量窀然飙升时撞到并发限制，请求被 throttle。要么提前申请限额提升，要么接受丢失。
现在：默认限制更高，中小团队大概率不用再手动申请。

场景 3：Java SnapStart

Java 冷启动一直是老大难（动辄 3-5 秒）。SnapStart 本身就解决了大部分问题，这次进一步优化了 SnapStart 的恢复速度。

怎么验证

# 查看当前并发限制
aws lambda get-account-settings --query 'AccountLimit.ConcurrentExecutions'

# 查看函数的 Provisioned Concurrency 配置
aws lambda list-provisioned-concurrency-configs \
  --function-name my-api-handler

# 测试冷启动时间（强制冶启动：改个环境变量）
aws lambda update-function-configuration \
  --function-name my-api-handler \
  --environment "Variables={FORCE_COLD=$(date +%s)}"

# 然后 invoke 看 Init Duration
aws lambda invoke --function-name my-api-handler \
  --log-type Tail output.json \
  --query 'LogResult' | base64 -d | grep "Init Duration"

建议操作

1. 检查 Provisioned Concurrency — 如果你配 PC 主要是为了避冷启动（而不是保证吞吐），试着降到 0 看延迟变化
2. 检查并发限额 — 看看新的默认值是否已经够用，可能不再需要手动申请
3. Java 项目评估 SnapStart — 如果还在用 Java 但没开 SnapStart，这是个好时机

不变的

• 函数代码层面的初始化逻辑（import、连接池建立）该优化还得优化
• 大依赖包（几百 MB 的 ML 模型）冷启动还是会慢
• Provisioned Concurrency 对于需要绝对零冷启动的场景仍然有价值

来源：亮马逊云科技 2026 年 5 月 Lambda 服务更新