计费与成本入门

1 云成本回答什么问题：资源背后的计量

订单系统上线后，团队收到月度账单：应用没有增加，费用却比上月高。开发说请求量只涨了少许，运维说机器规格没有变，财务则想知道多出的费用属于哪个项目。这些说法可能同时成立，因为云账单记录的不只是机器，还包括磁盘、数据库、网络、请求、日志和备份。解释成本，首先要把业务活动对应到这些可计量的资源。

云不是“买了 1 台服务器，月费就固定”这么简单。很多服务按实际使用时间、保留容量或处理次数计费；有些同时收取固定费用和用量费用。应用实例运行着，即使没有订单，运行时间仍会累积；磁盘保留着，即使没有挂载，容量费用仍可能产生；用户下载商品图片，则可能同时增加对象读取次数与出网流量。业务空闲与账单停止不是同一件事。

可以先用一个框架理解：费用等于各项“计费用量 × 对应单价”的合计，再考虑免费额度、优惠、税费、退款等调整。这里的用量必须带单位，例如实例小时、GB·小时、GB 或万次请求。“用了 100”不能用于估算，因为 100 GB 的存储与 100 GB 的出网对应不同服务，也对应不同价格。

成本问题因而分成几层：用了什么资源；谁在什么环境使用；用了多久或多少；按什么规则结算。先让每项费用能够解释，再决定是否优化。如果只看总额下降，可能把测试环境关闭的节省与生产日志丢失的风险混在一起；如果只看总额上升，也可能误判正常业务增长。每笔主要费用都能回到资源和用途，才有比较方案的基础。

本课沿用 C15 的身份边界：谁有权查看账单、创建资源和修改配置，需要通过 IAM 授权。接下来补上另一条线：授权后的活动怎样形成费用，费用怎样回到项目，以及预算如何成为方案验收条件。目标不是记住某家云的价目表，而是能拿着资源清单，给出有假设、有公式、有责任人的成本说明。

2 常见计量维度：时间、容量、次数与流量

计量维度可以理解为账单上的计数器。下面列出订单系统常见的 6 类。表中的单位是阅读方法，实际服务是否按秒、是否有最低计费时长、是否向上取整，需要查看当前计费规则。相同资源名称，也可能采用不同的计费方式。

时间与容量经常相乘。100 GB 磁盘保留 10 小时，累计 1000 GB·小时；保留整月，则要乘本月计费小时。GB·月表达的是一段时间内的容量占用，不代表每月只能写入这么多数据。反复覆盖同一批对象，保留容量可能变化不大，但写入请求、历史版本和处理流量仍会增长。把“容量”和“传输量”混为一谈，会直接漏算。

网络也不能只看网卡总流量。入站与出站常有不同规则，常见情况是外部进入云的流量与云向互联网发送的流量价格不对称，但不能据此认定所有入站免费。跨区域、跨可用区、经过 NAT 或负载均衡的流量，也可能形成独立计费项。核算一次图片下载时，应沿实际路径检查：对象存储读请求、可能存在的缓存服务、互联网出网，以及中间组件的处理费。

日志与备份值得单列，因为它们常不在应用服务器清单中。每个请求记录 2 KB 日志，100 万次请求就约产生 2 GB 原始日志，这里为便于估算按十进制换算。若开启详细调试，单次日志变为 20 KB，同样请求量就约为 20 GB。实际账单还会受压缩、索引和计费口径影响，但 10 倍增长已经能通过这个例子提前识别。

读取计量时还要避免重复：如果托管数据库套餐已经包含一部分磁盘与 I/O，不应再把它们作为全部额外费用加入。相反，“包含计算”不代表包含所有备份和网络。先标明包含项、另计项和待确认项，比在不完整清单上追求小数点精度更有价值。

3 账单结构：账号、项目、标签与归属

账号通常是账单汇总和结算的重要边界，企业也可能在组织层统一付款，再按成员账号或项目分账。项目承载预算与责任，资源标签进一步说明用途。对订单系统，可以约定“应用=order”“环境=prod”或“环境=dev”“负责人=某团队”。这些字段回答不同问题：是什么应用、在哪个环境、由谁处理费用异常。

标签不会自动降低费用，却决定能否解释费用。假设某月应用资源费用合计 100，其中 60 标为 prod、25 标为 dev、15 没有环境标签。不能直接宣称生产只花了 60，因为未归属的 15 可能包含生产资源。正确呈现应保留“无法归属”桶，并列出资源标识、服务类型和补充证据，待核实后再分配。为了让报表看起来整齐而随意归入 prod，会污染后续比较。

标签也不是完整的分账算法。共享负载均衡、公共日志平台或多个应用共用的网络出口，可能无法直接按单个资源归给某个应用。此时应写明分摊口径，例如按有记录的流量比例分配，或者暂列共享费用。若按请求数分摊，而各应用的响应大小差异很大，就应说明这个口径的局限。无法精确分摊时，透明的约定比虚假的精确数字更可靠。

归属需要在创建资源时建立，而不是月底凭记忆追补。资源模板可要求填写环境、应用与负责人；巡检检查缺失值与错误值，例如 prod、production、生产并存会让同一环境散落在不同组。查看历史账单时还应确认标签是否在当时已经生效，当前资源标签不一定能自动修复过去的费用明细。

IAM 与标签纪律应分别验收。C15 解决的是谁可以访问费用信息或修改资源，授予查看账单权限并不会让所有资源自动带标签。可以允许应用负责人查看本项目费用，同时限制其修改结算设置；另由资源创建规范保证归属字段完整。最终，一条主要费用应尽量能沿“账号—项目—应用—环境—负责人”追溯，无法追溯的部分要显式暴露。

4 数量级估算：用教学单价做方案预算

本节统一使用货币单位，不对应任何厂商报价。教学假设：计算单价为 0.05 货币单位/实例小时；存储单价为 0.0001 货币单位/GB·小时；互联网出网单价为 0.08 货币单位/GB。 为便于比较，教学月份按 730 小时。这是平均月长度的近似，真实月份、计费舍入、免费额度和合同条款都可能改变结算结果。真实单价以控制台和合同为准。

先算 2 台持续运行的应用实例：2 × 730 × 0.05 = 73。再算 100 GB 磁盘：100 × 730 × 0.0001 = 7.3。最后算 200 GB 互联网出网：200 × 0.08 = 16。已知部分合计为 96.3 货币单位。这个数字只是这 3 项的教学小计，尚未包含数据库、负载均衡、请求、备份等，不能直接称为订单系统总预算。

估算的关键是量纲相消。实例数乘小时再乘“货币单位/实例小时”，结果才是货币单位；存储需要容量乘保留时间，不能拿 100 GB 直接乘按 GB·小时标出的单价。当账单采用 GB·月时，应使用对应的月度价格口径，不能未经换算又乘 730。看到不合理的小计，先检查单位，再检查数值。

预算还需要范围。假设出网可能在 200—600 GB 之间，按上述教学假设单价，出网费用就在 16—48 之间，仅这项便有 32 的变化。若应用从 2 台扩到 4 台并持续运行整月，计算费用从 73 增到 146。这样的比较告诉我们该优先确认流量和运行时间，而不是花大量精力争论 100 GB 磁盘估算中的少量误差。

可以用“基准场景、增长场景”管理不确定性。基准场景采用当前容量，增长场景明确哪些用量增加，不要把所有项目统一乘 2：请求翻倍不一定需要实例翻倍，备份容量也可能随数据增长缓慢变化。在规格和架构保持不变的范围内，按 GB 收取的出网费通常随出网量近似线性增加；计算费用常随实例数量与运行时间呈阶梯变化。

估算表中应保留假设来源与日期，例如流量来自压测、容量来自数据保留要求、运行时间来自排班。对尚未确认的费项写“待确认”及负责人，不能默认为 0。税费、优惠与免费额度另列调整项，避免把可变优惠当成长期资源效率。方案评审需要的是可复算、能解释范围的预算，不是一个看似准确却无法追溯的总数。

5 闲置与浪费：开着却无负载的成本

闲置指资源保留或运行，却没有对应的有效业务需求；浪费还包括资源虽然有用途，但规格、数量或保留策略明显超过需求。测试机忘关、未挂载磁盘、旧快照、闲置公网 IP 和过量保留的日志都可能收费。删除实例也不等于删除它的磁盘、快照或地址，巡检需要检查资源之间的关联与独立生命周期。

看一个时间差异。教学假设：某款 4 核测试实例的计算单价为 0.05 货币单位/实例小时，仅用于演算，不表示所有 4 核实例同价。 忘关后运行 730 小时，计算费用是 36.5。若业务只需每天高峰运行 4 小时，按 30 天估算为 120 小时，计算费用是 6。两者相差 30.5，忘关场景约为后者的 6.1 倍。节省来自减少无需求的运行时间，磁盘等附属费用仍须另算。

但不能看到低 CPU 就立即删除。备用节点可能为故障切换而保留，定时任务可能只在月末运行，数据库可能受内存或 I/O 限制。判断闲置至少结合业务用途、观察周期、访问记录和负责人确认。订单系统周末低负载，不能证明它在促销时不需要容量；短时间无请求也不能证明某个回调入口已经废弃。

处理资源应有可恢复步骤。先确认资源标识与归属，检查依赖，再按既定变更流程停用或缩减，观察业务，最后按保留要求清理。未挂载盘可能是待恢复数据，旧快照可能承担合规或恢复责任，公网 IP 也可能仍被外部白名单引用。成本巡检要找出可处置对象与证据，而不是把“看起来不用”当成删除授权。

浪费还藏在策略中。为方便而复制整套长期运行的测试环境，会让多个低使用率环境持续收费；对象存储开启版本后若没有生命周期，覆盖文件也可能不断增加历史容量；日志从 7 天改成长期保存后，新增数据会持续累积。对这些问题应定义环境到期时间、版本保留与日志分层规则，并记录清理前后的容量和费用变化，验证节省确实发生。

6 成本与可靠性的取舍：哪些钱不该省

成本优化应在明确底线内进行。订单系统至少要保护生产备份与恢复演练、满足可用性目标的多可用区部署、必要审计与最低日志，以及安全补丁窗口。这些费用购买的是恢复能力、连续服务与可追溯性。它们平时可能没有明显业务产出，但不代表闲置；发生误删、故障或安全事件时，才会体现价值。

备份费用尤其不能只按保存容量判断。假设方案要求最多丢失 1 小时数据、4 小时内恢复服务，评审就要检查备份频率、恢复链路和演练证据是否支持该目标。只保存备份却从未恢复过，不能证明可恢复；为减少账单擅自延长备份间隔，也可能直接破坏已承诺的目标。省下的保存费，可能在一次误删造成的停业与补单中耗尽。

多可用区也要对应明确需求。若订单数据库已经承诺承受单个可用区故障，就应把相应副本、存储与跨区通信作为必要成本，检查报价是否已包含它们。优化可以比较满足同一目标的规格和配置，不能在费用下降时悄悄把容灾能力删掉。若业务确实调整目标，应由业务与技术责任人共同确认，并更新方案验收条件。

日志可以控制噪声、采样普通访问记录、分层保留，但不能随意取消必要审计。安全补丁也需要时间与容量余量，例如滚动更新期间短暂增加实例。为了压低某个月账单而取消更新窗口，可能把成本转成更大的漏洞处置负担。将这些条件写成不可突破的清单，团队才能区分“减少无用消耗”与“降低承诺能力”。

评估优化时同时记录节省额、影响范围和回退条件。例如缩减测试环境运行时间，可用自动启动与状态检查保证次日可用；调整生产规格，则需以性能数据证明仍满足峰值需求。不能把开放公网访问、取消访问控制或关闭备份当成省钱默认选项。安全与恢复要求先确定，再在满足要求的候选方案中比较总成本。

7 常见坑：只看折后单价、忽略出网、标签缺失无法追责

只比较折后计算单价，容易把整套架构缩成一行报价。应用实例便宜，不代表数据库、磁盘、出网和日志便宜；若迁移后网络路径多了一层收费组件，总费用甚至可能更高。比较方案应固定业务量、可用性目标与保留要求，再对齐包含范围。折扣可以作为调整项展示，但不能替代对用量的解释。

出网常被遗漏，因为开发容易只估算数据库里的业务数据。订单记录不大，商品图片、导出文件和反复下载的附件却可能占据大部分流量。教学假设仍采用出网 0.08 货币单位/GB。 200 GB 对应 16，2000 GB 就对应 160。缓存命中率、响应大小和重试都影响实际出网，应通过监控确认这些量，而不是只按订单条数推测。

NAT、负载均衡和日志通道属于容易漏掉的中间费用。它们可能按运行时长、处理流量或容量单位组合收费，不能因为网络图上只画了一个箭头就忽略。检查时沿请求路径逐段标计费点，再核对日志从采集、传输到保存和查询的路径。若服务套餐已包含某段费用，应在表中注明，防止反向重复计算。

多账号不等于天然分账清晰。如果生产与开发账号都缺应用标签，财务仍可能找不到费用责任人。缺标签应形成待处理清单，而不是靠月末群聊猜测。预算告警也必须绑定能处理的人：只有邮件地址，没有值班替补、处理时限与具体动作，就只完成了通知，尚未形成控制。

还有一种误区是用长期用量承诺或“节省计划”遮住用量失控。折扣可能降低某项单价，却不会解释为什么测试环境突然多出大量实例，也可能带来承诺使用的约束。本课不展开购买策略；顺序应是核实用量与归属、清理无效消耗，再评估稳定需求的采购条件。购买优惠后仍要保留原始用量趋势，否则价格变化会掩盖资源增长。

8 案例：订单系统月度成本草算

考虑一个订单系统最小资源集：2 台应用实例、1 套多可用区托管数据库、1 个负载均衡、100 GB 应用盘、对象存储、200 GB 互联网出网，数据库备份保留 7 天。这里的“1 套数据库”包括满足本案例多可用区要求的资源，不应再误当成单节点价格。估算从资源与包含范围开始，不能仅数控制台里的资源卡片。

沿用前述教学月份 730 小时，并补充假设。下表所有单价均为教学假设，单位为货币单位；数据库和负载均衡使用教学组合模型，不对应真实产品。 数据库组合价假设已含多可用区计算、基础数据盘与基础 I/O；备份另计。负载均衡假设时长费外另有流量处理费。为保持案例边界清楚，假设此部署没有独立 NAT 资源。

按这些假设合计为 256.19—343.79，可向评审表达为约 256—344 货币单位/月，未计税费、优惠及未启用的额外服务。这里保留原始计算值方便复算，口头说明则使用区间，避免把尚未选定的数据库规格伪装成确定费用。实际产品若另收数据库请求、日志查询或网络费用，必须补入，不能直接照搬这张表。

备份保留 7 天并不自动等于“数据库容量 × 7”。全量、增量、压缩与服务包含额度都会影响计费容量，因此本案例明确假设平均计费备份量为 70 GB，并要求在验证阶段用实测替换。日志同样区分月写入量与平均保存容量，20 GB 写入并不意味着整月每个小时都保留 20 GB。

本例的 3 个敏感项是出网、数据库规格和闲置测试机。出网由 200 GB 增至 1000 GB，互联网出网费增加 64；若负载均衡计费处理量也增加 800 GB，另增加 8，二者不能混为同一项。数据库从区间下沿到上沿增加 87.6。新增 1 台忘关整月、教学假设单价为 0.05/实例小时的测试机，再增加 36.5，附属存储另计。

验收时逐行检查公式、教学假设单价和范围。出网、请求以及本模型中的处理费随对应用量线性增长；固定规格下的实例和数据库主要随运行时间增长，扩容则改变台阶。让评审者任选一项改变用量后能重新算出结果，这份预算才具备指导方案调整的价值。

9 排查案例：账单骤增、环境费用混线、预算告警后仍超支

排查从统一时间范围与费用口径开始。选择同等长度的日期，区分用量发生时间与账单入账时间，尽量先比较优惠和税费调整前的可比费用。准备按服务、标签、时间拆分的明细，关联资源标识，再取同窗口的流量图、变更记录和闲置资源列表。总额告诉我们发生了变化，明细与监控才能帮助定位原因。

路径 A：账单骤增。假设最近 3 天日均费用翻倍，先看增加额集中在哪些服务。如果出网从每天 20 GB 增到 200 GB，按教学假设单价 0.08/GB，出网日费就从 1.6 增至 16。对照同一时间的响应字节、下载次数和缓存命中率，再看变更窗口，可能找到新上线的导出接口或失效的缓存配置。请求量只增少许，也可能因响应变大而推高出网。

若增加的是日志，比较写入 GB、单请求日志大小与日志级别。部署后请求量基本不变，而日志量增长 10 倍，调试日志或重复采集就是需要核查的假设。处理动作应针对被证据支持的来源，例如恢复合理日志级别并保留必要审计，不能为了让费用曲线下降直接关闭全部日志。完成后继续观察实际用量是否回落，已入账费用不会因配置修复而自动消失。

路径 B：环境费用混线。假设报表显示 prod 从 100 增至 140，dev 从 40 降至 0，总额仍是 140。这首先像归属变化，而不是资源突然变贵。检查资源标识和标签历史，发现新建开发实例未带环境标签，被报表默认归进 prod。应修正报表的默认归类，把未知项先放入无法归属桶，再根据创建记录和负责人核实开发用途。

修复时分别记录资源当前标签与历史分账调整，不应暗示修改标签一定能重算旧账。还要检查为什么创建入口允许缺失字段，以及是否有其他资源同样遗漏。验收证据是缺标签资源数下降、已核实费用回到正确环境、共享费用有明确口径，而不只是 prod 数字恢复原样。否则下次创建环境还会重演。

路径 C：预算告警后仍超支。假设月预算 300，在累计达到 240 时发出邮件，但系统仍按每天 20 消耗，剩余 5 天就可能再花 100，达到 340。预算告警通常是通知机制，费用数据与通知也可能有延迟；它不天然等于实时余额，更不天然阻止资源继续运行。排查应检查发送记录、接收人、处理工单与后续资源变更，判断通知是否转化为行动。

改进需要把责任与动作写清：谁在什么时间内确认异常，谁审批新增容量，哪些有明确到期规则的开发资源可以受控停机，生产继续运行需要怎样升级决策。生产保护动作必须保留安全和恢复底线，不能按预算阈值直接删除数据库。复盘时保留阈值触发时刻、当时累计值、预计剩余消耗和采取措施后的趋势，验证告警是否真的缩短了处理时间。

放进方案里

在 P2/P3 的方案中加入可复算的成本页。先列计量维度表，把计算时间、存储容量与性能、出网、请求、日志和备份映射到实际资源。注明哪些包含在套餐中、哪些另计、哪些尚待确认，避免把缺项当成免费。网络图上的主要收费路径也应能在表中找到对应项。

写清归属约定：账号或项目边界，以及应用、环境、负责人标签的必填值。共享资源说明分摊依据，缺失标签进入无法归属桶并指定处理人。衔接 C15，列出谁能查看本项目账单、谁能修改预算配置；资源创建权限与费用查看权限分别说明，不能用授权替代标签纪律。

预算逐项给出用量、单位、公式和假设日期，使用本课数字时显著标注教学假设单价。提供基准与增长区间，标出随流量线性增加的项，以及扩容后才改变的项。对出网、数据库规格和测试环境运行时间做敏感度比较，真实部署前用控制台或合同价格替换教学数字。

附上闲置巡检项：到期测试机、未挂载盘、旧快照、闲置地址、对象历史版本与日志保留。每项有资源归属、依赖确认和处理证据。另列不可省的成本底线，包括生产备份、恢复演练、必要多可用区、审计与补丁窗口，优化不得绕过这些承诺。

最后把预算告警写成行动约定：阈值、接收人、替补人、响应时限、审批入口与允许执行的措施。验收要求任选主要费用能追到资源和责任人，任选用量变化能重算区间，异常后能找到同窗口明细与变更记录。成本页因此成为方案约束，而不是上线后补上的总价截图。

10 小结：成本可读之后，进入方案深化（P2/P3）

云成本从计量开始，经由账号、项目与标签形成归属，再通过假设和公式进入预算。先解释用量，再识别闲置与浪费；优化始终受安全、可用性和恢复目标约束。预算告警只有连到责任人与动作，才可能改变超支结果。

进入 P2/P3 时，带着资源清单、预算区间和证据要求深化方案。你应能说明每项主要费用怎样产生、哪些变化最敏感、哪些能力必须保留，无须背诵厂商价目表，也无需先掌握复杂的采购套利策略。