2. 请求计费模型：深入解析Lambda、API Gateway等服务的请求次数与持续时间计费
好，咱们进入第二个核心话题。很多刚接触无服务器的朋友，一看账单就懵了——明明没跑几个请求，怎么钱就花出去了？
说白了，无服务器计费就两把刀：请求次数和执行时间。这两把刀怎么砍，砍多深，今天咱们掰开揉碎了讲清楚。
2.1 Lambda 计费：请求次数 + 持续时间 + 配置内存
Lambda 的计费模型，我习惯把它拆成三个维度：
- 请求次数：每调用一次，算一次。每月前 100 万次免费，超出后按每百万次 0.20 美元计费。
- 持续时间：从代码开始执行到返回结果，按毫秒计费。计费粒度是 1 毫秒，但最低收费 100 毫秒。
- 配置内存：你给函数分配了多少内存，决定了每秒的单价。内存越大，单价越高。
嗯，这里要注意：持续时间不是按秒算的，是按毫秒算的。我见过不少团队，以为 Lambda 按秒计费，结果优化时只盯着秒级，忽略了毫秒级的优化空间。
核心公式：
单次调用费用 = 请求次数费用 + (执行时间(毫秒) × 内存单价)
其中，内存单价 = 0.0000166667 美元/GB-秒 × (配置内存 / 1024)
2.2 实际案例：一个 128MB 的函数跑 200ms
咱们算一笔账。假设你配了 128MB 内存，每次执行 200ms：
- 单次持续时间费用 = 0.0000166667 × (128/1024) × (200/1000) ≈ 0.0000004167 美元
- 加上请求次数费用（假设已超免费额度）：0.0000002 美元/次
- 单次总费用 ≈ 0.0000006167 美元
看起来便宜得离谱对吧？但别忘了，量变引起质变。我在项目中遇到过，一个日活 10 万的 API，每个请求触发 3 次 Lambda 调用，一个月下来光 Lambda 就烧掉 500 多美元。你想想看，如果每个请求多跑 100ms，成本直接翻倍。
我的优化建议：
别盲目追求低内存。128MB 跑 500ms 和 512MB 跑 100ms，哪个更省钱？我建议你实际测一下。有时候多分配点内存，执行时间缩短了，总费用反而更低。
2.3 API Gateway 计费：请求次数 + 数据传输 + 缓存
API Gateway 的计费模型，比 Lambda 多了一个维度——数据传输。
| 计费项 | 说明 | 免费额度 | 超出后单价 |
|---|---|---|---|
| 请求次数 | 每收到一个 HTTP 请求算一次 | 每月 100 万次 | 每百万次 3.50 美元（REST API） |
| 数据传输 | 响应体大小，按 GB 计费 | 每月 1 GB | 每 GB 0.09 美元 |
| 缓存 | 可选，按缓存大小和时长计费 | 无 | 0.02 美元/小时起 |
这里有个坑，我踩过。API Gateway 的请求次数计费，是按实际接收到的请求数算的，不是按成功响应的请求数。也就是说，客户端发了个请求，你返回 500 错误，这笔钱照样扣。
我曾经...遇到过一个问题：
一个客户端写了个死循环，每秒发 1000 个请求到 API Gateway。虽然 Lambda 那边因为限流没怎么执行，但 API Gateway 的请求次数账单直接爆了。后来我加了 WAF 和请求频率限制，才把这个问题控制住。
2.4 持续时间计费的隐藏成本
持续时间计费，不只是 Lambda 有。API Gateway 也有一个容易被忽略的点——响应超时时间。
API Gateway 默认超时是 29 秒。如果你的 Lambda 函数执行时间超过 29 秒，API Gateway 会断开连接，但 Lambda 还会继续跑。这意味着：
- API Gateway 收了请求费，但没返回结果
- Lambda 收了执行费，但结果没人要
说白了，两边都收了钱，但用户啥也没得到。我建议你把 API Gateway 的超时时间设短一点，比如 10 秒。如果业务确实需要长时间处理，改用异步调用。
2.5 实战：如何预估你的账单
我习惯用这个公式快速估算：
月费用 ≈ (请求次数 × 单次请求费用) + (总执行时间(秒) × 内存单价)举个例子：
- 假设每天 10 万次请求，每月 300 万次
- 每次请求触发 1 次 Lambda，执行时间 300ms，内存 256MB
- Lambda 费用 = (300万 - 100万) × 0.0000002 + (300万 × 0.3秒) × (0.0000166667 × 256/1024)
- ≈ 0.4 美元 + 0.96 美元 ≈ 1.36 美元
- API Gateway 费用 = (300万 - 100万) × 0.0000035 ≈ 7 美元
- 总费用 ≈ 8.36 美元/月
你看，API Gateway 的费用反而比 Lambda 高。这就是为什么我总说：别只盯着 Lambda 优化，API Gateway 的请求次数可能才是大头。
我的个人习惯：
每个月第一天，我会用这个公式快速算一遍。如果发现某个服务的费用占比异常，就深入排查。比如有一次我发现 API Gateway 费用突然涨了 3 倍，一查发现是某个客户端没做缓存，重复请求太多。
2.6 避坑指南：这些细节别忽略
- 免费额度是共享的：Lambda 和 API Gateway 的免费额度是按 AWS 账号算的，不是按函数或 API 算的。如果你有多个函数，共享那 100 万次免费请求。
- 冷启动也计费：冷启动的时间会计入持续时间。虽然时间不长，但如果你的函数频繁冷启动，积少成多也是一笔钱。
- 响应体大小影响数据传输费：API Gateway 的数据传输费是按响应体大小算的。如果你返回一个 1MB 的 JSON，每次请求都要付 0.00009 美元的数据传输费。我建议你压缩响应体，或者用分页。
- 预留并发不额外收费：Lambda 的预留并发只保证有足够的实例，不会额外收费。但如果你设置了预留并发，却没有用完，那部分资源就浪费了。
嗯，关于请求计费模型，今天就聊这么多。下一章咱们聊聊存储和数据库的成本控制，那又是一个容易踩坑的地方。