5.6 云成本结构
一句话
云账单不是 “用了多少台机器”，而是四类计费维度的乘积——计算（规格 × 时长）、存储（容量 × 时长 + 请求数）、网络（出口 + 跨区）、请求与许可（次数 × 单价）；优化顺序永远是先关闲置、再调规格、后买承诺折扣，最后才动架构。
四类计费维度：先知道钱花在哪
| 维度 | 计量单位 | 随什么增长 | 典型占比 | 优化杠杆 |
|---|---|---|---|---|
| 计算 | vCPU·小时 / 实例·小时 | 实例数 × 规格 × 运行时长 | 30%–50% | 规格降配、预留、Spot、闲置关停 |
| 存储 | GB·月 + 请求数 | 数据量 + 访问次数 | 10%–25% | 分层、生命周期、压缩、快照清理 |
| 网络 | GB（出口 / 跨区 / 跨 AZ） | 出网流量 + 副本同步 | 5%–30%（差异极大） | CDN、同区闭环、压缩、边缘缓存 |
| 请求与许可 | 万次请求 / 席位 | 调用次数、日志摄取量、许可证 | 5%–20% | 采样、批量、协议优化 |
占比差异极大的原因是业务形态：视频类出口费可能是计算费的 2 倍；日志密集型业务里 “指标与日志摄取” 常常是第二大项。判断自己的成本结构，唯一可靠的方法是按服务维度拆一次账单（标签 + 成本分配），而不是凭直觉。
三条最容易被忽略的账
| 项 | 为什么会漏 | 量级与修法 |
|---|---|---|
| 出口流量（egress） | 潜意识里以为 “网络免费” | 出公网按 GB 计费，跨地域专线另算；用 CDN 回源 + 压缩 + 边缘缓存压低 |
| 跨 AZ 流量 | 多 AZ 架构的 “固定税”，账单里是单独一行 | 每 GB 一分钱量级；靠同 AZ 优先路由减少 |
| 请求费 | S3/对象存储、API 网关、日志摄取都按请求或按量收费 | 百万次请求起跳；批量合并、采样、TTL |
一个具体例子：跨 AZ 的日志双写。每 GB 日志写两遍、查三遍，账单里可能出现 “存储费 < 请求费 < 跨区流量费” 的倒挂——这时最有效的优化不是换存储类型，而是把日志留在本 AZ、只跨区同步聚合指标。
闲置与影子成本清单
这些项金额不大但数量多，是 “没人认领的钱”：
| 影子成本 | 常见规模 | 处理 |
|---|---|---|
| 未挂载的云盘 | 每账号几十块，合计可观 | 按月扫描 available 状态的卷 |
| 旧快照与镜像 | 越滚越多，且按容量计费 | 设保留策略（如 30 天 + 每月 1 个全量） |
| 未绑定的 EIP | 闲置 IP 也收费 | 回收进池 |
| 空闲负载均衡 / NAT 网关 | 按小时计费，即使零流量 | 测试环境按需创建 |
| 无人用的测试环境 | 常年开机 | 定时开关机（工作时间外停机省 60%+） |
| 日志保留 90 天但只查 7 天 | 存储费线性增长 | 热 7 天 + 冷归档 90 天 |
四种购买形态：把 “确定性” 折价买回来
| 形态 | 折扣量级 | 承诺 | 适合 |
|---|---|---|---|
| 按需 | 基准价 | 无 | 不可预测峰值、短期项目 |
| 预留实例 / 节省计划（1 年） | 省 30%–40% | 1 年 | 稳定基线 |
| 预留（3 年） | 省 50%–60% | 3 年 | 长期确定的核心负载 |
| Spot / 抢占 | 省 60%–90% | 无，可中断 | 批处理、CI、无状态可重试 |
折扣的具体数字随厂商、地域、付款方式（全预付 / 部分预付 / 无预付）变化，引用时必须说明 “以报价为准”。真正的方法论只有一条：把负载分成 “确定的基线” 与 “不确定的峰值”，基线买承诺、峰值买按需、可中断的买 Spot。基线的估计方法见 57.3 冗余系数。
单位经济：把账单变成可比较的数
账单总额无法判断 “贵不贵”，因为业务量也在涨。可比的指标是单位成本：
每订单成本 = 当月总成本 / 当月订单数
每租户成本 = 当月总成本 / 活跃租户数
每 GB 处理成本 = 当月数据链路成本 / 当月处理字节数
| 现象 | 含义 | 动作 |
|---|---|---|
| 账单涨 30%，单位成本不变 | 业务量涨了，健康 | 不用动 |
| 账单不变，单位成本涨 20% | 效率在退化（冗余、闲置、架构劣化） | 查闲置与规格 |
| 单位成本随规模下降后走平 | 到了当前架构的规模拐点 | 考虑架构调整（分片、缓存、存储分层） |
单位成本的完整算法与折现口径见 4.2 成本-收益分析；存储层的分级策略见 39.3 存储分级。
优化顺序：按 “每投入 1 人日省多少钱” 排
| 顺序 | 动作 | 典型回报 | 风险 |
|---|---|---|---|
| ① | 关停闲置、回收未挂载资源 | 立竿见影，1 人日可省 5%–15% | 几乎为零 |
| ② | 规格降配（rightsizing） | 10%–30%，按实际 P95 用量 | 需留 30% 余量，避免打满 |
| ③ | 承诺折扣（预留 / 节省计划） | 20%–50%，无技术风险 | 承诺期绑定，需预测基线 |
| ④ | 存储分层与生命周期 | 存储费降 40%–70% | 取回延迟与请求费上升 |
| ⑤ | 架构调整（缓存、合并、单元化） | 幅度大但周期长 | 引入复杂度，需 ADR 记录 |
顺序的意义是先摘低垂果实：架构级优化往往要 1–3 个月，而第①步一天就能省出同等金额。反过来先上架构，会把 “闲置资源” 和 “架构低效” 混在一起，最后归因不清。FinOps 的组织化做法（成本分摊、预算、例会）见 57.4 FinOps 实践。
反模式
| 反模式 | 后果 |
|---|---|
| 不看账单，只看控制台估算 | 实际支出常是估算的 1.5–3 倍 |
| 只优化计算，不看出口流量 | 视频 / 下载类业务优化方向完全错 |
| 为省钱把副本挤到同一 AZ | 省下的流量费远小于一次故障损失 |
| 预留买到峰值的 100% | 业务下坡时承诺变成沉没成本 |
| 没有标签与成本分摊 | 没人认领的钱永远没人优化 |
| 用 “总账单” 判断成本效率 | 业务增长被误读为成本失控 |
| 过度 rightsizing 打满 CPU | 延迟长尾恶化，稳定性换成本 |
| 先做架构优化再关闲置 | 浪费 1–3 个月，且效果被闲置掩盖 |
三条铁律
🔑 账单要按服务拆开看；拆不开的成本，既不能优化也不能归因。
🔑 单位成本是唯一可比的成本指标；总额只反映规模，不反映效率。
🔑 优化顺序：闲置 → 规格 → 承诺 → 架构；先摘低垂果实，再动结构。
自检
Q1 一个服务的账单三个月涨了 40%，但业务量只涨了 10%。先查哪三项？
▸ 答案：① 单位成本（账单 ÷ 业务量），确认是效率退化而不是统计口径变化；② 出口/跨区流量（这类费用常在一个架构变更后突增，比如把缓存与数据库分到了不同 AZ）；③ 闲置与影子成本（新开的测试环境、未回收的云盘与快照）。先排除 “新增了什么” 再谈优化，否则会把业务增长当成浪费砍掉。
Q2 为什么 “把预留买到 100% 的峰值” 是危险的？
▸ 答案：因为预留是按承诺期付费，而峰值只出现在少数时段。买到峰值意味着：① 大部分时间你为闲置容量付钱；② 业务下坡或架构调整时，承诺无法退回，变成沉没成本。正确做法是基线（常态负载的 60%–70%）买预留，峰值买按需，可中断的买 Spot，把确定性折价买回来，把不确定性留给弹性。
Q3 团队把日志从 90 天改成 7 天，省了 40% 存储费，但第二个月总成本反而涨了。可能是什么原因？
▸ 答案：取回与查询成本转移。冷归档存储的读请求与检索（扫描）单价远高于热存储；如果团队为了排障频繁回捞历史日志，或把日志改成了 “按查询计费” 的模式，省下的容量费会被请求费吃掉。判断方法是按 “容量费 / 请求费 / 取回费” 三项分开看，而不是只看存储总额。
Q4 一个视频业务的成本里，出口流量占 60%。优化顺序应该怎么排？
▸ 答案：先动流量结构，再动计算：① CDN 命中率（回源量决定出口费）；② 编码与封装（同画质码率降 20%–30%）；③ 缓存键与 TTL（减少重复回源）；④ 最后才看转码机器的规格。计算优化在这类业务里通常只能动 30% 的盘子，而流量能动的幅度更大——优化顺序必须跟着成本结构走。
Q5 为什么说 “优化闲置” 应该排在 “买预留” 之前？
▸ 答案：因为闲置资源也会被算进 “基线”，导致预留买多。先关掉闲置，基线才真实；在虚高的基线上买 3 年承诺，等于把浪费锁进合同。按投入产出比排：闲置清理通常 1 人日、回报 5%–15% 且无技术风险；预留需要准确的基线预测，且一旦买错无法退回。
跨篇相关：预留与 Spot 比例的容量依据见 57.3 冗余系数；成本优化的组织流程见 57.4 FinOps 实践；存储分层的取舍见 39.3 存储分级；TCO 与折现口径见 4.2 成本-收益分析；跨 AZ 流量的来源见 5.3 地域与可用区；出口费与锁定成本的关系见 5.7 云厂商锁定与迁移；弹性带来的峰值浪费见 5.4 弹性伸缩与自动扩缩容。