佚格麻瓜最近有个CTO朋友跟我吐槽，说他们公司每个月的AWS账单跟坐火箭似的往上蹿，明明业务量没涨多少，成本却比上个月多了接近一倍。查了半天账，最后发现问题出在几台闲置了快半年的GPU实例上——一台p3.2xlarge挂着不跑任务，一个月将近两千美金就白烧了。这种场景我见得太多了，很多团队其实不是没有成本意识，而是压根不知道该从哪儿下手去查、去省。
我这些年帮不少团队做过云成本治理，自己也踩过无数次坑，从最开始对着账单一头雾水，到现在基本能在一小时内定位出主要浪费点。这篇文章就把我实际验证过的三招核心打法分享出来：账怎么算清、资源怎么砍、架构怎么改。不卖理论，全是能直接落地、能让账单肉眼可见往下降的实操方法。按照这套思路走一遍，云成本下降30%到40%是完全可实现的，如果你原本资源浪费得比较狠，省得更多。
1. 动手省钱之前的必做功课：先把账算明白
很多人一听说要优化云成本，第一反应就是冲进去关实例、缩配置，这是大忌。你连钱花在哪了都不知道，凭什么判断哪台机器该砍、哪台机器该留？我见过有人把生产环境的核心数据库配置给缩了，结果业务高峰期直接扛不住，省了五千块、损失几十万，这种案例一点都不夸张。
1.1 成本可视化：让每一分钱都有标签
AWS账单在根账号的Billing页面里就能看，但默认视图对多项目、多部门的企业来说基本等于没有——你看到的是一坨数字，根本分不清是哪个项目花掉的。所以做成本优化的第一步，不是省钱，而是给资源打标签。
标签就是给你每一台EC2、每一个RDS、每一个S3桶贴上归属信息，格式就是简单的键值对，比如 Project=A电商平台、Environment=production、Owner=张三。有了标签之后，你在Cost Explorer里就能按照Project维度去拉账单，哪套系统花了多少钱一目了然。
我一般建议团队至少打三个维度的标签：业务项目、环境（生产/测试/开发）、负责人。前两个用来做成本归集和分摊，第三个用来出问题的时候找得到人。实际操作中经常遇到的情况是，标签规范定了，但新资源创建的时候没人记得打，这时候就得靠强制手段——用Service Control Policy或者资源创建时的IaC模板加校验，没带指定标签的创建请求直接拒绝。虽然前期有点阵痛，但后面做成本分析的时候能省太多事了。尤其是当公司账号多、业务线多的时候，没有这套标签体系就相当于没有账本，后面所有优化动作都无从谈起。
另外一个特别实用的工具是Cost Explorer，它支持按服务、按区域、按账号、按标签维度去看费用趋势。我每次做成本分析，基本都会用它的分组视图，拉出最近三个月的费用趋势，找出曲线异常爬升的时间点，再倒推那个时间点上线了什么功能、加了什么资源，很快就能圈定问题范围。
1.2 AWS Budgets和异常告警：别等账单出来才发现超支
账单是月结的，真等月底看到账单傻眼，那个月钱已经花出去了。AWS Budgets这个服务就是干这个用的——你设定一个预算阈值，比如每个月五万美金，当实际消费或预测消费达到80%的时候，系统就往你的邮箱或钉钉/企微机器人推送告警，这个时候去处理还来得及。
我强烈建议预算至少设置两层：月度预算和预测预算。月度预算是看实际花了多少，预测预算是根据当前消费速度推算这个月最终会花多少。有时候月初才过一半，预测值已经超过整月预算了，这种告警才是真正需要警惕的信号。仅仅是看实际消费，往往等到告警的时候已经来不及救了。
除了预算告警，AWS Cost Anomaly Detection也是一款很容易被忽略但很实用的工具。它基于机器学习对历史消费数据建模，能自动发现异常消费模式。比如你平时每天EC2消费是五百美金，某天突然涨到一千二，它会自动形成一个异常事件并推送告警。我给它起的定位是“最后一道防线”——毕竟人的精力有限，不可能每天都在成本报表前盯着，有了这层自动化监控，至少能在异常发生后一两天内发现，不至于拖一个月到账单日才暴露。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第一招：对存量资源“断舍离”，40%的成本能从闲置和浪费里挤出来
账算清楚之后，接下来就是对存量资源动刀。根据我的实践经验，绝大多数AWS账号里起码有30%的资源是处于闲置或低利用率状态的——要么是上线时创建了、后来业务下线但机器没退；要么是配置过高、实际CPU和内存利用率长期徘徊在5%到10%。这些资源是成本优化的“第一桶金”，也是见效最快的地方。
2.1 EC2 Right Sizing：找到负载和配置的最佳交点
很多团队选实例规格的依据是“估摸着够用就行”，估高了不奇怪。我见过最离谱的一个案例：某数据分析团队跑离线批处理，开的全是c5.2xlarge（8核16G），结果一查监控，CPU平均利用率只有4%，内存用了不到2G——这批机器一个月就要花掉六千多美金，而真正干活的时候都用不到十分之一的算力。
解法就是Right Sizing，说白了就是根据实际负载去匹配实例规格。AWS自家的Compute Optimizer会用机器学习分析你所有EC2实例过去两个月的利用率，给出规格调整建议，比如“c5.2xlarge可以降为c5.large”，直接照着推荐改就行。
不过纯依赖工具也不行，还得结合业务形态去判断。我常用的分析套路是先看三个核心指标：
- CPU利用率：看平均数和P95，如果P95都长期低于20%，基本可以确定规格过高了；
- 内存利用率：这个是很多人会忽略的，AWS的免费监控默认不采集内存指标，需要在实例里装CloudWatch Agent才能看到；
- 网络吞吐：有些业务CPU不高但网络包量巨大，这类情况降配就可能出问题，降之前一定得看清楚。
判断出哪些实例规格过剩之后，具体操作是通过修改实例类型来完成的。这里有个需要注意的点：修改实例类型需要实例先停止再启动，会有几分钟的停机窗口，生产环境操作前一定要评估业务影响。如果业务不能停机，就选一个维护窗口期操作，或者用新规格的实例先顶上，确认没问题再切流量。
自动化的方式是用AWS Launch Template加Auto Scaling Group，把里面的实例类型定义从硬编码改成参数化列表，这样后面想统一调整规格的时候，只需要改模板再滚动更新，不至于几百台机器一台台去手工操作。
2.2 开发/测试环境自动休眠：非工作时间就该关机
如果你做过成本分析就会发现，开发环境和测试环境往往是浪费的大头。正常情况下，开发团队每天工作八小时，但开发服务器是24小时全天候开着的，这16个小时的空转时间实际上就是在烧钱。
我的做法是给开发/测试环境的EC2实例设置一套自动化启停机制：工作日早上八点自动开机，晚上八点自动关机；周末全天关机。这套机制跑下来的效果立竿见影，单是开发环境的EC2费用就能降50%以上，在整体账单上大概能拉低10%到15%。
实现方式很简单，用Lambda + CloudWatch Events（现在叫EventBridge Scheduler）就能搞定，不需要额外装任何软件。核心思路是：用EventBridge创建定时规则，到点触发Lambda函数，函数内部根据实例的Tag筛选出需要关停的机器，调用EC2的StopInstances或StartInstances接口去执行动作。
这里有一个比较成熟的实现方案：给所有开发环境的实例打上 AutoStop=true 和 AutoStart=true 的标签，然后Lambda函数每次只处理带对应标签的实例，这样就不会误伤生产环境的机器。我自己还用过一个更稳的思路，就是维护一张配置表放在Parameter Store里，按部门和项目记录不同的启停时间，灵活性比一刀切高很多。
2.3 存储成本：EBS和S3是账单里最会“闷声烧钱”的服务
看到EC2的费用高，大部分人都会去调实例，但很少有人留意EBS存储块的费用。每台EC2实例至少要挂一块根卷，默认创建的时候一般都会给到30G或50G的SSD容量，但很多业务根本用不到这么多。而且要知道一个坑：你删了EC2实例，根卷默认会保留，如果不手动删除，它就会一直躺着扣费。我整理过好几个客户的账号，每次都能找到几十块已经没有任何实例关联的“孤儿卷”，单个看起来每月的费用不高，二三十块加在一起就是一笔不小的数字。
理论上处理这类问题并不难：先用脚本把所有的EBS卷和实例关联关系拉出来，找出所有 status=available（没挂到任何实例上）的卷，确认数据没用了就直接删掉，一块卷每月能省下的钱虽然不多，但抵不住数量多、积少成多。
另外一个很重要的动作是gp2向gp3迁移。gp3是AWS后来推出的新一代通用型SSD，单价就比gp2便宜了差不多20%，而且默认吞吐量还更高。对大多数业务来说，直接从gp2切到gp3，IOPS和吞吐都会得到提升，费用却更低，属于罕见的“既省钱又提性能”的操作。操作方式是在控制台里修改卷类型，或者用CLI执行一行命令，等待卷的底层数据迁移完成就行，通常不需要重启实例。
S3存储这块也有类似的门道。很多团队习惯把所有数据都放到S3 Standard里，但根据数据访问频率的不同，完全可以考虑S3 Standard-IA（低频访问）、S3 Glacier Instant Retrieval甚至Glacier Deep Archive。就老日志、历史备份这类数据来说，访问频率极低，放Standard就是每个月白交钱。配置一条生命周期策略，让超过30天没访问的对象自动转入IA，超过90天自动转入Glacier，存储成本可以省下来80%左右。
3. 第二招：Savings Plans和Spot实例，花同样钱买到更多算力
如果说清理闲置资源是“止损”，那购买Savings Plans和合理利用Spot实例就是“放大收益”。这两者本质上都是在跟AWS“批发拿折扣”，付出的管理成本不高，但省下来的数字非常可观。
3.1 Savings Plans到底是什么、怎么选？
直接说结论：Savings Plans是AWS针对你有长期稳定算力需求时推出的一个预付费折扣计划。具体做法是你承诺在未来一年或三年内每小时消费一定金额，AWS作为交换给你折扣。EC2实例的折扣大约在30%到60%之间，根据你承诺的时长和付费方式不同而浮动。承诺一年、全预付，折扣最高；承诺三年、部分预付，次之；选择每小时付款、无预付，折扣最低。
很多人分不清Savings Plans和之前的Reserved Instances（预留实例）的区别。简单类比：RI类似于你直接包了一间房，不管住不住都占用这间；Savings Plans更像直接买了一张“任住卡”，只要入住的就是这个档位内的房型都按折扣价算。Savings Plans的灵活性更高，它会优先抵扣你账号下所有符合条件的EC2（包含Fargate和Lambda的算力消耗），用不完的额度才是浪费。
选Savings Plans之前，一个重要的步骤是测算自己的基础用量。我一般会先看过去三个月的EC2账单，找出每小时的用量最低值——那个就是你雷打不动的“底座”。比如过去三个月里，无论业务怎么波动，你至少有10台m5.large在跑，那就可以按10台的量去购买。这样能确保Savings Plans的承诺消费额永远在覆盖范围内，不会出现承诺了但实际用不满、还得倒贴钱的情况。
实际操作中，还有一个跟Savings Plans经常一起出现的组合拳——Compute Savings Plans vs EC2 Instance Savings Plans。前者可以跨实例族、跨区域、跨账号抵扣，折扣相对低一些；后者只能抵扣特定区域的特定实例族，折扣更高。我给团队的建议是：如果业务比较稳定，明确知道未来一年跑什么规格，买EC2 Instance Savings Plans可以抠出更高的折扣；如果业务经常调整架构、实例样式换代快，选Compute Savings Plans更稳，灵活性价值远超那点折扣差。
3.2 Spot实例：把批处理和无状态应用的算力成本打到两折
Spot实例是AWS把闲置的算力以超低价拿出来卖的一种形式——最高能比按需价格便宜90%，但代价是：当AWS需要回收这部分资源的时候，它会给两分钟的预警通知，然后回收实例。所以只有那些扛得住中断的业务才适合用Spot，典型的就是离线批处理、大数据分析、CI/CD构建节点、无状态Web服务。
我自己做过的比较成功的一个案例，是一个CI/CD跑测试的集群。原来用的是五台c5.xlarge按需实例，一个月下来大概四千美金。后来我把这些节点的基础镜像统一改成容器化方案并且推送到自己的镜像仓库，然后把Auto Scaling Group的购买选项切到Spot池，配合Capacity-optimized策略选择最不容易被中断的可用区，实际跑下来月成本只有八百美金——打了两折，而且因为测试任务本身对中断有重试机制，建集群至今没有遇到过被中断导致任务失败的严重事故。
如果你想把Spot的风险控制得更精细，可以用一组混合策略：Auto Scaling Group里面同时设置Spot实例和一个按需实例作为备用容量，当Spot实例被回收或者价格超过设定上限的时候，系统会自动采用按需实例接管。对于可以用队列方式处理的业务来说，这个策略几乎是零成本上云省钱最实用的技巧了。
3.3 自动化切入点：把承诺折扣交给系统管理
如果你所在的团队比较大、账号数量多，AWS Organizations里的Consolidated Billing加Savings Plans组合的方式值得认真考虑。把多个账号的账单合并，所有账号共享同一个Savings Plans池，这样即使某个账号某天用量低、另一个账号用量高，Savings Plans的抵扣也会自动在账号间分配，不会出现A账号Savings Plans用不完、B账号却全款按需付费的情况。
用管理账号登录控制台，进入Billing页面下的Cost Management，找到Purchase Savings Plans选项，先让AWS基于历史账单给你生成一份建议。一般建议实际承诺额度设置为你历史最低用量的80%到100%，预留一点弹性空间给突发流量。另外需要注意，Savings Plans购买之后是不能退的，选错规格就只能靠后面的用量慢慢稀释，前期测算这一步一定不能省。
4. 第三招：从架构层面动手，把“常驻服务”改成“按需运行”
如果说前面两招是“省钱”，那这一招就是“换一种活法”，系统性省成本，还能提升系统弹性。它的核心指导思想很简单：同一个业务，别让它7x24小时地在固定的服务器上跑，而是尽量往无服务器架构和容器化方向走，让资源跟着请求走，而不是为了可能到来的请求常年空转。
4.1 Serverless化改造：从“养服务器”变成“为调用买单”
Serverless最典型的产品组合是API Gateway + Lambda + DynamoDB。这个组合的逻辑是：用户请求到了API Gateway，触发Lambda函数执行一段代码，需要读写数据再去操作DynamoDB。整个过程里，你没有一台一直开着的服务器，也就不存在空闲付费，而是按实际调用次数和运行时长来付费。
我的体验是，这组产品在“间歇性负载”的业务场景里优势特别大。比如说一个定时任务，每天只在固定时间跑一次；一个内部工具，只在上班时间有人用；一个营销活动页的Backend API，活动期间流量高，活动结束几乎没人访问。这三类业务如果用传统的EC2托一个服务，即使几乎没有流量，每个月也要交几百美金的实例费。改为Lambda之后，可能一个月只花几十美分。
不少读者会担心迁移成本。实际上Serverless化并不要求推倒重来，可以先从一个比较“独立”的API开始试水。比如原来你的后端服务里有一个发送邮件的功能，把它拆出来，用Lambda + SES重写一遍，通过API Gateway暴露，原来的服务只需要改一下HTTP调用地址。这个改造过程对现有系统的侵入很小，而且能立刻看到这部分成本变成按量计费。踩过一次坑之后，你对Lambda的并发、超时、冷启动这些概念就会有体感，后面再迁移别的模块就得心应手了。
4.2 ECS Fargate vs EC2：走出容器的成本迷思
如果你原来的服务是跑在EC2上自建Kubernetes或者用Docker Compose管着的，把整个集群搬上ECS Fargate可能是你实现“按量付费”最快的一条路。
简单说，Fargate是AWS托管的容器运行环境，你只需要定义好容器镜像和需要的CPU/内存规格，它自动帮你找地方运行，你不用再管理底层服务器。它的计费模式是按秒计算、按资源的实际使用量计费——容器运行中才付钱，不需要的情况下缩到零副本，成本就归零了。
这里有一个大家常搞混的点：ECS Fargate不一定比自建ECS on EC2更贵。如果是那种大流量、全天候满载的业务，用ECS on EC2并且搭配Savings Plans，成本确实更优；但你如果是那种一天大部分时间没有几个请求的长尾服务，Fargate按秒计费的模型更为合适，彻底不跑的时候成本直接归零，而后者无论如何都得背着底层几台EC2常驻。
我实际改造过一个客户的内部系统，原来两台t3.large常驻，一个月算上EBS差不多五百多美金。后来迁移到Fargate，平时流量小，服务缩到1个副本，高峰期自动扩容到5个，一个月账单不到一百五十美金。按同样的负载跑完业务，体验没有任何变化。
4.3 用S3生命周期策略给存储“自动降级”
再延伸一个架构层面的习惯：S3其实不只是一个“放文件的地方”，它是一个有层次的存储体系。设计存储方案的时候，你就该想好数据的生命周期：新上传的日志放Standard；超过7天不访问的转入IA；超过90天没访问的转Glacier Instant Retrieval；超过一年的压缩后转Deep Archive。
通过一条生命周期规则，S3会自动帮你做这些搬运，而不用人肉去脚本同步。在S3控制台选中桶，添加Lifecycle Rule，按前缀或者标签匹配对象，就可以直接配置转换策略。规则配置完要留意一点，S3的转换是按“对象最后修改时间”起算的，不是按你配规则的时间起算，所以有些老数据会在规则配置当天就立马触发转换，这个过程中需要关注一下是否有费用预警，确认批量转换带来的请求费用是否在预期内。
5. 账单省下来了，怎么守住成果并持续优化？
成本优化不是一次性的运动，月初降下来了，月底就可能弹回去。我觉得成本这件事跟家里记账本质上没什么区别——你不可能靠月底看一眼收支表就把钱省下来，还是需要每天了解进账和出项，看到异常的苗头就立刻处理。云成本治理同理，花一周时间做完存量清理后，更重要的是建立一套治本的机制，让自己不用每次都用“救火”的方式面对账单。
5.1 建立标签强制规范和成本看板
省钱之后要想守住战果，第一道防线就是打好标签，而且必须是强制的。在组织的IaC模板里把标签校验写死，没有 Owner 和 CostCenter 标签的资源不让创建。同时用Cost Explorer做一个按部门展示的成本看板，放在部门的周会上。确保每一个团队负责人对自己团队的云花费有一个直观的感知。当一个团队每个月都能看到自己成本趋势的时候，很多浪费行为其实会自动收敛——这比任何自上而下的行政命令都有效。
我自己的经验是，每月初抽半小时拉一下上个月的Cost Report，按服务、按项目看一遍环比数据，重点留意增幅超过20%的项目。不要怕麻烦，这半小时花的非常值，坚持半年以后你会对账号里的每一个服务、每一类流量费用都非常有数。
5.2 FinOps文化的建设：让工程师主动关心成本
不少团队将成本归属于财务或运维团队，但云成本最终是由工程师写代码时选择的资源规格决定的。如果工程师没有成本意识，你再怎么事后核算也只是亡羊补牢，防不住新浪费的产生。所以要让工程师在开发阶段心里就要“装着一杆秤”，把成本作为一个常规的考量因素。
具体做法有许多：将成本指标纳入开发团队的月度复盘；新功能上线前做一次简单的成本评估；买Savings Plans的时候让架构师和核心开发一起参与决策，而不是只由运维单方面决定。此外，还可以设置CI流水线里的成本预估步骤，比如Terraform Plan之后自动跑一次Infracost，估算出这批资源每月的费用，并及时输出到PR评论中。当开发写一个资源定义的时候，立刻就能知道它一个月会花多少钱，这个反馈是很有震慑力的。
5.3 每季度的成本治理复盘要怎么开才高效
最后聊一下节奏问题。我经常被问到“成本优化做完之后，多久再查一次合理？”我的答案是一周看一次告警，一月做一次分析，一季度做一次系统性的治理。这里说的“季度治理复盘”指的是：过一遍账号下所有的EC2、RDS、EKS节点，看看有没有规格过大的新资源上线了；梳理一遍Savings Plans的覆盖情况，有没有因为新开账号或新购实例导致覆盖率下降；检查一下存储服务的生命周期策略，是否有未及时清理的日志存储桶在持续膨胀。
复盘会建议控制在40分钟内，直接拿着Cost Explorer按服务维度的报表来开，对照上次的记录一条条过：关掉了哪台机器，省了多少；新上线了什么资源，是不是必要。季度复盘最大的价值不在当下省了多少，而是建立了一个连续追踪的机制，让团队始终有人对成本这件事保持敏感度。三个月、半年做下来，团队的云成本控制能力会上一个非常大的台阶。
6. 实战复盘：一次真实的AWS账单瘦身全过程
最后用一个我实际操盘过的案例把前面所有招法串起来，方便你对整个过程有一个整体认知。那个客户的情况是月账单在五万美金左右，在华东做跨境电商SaaS，大概有六十多套服务部署在AWS的us-west-2，账号的情况比较典型——没人管标签、开发测试环境24小时运行、机器规格凭感觉开。
整个治理过程分了三步，耗时大概三周：
第一步，建立成本模型和标签规范。这步用了大概两天时间，把全部存量资源补齐标签、Future创建强校验、设置Cost Explorer分组、配好月度预算告警和异常检测。这个阶段的产出是一份清晰的成本报表——各业务线分别花了多少钱。
第二步，清理存量浪费。拉出所有EC2实例，以 Environment=dev 和 Environment=test 为条件筛选，把已经在运行的开发测试实例做了一次CPU和内存利用率分析。最终关停闲置实例23台，降配11台，删除了37块孤儿EBS卷和两个无人访问的S3桶，这步做完，整张账单已经降了约8000美金，折合16%。
第三步，购买Savings Plans并调整架构。基于过去三个月的EC2用量分析，购买了一份按小时承诺消费的Compute Savings Plans，覆盖全部账号里常年保持的底座算力。顺手把流量低谷流量大、扛得住中断的夜间批处理任务切成Spot实例。针对访问量起伏比较大的报表服务做了Serverless化的改造，上线Fargate。三步下来，账单从五万美金降到了三万出头，整体降幅接近38%。从始至终没有动到生产核心链路。
做复盘的时候我发现了一点，在整个过程中最耽误时间的其实不是技术操作，而是确定“这台机器到底能不能关”——常常需要找对应的业务负责人确认，没人能给出明确答复。后面我学乖了，建立资源时责任人就强制写入标签，这个烦琐环节就慢慢消失了。
最后分享一点个人建议
我真的很想说一句：云成本优化最大的障碍是恐惧——怕动生产环境出事、怕开发环境关停影响迭代、怕改架构引发不稳定。但根据我的实际经验，把开发环境晚上自动关停，几乎不会影响任何正常工作；把明显规格过大的机器降配，也不会带来任何业务波动。真正的风险点其实是那些没打标签、说不清归属、没人敢动的资源。所以成本优化的原则应当是“先易后难”：先清理闲置，再购买Savings Plans兜底，最后才是架构级别的调整。走完这一步之后，每月坚持看一眼账单趋势，效果自然就能稳住。你的AWS账单不应该是一个每年都会让人心跳骤停的谜题，花点时间把它彻底理透，回报率远超你的预期。