云账单：210 美元的去处与每千次请求 0.42

账单不按你的努力收费，按你用掉的量收费。

一、请求涨了 24%，账单降了 44%

九月，沈牧给任务板加了导出预览和两个设置页面。月底一看用量，请求从 50 万涨到 62 万，涨了 24%。他按旧单价估了一下：620 × 0.42 ≈ 260 美元，准备接受这个涨幅。

账单出来是 118 美元。他先怀疑统计错了，又怀疑是不是少收了钱，最后把两天的日志对了一遍，才确认这是真的：同样的功能，请求更多，钱更少。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

请求数不是成本的唯一驱动量。 账单由五项组成，每项背后是另一个量：CPU 时间、查询次数、存储容量、出站字节、日志条数。只盯请求数，会同时误判涨和跌。

单看总额看不出发生了什么。 210 降到 118 可以是「用量减半」，也可以是「单价减半」；两者的可持续性完全不同。要判断，必须先把金额换算成单位成本。

沈牧后来把每月数字记在一张表里：请求数、五项金额、每千次成本。三个月后，这张表比任何仪表盘都更早告诉他哪一项在变贵，因为金额会波动，单位成本不会说谎。

二、210 美元的五项分解

这是改前的账单。五项金额相加正好 210，每一项都能追到一个可测量的驱动量。

出站可以自己算出来。 50 万次请求 × 平均 700 KB = 350,000,000 KB = 350 GB；32 美元对应 350 GB，说明这一项几乎完全由传输体积决定，而不是请求数。

计算占比最高，但它最不该先动。 96 美元是「CPU 时间 × 请求数」的结果；在不知道单请求 CPU 时间之前调规格，只是把同一份浪费换到更小的机器上。

数据库的 54 美元里，大头不是容量。 项目列表一次加载 1,200 次查询，慢查询把 CPU 打满；这一项的成本由查询次数驱动，和存了多少行关系不大。

「其它」最容易变成黑洞。 10 美元看着小，但日志与监控会随请求数线性增长；62 万请求时如果不采样，它会自己涨到 12 美元以上。

每千次请求成本是可比的唯一口径。 210 ÷ 500 = 0.42 美元，这个数字把金额和用量绑在一起，跨月比较才有意义。

占比不是优先级。 计算占 45.7% 最大，但它由前几篇的首屏与查询优化间接决定；先动它，等于在结果上改数字。按「驱动量是否可直接改变」排序，通常先动查询、传输与保留期。

三、降在哪五项

账单下降不是靠砍功能，而是靠让同样的请求变轻、让同样的字节少走一程。五项各自的原因如下。

计算降一半，靠的是「每请求更轻」。 静态资源改由 CDN 承担后，源站不再为每个页面返回 412 KB；导出改成异步后，请求线程不再等 34 秒。同一批请求，CPU 时间少了，实例才有下调的空间。

数据库的 42 美元没有换机器。 三个索引把列表页的查询次数从 1,200 降到 3，慢查询归零；成本下降来自次数，不来自容量。数据一行没删。

存储的 12 美元是生命周期规则。 导出文件 90 天保留意味着三份历史副本常驻；改成 30 天后，常驻容量少三分之一。这里要确认业务确实不再需要 90 天前的导出。

出站从 350 GB 降到 118 GB。 62 万 × 190 KB = 117,800,000 KB ≈ 118 GB；体积降 66.3%，金额降 62.5%，差额来自缓存命中后仍有一部分回源流量。

「其它」靠采样与保留期。 日志采样一半、保留从 90 天缩到 30 天，监控规则从四十条收敛到十二条；10 美元降到 4 美元，且没有丢掉任何一次真实故障的定位能力。

五项里没有一项靠「换更便宜的供应商」。 全部是同一套服务、同样的请求量下，把浪费去掉；这也是为什么涨幅没有传导到账单。

五项之间有耦合，别重复计功。 缓存既降低出站，也降低源站计算；查询优化既降数据库，也降 CPU。写复盘时把收益归到主因那一项，否则五项加起来会超过 92 美元。

四、0.42 到 0.19、年省 1,104 与 27.6

把金额除以用量，才能看清这个月到底发生了什么。

改前每千次请求 210 ÷ 500 = 0.42 美元；改后 118 ÷ 620 = 0.19 美元。单价降了 54.8%，而请求量涨了 24%，两个方向相反，才出现「用得更多、付得更少」。

复算：
改前账单 = 96 + 54 + 18 + 32 + 10 = 210
改后账单 = 48 + 42 + 12 + 12 + 4 = 118
月省 = 210 − 118 = 92；降幅 92 ÷ 210 = 43.8%
请求 = 500,000 → 620,000；620 ÷ 500 = 1.24（+24%）
改前每千次 = 210 ÷ 500 = 0.42
改后每千次 = 118 ÷ 620 = 0.19；单价降幅 (0.42 − 0.19) ÷ 0.42 = 54.8%
改前出站 = 500,000 × 700 KB = 350,000,000 KB = 350 GB
改后出站 = 620,000 × 190 KB = 117,800,000 KB ≈ 118 GB
年省 = 92 × 12 = 1,104
时薪门槛 = 1,104 ÷ 40 = 27.6；本篇 3 h 占 40 h 的 7.5%

1,104 是按请求量不变算的下限。 如果按旧单价推算，62 万请求本应花 620 × 0.42 = 260.4 美元；实际 118，单月差额 142.4。但把 142.4 年化会高估收益，因为它把新增请求也算成了节省；保守起见，只报 92 × 12。

27.6 美元/小时是整组工作的门槛。 40 小时换 1,104 美元，等于每小时 27.6；如果同样的时间拿去做别的能赚更多，这件事在经济上就不划算。它不衡量快慢，只回答「值不值得动手」。

本篇只占 3 小时。 账单治理是九项工作里最便宜的一项：查用量、算单位成本、改保留期与缓存，一次做完；真正的节省来自前面几篇把请求变轻。

混合单价会掩盖分项。 0.19 是 62 万次请求的平均值，新增的导出预览请求可能比普通页面更贵；如果预览占比继续上升，平均单价会在总账单不变的情况下慢慢变差。每月按路径再拆一次，才不会把结构变化误读成效率提升。

五、行动清单与复算验收

账单治理一个月做一次，二十分钟能看完；真正花时间的是第一次把五个驱动量找出来。

• 导出最近三个月账单，按计算、数据库、存储、出站、其它五项归类。
• 给每项写出驱动量：CPU 时间、查询次数、GB、日志条数，不只记金额。
• 算出每千次请求成本，作为跨月比较的唯一口径。
• 找出传输体积最大的三项资源，检查压缩与缓存头。
• 检查关键页面的查询次数，把随行数增长的 N+1 降到常数。
• 给对象存储设保留期，清理过期导出与历史大图。
• 给日志与监控设采样率与保留期，别让「其它」随手涨。
• 用同一请求量假设复算年省，并写下时薪门槛。

验收标准：你能用五项金额、五个驱动量与每千次请求成本解释本月账单，并在请求量变化 20% 时判断出是效率变了还是用量变了。

使用边界与实操验收

本文只讨论同样请求量下的效率与单价，不讨论什么时候该扩容、连接池开多大、要不要买预留实例。

扩容与容量水位不归本文。 那些问题属于运维专题的《容量与成本》；本文假设容量已经够用，只问同一批请求为什么更贵。

不写厂商报价。 文中所有金额都是教学假设，用来演示五项结构与单位成本算法，不对应任何一家云厂商的实际价格。

税务与会计口径不归本文。 预付费、摊销与抵扣属于财务专题；本文只看月度用量与金额。

免费额度会掩盖真实单价。 早期账单低，可能只是还没超过免费额度；用免费期数据算单位成本，会得出过于乐观的结论。

出站与缓存强相关。 传输体积下降多少能换成金额，取决于缓存命中与回源比例；具体缓存层设计见本组《缓存：三层、86% 命中与一次 11 分钟的旧数据》。

降本不能拿可靠性换。 缩短日志保留、降低采样率之前，先确认还能定位一次真实故障；省下的 6 美元不值得丢掉一次复盘能力。

请求数与传输量要同口径。 是否包含静态资源、是否包含预览接口，会让 50 万这个分母差出两三成；口径定下后，至少保持一年。

关键参考与核验范围

• FinOps Framework ：用于核对按用量归集成本与单位成本的一般做法。
• AWS Well-Architected 成本优化支柱 ：用于核对「先理解用量再优化」的顺序。
• MDN HTTP Compression ：用于核对传输体积与压缩对出站的影响。
• Cloudflare Cache ：用于核对缓存命中与回源流量之间的关系。

以上链接于 2026-10-26 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-26。

范围上只讨论五项账单结构、单位成本与同请求量下的效率改进，不讨论扩容顺序、实例选型与商务折扣。

系列导航

• 上一篇：第三方脚本：七个标签、640 KB 与一次被拖慢的登录
• 下一篇：性能回归与门禁：一次发布后 p95 从 320 到 980
• 回到目录：一个人的性能与账单：4.2 秒的首屏、一千二百次查询与每月 210 美元
• 相关阅读：容量与成本：先找瓶颈，再谈扩容