AWS 账单看不懂？2026 年云成本优化 6 个可执行做法

AWS 账单看不懂，通常不是账单太复杂，而是你打开的是付款视图——它只告诉你这个月被扣了多少钱，却不告诉你哪台机器、哪个环境、哪块磁盘在烧钱。要做 AWS 云成本优化，第一步不是去申请折扣，而是把账单切换成成本视图：按服务、按用量类型、按标签、按可用区一层层拆开。如果账单是突然涨了、而你要先弄清是谁涨的，那是另一条路径——见 AWS 账单突然变高怎么排查。

下面 6 个做法按「收益 ÷ 见效速度」排列，不是按理论难度。前 3 个通常就能吃掉你 30%–60% 的可优化支出，而且大多不需要任何架构改动。（顺带一句：折扣是账单优化的其中一层，不是第一层——五家厂商的折扣机制差别很大，横向对比见 五家云厂商折扣机制对比。）

30 分钟先把账单切成成本视图

AWS 自带三层账单界面，粒度完全不同。你要用的是 Cost Explorer，而不是账单页。

• Billing（账单页）：只有总额和发票。适合确认「我付了多少」，不适合找原因。
• Cost Explorer：按服务、用量类型、区域、标签、账号做多维拆解，支持自定义时间对比。这才是排查工具。
• Cost and Usage Report（CUR）：落到 S3 的原始明细数据，配合 Athena 可以写 SQL 自助分析。团队规模到「多人共用一个账号」时，这一步最终都要做。

路径是 Billing Console → Cost Explorer → Cost and Usage Report。前两个免费；Cost Explorer 在前两个账单周期免费，之后按所跟踪资源成本计费（量级是月支出的零点几个百分点，最低约 $1/月，具体以官方实时报价为准）。

先找出真正吃钱的 5 个大头

不要凭感觉优化。打开 Cost Explorer，按下面四步拆，10 分钟就能拿到一张成本大头清单：

1. Group by 选 Service，时间范围选上个月，看 Top 5 服务各占多少。
2. 对占比最高的 2–3 个服务，把 Group by 换成 Usage type（用量类型），看底是 DataTransfer-Out-Bytes、BoxUsage:m5.large 还是别的。
3. Group by 换成 Region + Availability Zone。很多账单里「同区域跨 AZ 流量」是一个不起眼但稳定增长的项。
4. 开启 Cost allocation tags（成本分配标签），按 Env、Owner、Service 分组。没有标签的支出会浮在 Untagged 里，那本身就是第一优先级问题。

拆完之后，绝大多数中小团队会得到类似这样的结构（以下是经验区间，不代表任何一家公司的真实账单）：

做法一：先关掉没人用的东西

这是投入产出比最高的一步，也是最常被跳过的一步。很多团队不是不知道有浪费，而是没人真的去查。把下面的动作交给值班的人，或者写进 IaC（Terraform/Pulumi）流水线，而不是靠人肉回忆。

• 未挂载的 EBS 卷：用 DescribeVolumes 按 State=available 过滤。卷按创建时的规格全额计费，挂不挂载都一样。
• 闲置的 Elastic IP：未关联任何实例的 EIP 仍按小时计费。
• 跨可用区的 NAT 网关：NAT Gateway 按每个可用区分别计费。多可用区架构如果在每个 AZ 都放一个，而其中一个 AZ 没有真实流量，那是一整份按小时费用。
• 缩容到 0 的 Auto Scaling 组、已停机但未注销的 EC2、长期保留的 RDS 快照与旧 AMI。
• CloudWatch Logs 没设保留期：日志按 GB 长期累积，通常属于「看一眼不心疼、半年后很贵」那一项。
• 闲置的负载均衡器，以及没有任何快照依赖链的孤立快照。

做法二：给实例和磁盘瘦身

清理完之后，第二步是把仍在付全价但用不满的资源改小。这一步的判断标准要用指标，不要用直觉。

EC2：看 p95 和内存，不是平均值

打开 Compute Optimizer（免费），它基于 CloudWatch 历史指标给出降配、升配和迁移到新一代架构的建议；EC2 侧的建议大约可以回看 12 周历史，正好覆盖工作日与周末的完整周期。具体怎么按负载挑实例族和区域，见 EC2 实例类型与区域怎么选。

• CPU 看 p95，别看平均值。p95 才 15% 的实例通常可以小一档。
• 内存常常才是真瓶颈：Java / Node 服务堆配置很高但实际只用 30% 的情况非常普遍。
• 别按平均值裁：留 20%–30% 余量。突发流量是常态，按平均值裁换来的是更高的重启/迁移频率和更差的 P99 延迟。
• 换机型常常比改尺寸更划算：同性能的新一代实例通常便宜 10%–25%；Graviton（ARM）在支持负载上通常便宜 20%–40%。迁移前务必确认依赖不是 x86 原生二进制。

EBS：GP3 的 IOPS 和吞吐是可以降的

GP3 卷最常见的浪费是按峰值规格买满。它支持在创建后单独调整 IOPS 与吞吐（基线以上部分立即生效），所以先把规格降到基线，再按实际用量逐档调高，比一步到位买满便宜很多。判断依据看 CloudWatch 的 VolumeReadOps / VolumeWriteOps 的 p95 用量。

另外两件常被忽略的事：同一份数据被多个实例挂载时，旧实例上那份卷不会被自动合并，旧卷照样全额计费；AWS 现在有 EBS Optimizer 会列出可优化的卷与预计节省，值得每月跑一次。

做法三：Savings Plans、预留实例和 Spot 怎么选

锁定折扣的本质是用钱换灵活性。选错的代价不是折扣小，而是接下来一年都在为一个根本用不满的承诺付钱。三种方式各自的适用条件，完整版见 节省计划与预留实例怎么选。

实际的决策规则只有四条：

1. 能用 Spot 的先全部用 Spot。 配上自动伸缩和断点续跑，把系统设计成「随时可被打断」，批处理成本可以降到接近按需的一成。
2. 主力 EC2 稳定在 2–3 个实例族 → 计算类 Savings Plans 1 年。 它对实例族不敏感，比 RI 更不容易买错，是绝大多数中小团队的正确选择。
3. 不要一上来就锁 3 年。 提前退出的代价是真金白银：卖出售余预留实例最高可能被收取预付额约一半的手续费，Savings Plans 的兑换与退出也有条件和费用。先买 1 年验证负载稳定，第二年再决定要不要延。
4. 承诺金额只买「稳态基线」。 把最低那部分（通常是正夜间的最低负载）算作承诺量，弹性部分继续按需或走 Spot。买多了不会退，这是最常见的亏损点。

做法四：数据传出（egress）：最容易出意外的一项

在账单里，DataTransfer-Out-Bytes 通常是增速最陡、也最没被主动设计过的一项。根因几乎总是同一个：请求从哪个可用区的实例出去，就从哪个可用区的出口计费，而不是走 CDN 或统一出口。完整拆解（流量其实有六个计费边界，以及每一条怎么省）见 AWS 流量费为什么这么贵。

• 同 AZ 内实例间通信免费；同区域跨 AZ 流量按每 GB 单价计费，双向都会产生费用。
• 跨区域流量同样计费，量级通常比跨 AZ 高一档。
• NAT Gateway 除按小时外还有按 GB 的数据处理费——每个 NAT 都收一次，这是 NAT 流量的双份成本。
• 互联网出站：静态资源、API 响应、图片下载都算在内，而且通常占大头。

做法五：把预算告警设成刹车片

优化不是一次性项目，是持续动作。没有告警的账号，三个月就能把省下的钱花回去——新增资源、测试环境、误配都会悄悄推高账单。AWS Budgets 的价值不在报表，而在阈值触发时能及时通知到具体的人。

1. 进 AWS Budgets → Create budget → 选 Cost budget，范围先锁定你负责的那个账号。
2. 金额设成上月实际支出的 1.1–1.2 倍，不要设成理想值。否则第一周就天天报警，最后所有人直接忽略通知。
3. 同时设 50% / 80% / 100% 三个阈值，再加一个 Actual vs Forecasted 阈值，用来抓「按当前趋势月底会超支」。
4. 通知渠道至少两个：邮件 + 团队聊天（SNS → Chatbot）。只有邮件的告警在实践中等于没有。
5. 开启 Cost Anomaly Detection，它基于历史模式做异常检测，能在账单明显上涨之前发现「某个资源的使用方式突然变了」。

再补一条治理动作：成本分配标签必须在资源创建时就强制带上。 标签如果靠人记得打，半年后 Untagged 通常会占总支出的 15%–30%，你就永远说不清这部分花在了谁身上。用 Organizations 的 SCP，或者在 IaC 里加必填标签来兜底。

做法六：让成本变成团队能管的事

以上六件事做完，剩下的瓶颈通常不是技术，而是「谁有权决定花多少钱」。这一步决定优化能不能持续下去。

• 按环境拆账号：生产一个账号、测试一个账号。测试环境最容易失控，独立账号让「先关测试环境」变成一个普通操作。
• 给测试环境加自动关停：工作日 19:00 定时停机、周末全天停机。一个 20 台实例的环境每月能省掉几十小时按需费用，几个人的成本差就出来了。
• 上线前过一道成本评审：新服务要有预估月支出，超过某个阈值（比如 $500/月）需要架构评审说明。这比事后省钱便宜得多。
• 每周 30 分钟成本例会：只看三样——总支出趋势、Top 5 服务、本周异常项。坚持三个月，效果通常超过任何一次性的架构重构。
• 把明细做成可查询的数据：CUR 落 S3 + Athena（按扫描量付费，单价很低），让业务方能自助查「我这个功能花了多少钱」，而不是每次都来问架构师。

30 天执行清单

把上面的内容压缩成一个四周节奏，按这个顺序做，收益基本线性累积：

1. 第 1 周 — 看清：在 Cost Explorer 里按 Service / Usage type / AZ 三层拆一遍，输出一张 Top 10 成本项清单；开启成本分配标签。
2. 第 2 周 — 清零：删掉未挂载卷、闲置 EIP、冗余 NAT 网关、过期快照；给所有 Log Group 设 30–90 天保留期；测试环境加定时关停。
3. 第 3 周 — 瘦身：跑 Compute Optimizer 与 EBS Optimizer，按建议改小一批实例、把主力卷迁到 GP3 并下调 IOPS/吞吐、评估一次 Graviton 迁移。
4. 第 4 周 — 锁定：按「最低稳态负载」买 1 年计算类 Savings Plans；把批处理任务迁到 Spot；配置 50/80/100% 预算告警与 Cost Anomaly Detection 通知。

做完这四周，常见结果是把可优化支出压掉 25%–50%，而且很多项是一次性的、会立刻体现在下一张账单上。真正决定长期效果的是第 4 周之后：告警有人看、标签有人填、闲置资源有人扫。