「AWS 省钱」攻略几乎只讲 EC2。但 RDS、S3、Lambda 与数据传出各按不同逻辑打折，且常是更大的账单项。按服务拆开讲，每项给判断方法。
如果你搜「AWS 怎么省钱」，看到的几乎都是同一套内容：预留实例（RI）、节省计划（Savings Plans）、Spot 竞价。这三样确实有效——但它们都是 EC2 及其计算类服务的折扣手段。
问题在于：EC2 往往不是你账单里最大的那一项。 数据库（RDS）、对象存储（S3）、数据传出（Data Transfer）在很多业务里占比更高，而且它们的计费逻辑与 EC2 完全不同——把 EC2 的省钱方法套上去，一点用都没有。
这篇按服务拆开，每个都给判断方法和可执行动作，而不是罗列折扣名称。（五家厂商的机制横向摆在一起看，差异会更清楚：五家云厂商折扣机制对比。）
为什么「AWS 省钱」的文章都在讲 EC2
因为 EC2 是入口服务，也是最多人接触的服务。写文章的人默认读者在用 EC2，而 EC2 的折扣模型又恰好最清晰：承诺换价格，三个选项（RI / Savings Plans / Spot）对应三种确定性。
但真实账单不长这样。一个典型的中型业务，账单结构往往是：
| 服务 | 常见占比区间 | 折扣机制 |
|---|---|---|
| EC2 计算 | 30%–50% | 预留实例 / 节省计划 / Spot —— 承诺换价格 |
| RDS 数据库 | 15%–35% | 预留实例（承诺换价格）；引擎与实例族决定空间 |
| S3 与存储 | 5%–20% | 不是折扣，是存储类与生命周期的选型问题 |
| 数据传出 | 5%–25% | 结构性优化（架构/缓存），几乎没有「折扣」可买 |
| 其他（Lambda、SQS、监控等） | 5%–15% | 部分可被计算类节省计划覆盖 |
先说结论：EC2 的折扣是「买承诺」，S3 是「选层级」，数据传出是「改架构」。三件事的方法完全不同，把它们混在一起谈是这类文章最大的误导。
如果你已经按 EC2 的方式做过一轮优化（比如我们另一篇讲的 AWS 账单优化 6 个做法），那接下来该看的就是这四项。
RDS：数据库的承诺折扣比 EC2 更容易买错
RDS 支持预留实例，逻辑与 EC2 类似：承诺 1 年或 3 年，换取相对按需的折扣，预付比例越高折扣越深。但 RDS 买错的代价比 EC2 更大，原因有两个。
第一，数据库的规格变化频率往往比应用服务器低。 应用可以随时扩缩容，数据库因为涉及数据迁移，通常会锁得很死。这听起来是好事（更容易预测），但也意味着一旦买错规格，这一年都得背着。
第二，RDS 的折扣绑定的是「实例族 + 区域 + 引擎」。 比如你承诺了 db.m5 系列在某个区域的 MySQL，那么：升级到 db.m6g（Graviton）不在覆盖范围内、换引擎不在覆盖范围内、跨区域也不通用。这三点比 EC2 的 RI 限制更严。
最常见的买错方式：为了拿折扣，直接按当前最大的那台实例承诺一年。但数据库的压力往往来自特定时段（批量任务、月末结算），峰值不等于常态。按 p95 或日均占用来承诺，而不是按峰值。
判断方法：在 RDS 控制台看一段足够长的历史（至少覆盖一个完整业务周期），确认日常占用和峰值的差距。如果差得远，先做的是降配或读写分离，而不是买承诺。
S3：不是折扣，而是把对象放到该放的层级
S3 没有「承诺换折扣」这一套。研究 S3 成本，99% 的收益来自存储类选型和生命周期规则，而不是任何折扣。
S3 的定价逻辑是：访问越不频繁、取回越慢、可用性越低，单价越便宜。 所以核心问题是——你存的东西，实际被访问的频率到底是多少？
- 经常访问的：留在标准存储，不要动它。往低频层放反而会因为取回费用而更贵。
- 一个月碰几次的：低频访问层（Infrequent Access）通常就能省下一部分，代价是有最低存储时长要求。
- 几乎不碰但要保留的：归档层，单价低很多，但取回需要等待（分钟到小时级），且取回有单独费用。
- 不想自己判断的：S3 有个「智能分层」选项，它会根据实际访问模式自动在层之间移动对象，省去人工分类。适合访问模式不稳定、又不想维护规则的情况。
可执行动作：先打开 S3 的存储分析（Storage Class Analysis）或访问日志，看实际访问分布——不要按「感觉」分类。很多人把「重要」当成「常访问」，把冷备数据留在标准层付了好几年高价。
另一条常被忽略的：版本控制与未完成的分片上传。开启版本控制的桶里，删除操作不会真正释放空间；中断的 multipart upload 也会一直占着容量计费。这两项用生命周期规则清理，通常能立刻见效。
存储类的完整选择方法（含各层的最低存储时长与取回费用对比）写在 S3 存储类怎么选 这一页。
Lambda 与 Fargate：无服务器也能吃到承诺折扣
很多人以为「无服务器」就没有折扣可谈——按调用付费，用多少算多少。这个理解只对了一半。
AWS 的计算类节省计划（Compute Savings Plans） 覆盖的不只是 EC2 实例，还包括 Lambda 和 Fargate。它的逻辑是：你承诺每小时一定的计算消费额，AWS 用折扣价抵扣你的计算用量——无论这些用量来自 EC2、Lambda 还是 Fargate。
这意味着两件事：
- 如果你的 Lambda 用量稳定（比如固定的定时任务、稳定的 API 流量），它可以被计算类节省计划覆盖，从而拿到折扣。
- 更实用的是反过来：计算类节省计划不锁实例规格，所以它天然适合「一部分 EC2 + 一部分 Fargate + 一部分 Lambda」这种混合架构。用一个承诺覆盖三种计算资源，比分别买三份承诺更不容易买错。
判断方法：看过去几个月的 Lambda 与 Fargate 消费是否稳定。如果波动很大（比如只在促销期跑批），不要为它买承诺；如果有一条稳定的基线（每天固定的任务量），那部分就可以纳入承诺范围。只承诺稳态基线，弹性部分继续按量付费。
计算类与实例类节省计划的差别、以及怎么和预留实例配合，见 节省计划与预留实例怎么选。
数据传输：账单里最容易被忽略的一块
数据传出（Data Transfer Out）是 AWS 账单里最容易被低估的一项。原因是它没有「折扣」可买——没有预留，没有承诺计划，只能从架构上减少。
它的计费逻辑大致是：入站通常免费，出站按流量收费；同一区域内跨可用区有少量费用；跨区域传输更贵。 所以成本往往出现在这几个地方：
- 把大量数据从对象存储直接送到公网（图片、视频、下载包）——这是最常见的成本来源。
- 跨可用区的高频通信：微服务之间如果没做拓扑优化，跨 AZ 调用的流量费会随调用量线性增长。
- 跨区域的备份与复制：容灾方案设计得很完善，但复制流量本身在持续计费。
- NAT 网关的流量处理费：很多人只注意到实例费用，忽略了按流量计费的那部分。
可执行动作（这里没有「买折扣」的捷径，只有三类结构性优化）：
- 能缓存的就缓存。 把静态资源交给 CDN，重复请求不会重复回源——这一项通常就是最大的一笔。
- 把跨 AZ 的调用改成本地优先。 让服务优先访问同可用区的依赖，跨区只作为兜底。
- 能放一起的就放一起。 如果两个服务之间流量很大，把它们放进同一区域（甚至同一可用区）比优化代码更有效。
为什么说它最容易被忽略：EC2 和 RDS 的账单是「看得见的大块」，数据传出是「很多小块加起来」。而按量计费的特性决定了——你不主动优化它，它就会随业务自然增长。
把三类折扣串起来用
看完上面四项，你会发现 AWS 的成本优化是三类完全不同的问题：
| 类型 | 涉及服务 | 手段 | 关键动作 |
|---|---|---|---|
| 承诺换价格 | EC2、RDS、Lambda、Fargate | 预留实例 / 节省计划 | 只承诺稳态基线，别按峰值买；优先用计算类节省计划覆盖混合架构 |
| 选型换价格 | S3 与各类存储 | 存储类 + 生命周期规则 | 用访问数据分类，不按「感觉」；顺手清理旧版本与中断的分片上传 |
| 架构换价格 | 数据传出、NAT、跨区通信 | 缓存 / 拓扑 / 就近访问 | 没有折扣可买，只能改架构；优先做 CDN 与同区优先 |
顺序很重要：先做「架构」和「选型」（不需要承诺，随时可做、无风险），再做「承诺」（一旦买了就是一年）。很多人顺序反了——先急着买预留实例拿折扣，结果规格买错，锁住一年。
最后补充一点关于代理渠道的：上面讲的全是「官方折扣」（AWS 直接给你的）。除此之外还有一条路是通过代理商开通与结算——它降低的是你的实际支付金额，与官方的预留实例、节省计划不冲突，可以叠加。这部分逻辑写在 AWS 折扣与代理定价 里。
别忽略顺序：代理折扣作用在你付给代理商的钱上，官方折扣作用在AWS 给你的账单单价上。两者在不同层面，所以可以同时享受——不是二选一。
常见问题
RDS 该买预留实例还是走节省计划？
如果数据库的实例族和区域在一年内确定不变，预留实例的折扣更深。但要注意 RDS 的预留绑定「实例族 + 区域 + 引擎」三项，任何一项要变，承诺就浪费了。如果存在升级到 Graviton 或换引擎的可能，先别买长期承诺，或者只承诺一个季度到半年的用量观察。
S3 的智能分层值得开吗？
取决于你的访问模式是否可预测。如果数据有明显的冷热分层（比如日志三个月后基本不再访问），手工配生命周期规则通常更省钱，因为你能精确控制。如果访问模式不稳定、又没人维护规则，智能分层省心且不会亏——它有个小额的监控与自动化费用，数据量很大时才需要权衡。
数据传出真的完全没有折扣吗？
没有「承诺换折扣」这一类。但有两个间接方向：一是用 CDN 把出站流量转成 CDN 的回源流量，通常单价更低；二是部分服务之间的流量在特定条件下不计费（例如同一区域内通过私有网络访问部分服务）。这两条都需要按具体架构评估，不存在通用答案。
Lambda 的用量怎么判断该不该买承诺？
看基线，不看总量。把过去 3 个月的 Lambda 消费按天排列，找出每天都发生的最低那部分——那才是可以承诺的。只在特定日期跑的任务（月末结算、定时报表）不要纳入承诺，它们用按量付费更划算。
这几项优化，从哪一项开始性价比最高？
按「不需要承诺」优先：先清闲置资源和未挂载的磁盘 → 再看 S3 的存储分布与生命周期 → 然后看数据传出的架构。前三项都不需要你做任何承诺，随时可做、也无风险。等这些都做完，账单项的构成清楚了，再去买预留实例和节省计划——那时你知道该承诺多少。