云海天狼这个月账单怎么又涨了？这恐怕是很多团队看到AWS月账单时内心最真实的独白。作为常年帮客户做云成本治理的架构师，我见过太多类似的场景：月初调了个实例，加了个快照，加了个并发，月底一看账单数字顿时傻眼。云成本这件事，说难也难，说简单也简单。难在你永远不知道钱到底耗在哪里，简单在你只要抓住几类大头资源，配合一套可落地的治理手段，效果立竿见影。
这篇文章不写概念，只讲实操。我基于自己做过的大量成本优化案例，把真正能把账单降下来、而且降下来之后不反弹的招数总结成三条主线：算力匹配、存储治理、架构重组。按这三条线走下来，大部分项目在不对业务做伤筋动骨的前提下，成本降个四成并不夸张。CTO可以把它当作预算管理的抓手，架构师可以把它当作基础设施改造的路线图，即使是刚开始接触AWS的运维同学，也能从里面找到可以直接试的优化动作。
1. 先别急着降配，先把账单拆明白
我见过太多团队拿到成本优化任务的第一个反应就是打开EC2控制台，看哪台机器不顺眼就降个配置。这种做法风险极大，很容易把核心业务搞挂，而且往往没降多少成本，反而增加了事故概率。做成本优化的第一原则，不是动手改，而是先把账单彻底拆明白。
1.1 用预算和标签建立第一道防线
很多时候账单超支不是某一项技术问题，而是管理缺位。AWS本身提供了预算工具Budgets，可以按月度、季度设置成本预算，并且按百分比设置告警阈值。我建议不管账户多小，都要把Budget建起来，这相当于给你的云账户装了一个燃油表。
具体创建路径很简单：控制台搜索Budgets，创建预算类型选择“成本预算”，周期选月度，输入你预期的金额，然后在告警阈值里设置三档：实际花费达到80%提醒一次，达到100%提醒一次，预测花费达到100%再提醒一次。通知方式建议同时绑上邮件和Slack机器人，这样出问题的时候不是财务事后才发现，而是当天就能有人响应。
但Budgets只能让你知道“超了”，不能告诉你“超在哪”。这时候标签体系就很重要了。我习惯在创建资源的时候强制要求打上三个标签：Env（生产/预发/测试）、Team（所属团队）、Project（业务项目）。很多公司觉得打标签麻烦，可一旦账号里的资源有几十个甚至上百个，不打标签的成本分析就是一笔糊涂账，你根本分不清这笔钱是为哪个产品花的。
注意：AWS有Cost Allocation Tags功能，启用后，标签才会出现在成本报告里。在Billing控制台的Cost allocation tags里找到你创建的标签键，勾选激活，最多等24小时数据才会刷新。这个环节不做，后面一切分析都无从谈起。
1.2 用Cost Explorer找出花钱大户
登录成本管理控制台，打开Cost Explorer，这是日常分析最常用的工具。很多人打开Cost Explorer只看总金额，这是浪费了它最核心的价值。最实操的用法是：把时间周期切到最近三个月，按“服务”维度分组，先把各服务占比看清楚，几乎每个账户的账单都是二八原则，EC2加RDS（关系型数据库服务）往往能占到一半以上，S3（对象存储）和数据传输费用紧随其后。
确定了哪个服务是大头，再按“实例类型”或“资源ID”维度细分。这里说一个经验值：如果一个账号里有几十台EC2，最后可能发现80%的支出集中在三到五台高配机器上。把这几台机器的规格、运行时长、给哪个业务用彻底搞清楚，成本优化的切入点就有了。
对于需要更精细分析的大企业，我还建议开启CUR（Cost and Usage Report），把账单明细导入到Athena或QuickSight里做自定义分析。CUR的数据最全，能够精细到每一个资源每小时的花费。不过Curiosity第一次配置有点复杂，需要在S3建存储桶、再建一个数据导出任务。对于大部分中小团队，这步可以先不做，Cost Explorer加上标签维度已经足够支撑第一轮优化。
1.3 别忽略账单里的“隐藏刺客”
第一轮拆解账单时，有几类费用特别容易被人忽略，却在账面上占了不小比例。它们往往和业务资源没有直接关系，而是运维过程中不经意产生的“隐藏刺客”。
第一类是地域内外数据传输费。AWS的公网流出流量费不便宜，如果你有跨地域数据同步、大量向公网分发内容或频繁做跨账号传输，月底看Data Transfer费用会吓一跳。这类费用在Cost Explorer里属于独立的服务维度，平时没排查过的人根本不知道它可能占总账单的10%以上。
第二类是闲置的弹性IP和负载均衡。很多团队给实例绑了弹性IP，实例释放了，IP却没有释放，每个闲置的IP都在产生费用。负载均衡即使没有流量，只要没有被删除，按小时计费也不会停。
第三类是早期创建的快照。有人可能忘了某个账户里几块已经删除的EBS卷还挂着历史快照，这些快照看起来单个不大，积少成多之后金额相当可观。快照费用在账单里体现为EBS Snapshot，不看明细根本发现不了。
花半天时间把这些历史包袱理清楚，就已经值回票价了。这里可以分享一个我的操作习惯：在Cost Explorer里把时间范围拉长到近6个月，按资源ID看趋势。如果一个资源的支出连续多个月高居不下，但负责人已经说不清它在跑什么业务，那它大概率就是首先要治理的对象。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第一招：计算资源向“实际需求”对齐
计算资源是绝大多数AWS账户里占比最高的支出，这也意味着它的优化空间最大。我把计算资源的优化拆成两个层面：一是为长期运行的实例找到更经济的买单方式，二是让实例的规格和数量动态匹配真实业务需求，而不是被动地为“高峰流量”付全额账单。
2.1 先给EC2做一次“体检”
动手调任何配置之前，先给现有EC2做一次资源利用率体检。标准做法是利用CloudWatch的CPU利用率指标，连续观察至少两周。为什么要两周？因为很多业务有周末和工作日的差异，只看一周容易漏掉周期规律。
具体操作时，在EC2控制台选中实例，点“监控”标签页，就能看到CPUUtilization的曲线。如果你想要更精确的分析，可以用以下命令批量拉取所有实例过去14天的平均CPU使用率：
bash复制aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-xxxxxxxx \
--start-time $(date -u -d '-14 days' +%Y-%m-%dT%H:%M:%SZ) \
--end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
--period 86400 \
--statistics Average
观察结果后做一个简单归类。CPU平均使用率长期低于10%的实例，属于典型的资源浪费；低于30%且波动不大，可以评估降配；频繁冲到90%以上且有规律的业务高峰，则适合引入弹性伸缩而不是简单扩容。这样的分类并不是拍脑袋，而是基于真实数据的决策依据。
内存指标要特别注意，CloudWatch默认不采集内存使用率，需要装CloudWatch Agent才能看到。我给客户做体检的时候，经常遇到CPU很低但内存已经快满的实例。这种情况不能只看CPU做降配，否则会引起内存溢出。内存密集型的应用，如果CPU长期空闲但内存使用率高，可能需要考虑调整实例系列，换用内存型实例，或者做应用层优化。
2.2 用Savings Plans和预留实例锁定折扣
市场上很多降本文章都在讲如何关停实例，其实云厂商设计的购买模型本身就是最大的折扣来源。AWS的Savings Plans和预留实例，本质上都是“你用承诺用量换折扣”。以常见的m5.large按需价格为例，如果承诺1年期Savings Plans，折扣通常在20%到30%，如果承诺3年期且全预付，折扣能达到40%以上。折算下来，光是把长期稳定运行的实例切到Savings Plans，总账单就能降接近两成。
我观察到很多团队没有用这个模型，原因是担心“承诺用量会绑死自己”。实际上Savings Plans非常灵活，它按每小时承诺金额来计费，比如你承诺每小时10美元，无论你后面是换实例族、换地域（同一区域范围内）还是升级到容器，只要小时承诺金额内的用量都能享受折扣，超出部分按需计费。这已经比传统预留实例要灵活得多。
在操作层面，可以先从Cost Explorer的“Savings Plans建议”入口进入，AWS会根据你过去7天或30天的使用情况，给出一个建议的小时承诺金额，并估算出潜在节省。如果你是第一次购买，我建议先按建议金额的50%到70%购买，留一部分缓冲空间，跑两周后如果发现覆盖比例太高再调整。
另外要提醒一下，购买Savings Plans是账户级行为，生效后会自动应用到账户内所有匹配的实例，不需要手动绑定。这一点给运维减少了很多工作量，也避免了“买了RI但忘了挂到实例上”的低级失误。
2.3 用弹性伸缩和自动开关机削峰填谷
业务流量的真实画像往往是波动的，电商类的白天高夜间低，数据分析类的上班时间高下班后低，而很多企业却习惯用一台固定规格的实例扛住所有时长，这是对成本最大的不尊重。
对可以中断的任务型计算，可以直接用Auto Scaling搭配定时策略。比如一个每天凌晨跑批处理的集群，只需要在凌晨两点到五点保持4台实例，其余时间缩容到0台即可。配置方式是在Auto Scaling Group里选择“根据计划调整实例数量”，然后按UTC时间创建多个scale action。实际操作时注意时区换算，AWS控制台里的时间默认显示为UTC，如果你在中国时区想设定的是“每天凌晨2点扩容”，要填写的实际是UTC时间18点，这个细节我见过不少人踩坑。
对于有状态应用或数据库之外的Web服务，一个比较稳健的模式是“最小容量+按CPU伸缩”。在AWS Auto Scaling里设置最小实例数为1台，最大实例数为5台，伸缩策略选择“Target tracking”，目标CPU利用率设到60%到70%。这样平时流量低时只跑1台机器，流量上来后系统自动扩容，流量下去又开始缩容。实际运行中，这个模式几乎能让计算成本与业务量做到同步变化。
“自动开关机”这个思路也能用在非生产环境。很多公司的测试环境、灰度环境机器是7乘24小时运行的，但真正使用时间只有工作日的早十点到晚六点。为什么不尝试给它们做定时关机？方式是给实例加一个由EventBridge（事件桥）触发的Lambda（函数计算）定时任务，或者使用Instance Scheduler这个官方解决方案，按Tag识别需要关机的实例，在指定时间执行stop和start操作。仅是测试环境这一项，很多客户就省下了30%以上的非生产支出。
2.4 不要只用按需实例扛生产流量
很多架构师有一个认知误区，觉得生产环境必须全部使用按需实例才安全，稍微省点钱就容易被扣上“稳定性堪忧”的帽子。实际上AWS的Spot实例这些年已经非常成熟，在架构支持容错的前提下，它完全可以承担很大一部分生产流量。
所谓的Spot实例，本质是AWS把闲置计算容量以折扣价放出来，价格通常只是按需的10%到40%，但有一个核心约束：当AWS需要回收这部分容量时，会给出两分钟的中断通知。对于无状态应用，比如Web后端、API服务、数据处理任务，两分钟足够把流量切换到其他节点。利用Spot实例的正确姿势是搭建一个混合容量组：其中一部分是按需实例作为“底座”，承担稳定流量，另外一部分是Spot实例作为“弹性部分”，价格便宜又能随时替换。
要让这个架构跑起来不费心，最简单的方式是创建EC2 Auto Scaling Group时，在购买选项里勾选“请求混合实例”，设置按需实例占比20%，Spot实例占比80%，再配上多实例类型。AWS会自动在所有符合条件的实例类型里挑选便宜的Spot容量。这套方案我在很多项目里实践过，能用相当于按需六七折的成本扛起同样的流量。
需要特别留意的一点是，Spot实例适合“可以重试”的业务，不适合数据库这类有状态服务，也不适合跑那种执行到一半中断就会产生脏数据的任务。判断一个系统适不适合用Spot，核心标准只有一个：实例被回收后，业务能否自动恢复或者由其他节点接管。如果答案不确定，那就把它放在开发和压测环境里先用起来，积累经验后再逐步扩大范围。
3. 第二招：存储成本治理，把“沉淀资产”盘活
存储费用通常不如计算费用那么扎眼，但它就像房间里慢慢堆起来的杂物，平时看不见，等你意识到要清理的时候，已经占了相当大的空间。这部分的优化逻辑不是照搬计算的思路，而是重新审视数据的“温度”和“生命周期”。
3.1 S3存储分层是成本治理的第一站
S3的费用模型由存储容量、请求次数、数据取回三部分组成。大部分团队创建存储桶时习惯使用S3标准存储，然后不管不问。标准存储单GB价格虽然不高，可一旦数据量到了几十TB甚至上百TB，月费就会变得非常可观。而实际上，很多存储在S3里的数据是日志、备份、历史归档，几个月都不会被读取一次。
AWS本身提供了从标准到低频、到智能分层、到Glacier（归档存储）的完整层级。把不常访问的数据挪到S3 Glacier Instant Retrieval或Glacier Flexible Retrieval，单位存储成本能便宜很多。但这里有一个决策点：数据迁移后如果仍然需要高频访问，加上取回费用可能反而更贵。所以我的建议是先用S3 Analytics这类分析工具观察存储访问频率，或者直接根据业务经验判断。
对大多数场景，直接配置一个生命周期规则就能完成自动迁移。比如在S3控制台选中存储桶，点击“管理”里的“生命周期规则”，创建规则后选择“为此规则作用于桶中的现有对象”，然后用前缀或标签指定需要分层的数据目录。配置示例可以是：
logs/前缀下的对象，30天后转为S3 Standard-IA（低频访问）logs/前缀下的对象，90天后转为S3 Glacier Instant Retrievalbackups/前缀下的对象，180天后转为S3 Glacier Flexible Retrieval- 超过365天的日志对象直接过期删除
这套规则配置完成后，每天AWS都会自动执行，不需要人工干预。如果嫌规则颗粒度太粗，还可以在前缀里加日期目录，例如logs/2025/01/之后做差异化的策略。配置生命周期规则前一定要先确认业务侧是否还有合规留存需求，避免把需要长期留存的财务数据过早转入归档层。
3.2 EBS卷和快照是账单里的“慢性病”
在给客户做成本分析时，我几乎总能发现一批已经挂载到实例上、但实际IO压力极低的EBS卷。比如一台实例的数据盘买了2000GB的通用型SSD，实际只用了不到100GB，却按照2000GB在计费。还有一些实例删除后，当初挂载的数据盘没有跟着删除，成了一块“孤儿卷”，每月照常计费。
治理动作分两步。第一步，利用EBS控制台的“监控”功能查看Volume的使用量，把那些平均IO延时很低、使用量却很大的卷找出来，和业务方确认这块盘上的数据能否迁移或压缩。第二步，直接搜索所有状态为available（未挂载）的卷，这些就是孤儿卷。如果确实没有使用需求，建议先创建快照做备份，然后删除卷。
快照的问题同样隐蔽。EBS快照费用按实际存储的数据量计费，增量快照机制意味着每次修改都会新增数据块。很多人定期做快照，却从不清理历史快照，几年下来快照总量可能比原始卷还大几倍。我的习惯是设置一个快照生命周期策略：每天一份快照保留7天，每周一份保留4周，每月一份保留6个月，超过期限的策略自动删除。这个策略既保证可恢复性，又不会让快照费用失控。
3.3 数据传输和跨区域复制前要算清楚账
存储治理经常容易漏掉一个环节：数据流动的成本。S3跨区域复制本身不产生复制传输费，但复制过去的对象会产生目标区域的存储费；如果你通过公网下载或第三方工具同步数据，那就要支付真金白银的流量费。
实际项目中，我遇到最典型的问题有两个。一是为了“容灾”把整个S3桶做了跨区域复制到另一个区域，结果另一个区域的桶根本没人访问，存储费白交了一年。另一个是把大量日志同步到第三方日志平台或本地机房，流出一路都是数据流量费。
关于前者，要重新思考容灾的策略，很多日志数据、临时数据并不需要跨区域复制，只需要给存储桶开启版本控制，再配合生命周期规则把历史版本转归档即可。关于后者，如果数据必须外送，可以考虑开启S3 Transfer Acceleration或走专线而不是公网，也可以跟云厂商协商采用特定的传输方案降低成本。大多数时候，只要大家意识到流量费在账单里有多重，就会重新审视“所有数据都要传输”这个前提。
3.4 数据库存储也要纳入治理范围
数据库存储往往隐藏在RDS和DynamoDB费用里，也是最容易被当成“铁板一块”的资源。RDS的费用包括实例计算和存储两部分，而存储的计费方式是按分配的容量而非使用量。分配存储时如果为了图省事给了500GB，即使只用了50GB，依然按500GB收钱。对RDS做容量规划时不要一次分配过大，可以先用较小的存储卷观察使用增长趋势，再做在线扩容。RDS本身支持存储自动扩容，同时也支持手动调整，预留余地不像以前那么重要。
RDS自动备份默认保留7天，如果业务对恢复时间要求不高，7天的备份保留足以应对绝大多数故障。很多人把备份保留期设成30天甚至更久，这种配置在账单上会增加存储费用。不要把RDS的自动备份当成长期归档工具，长期备份需求应该通过手动快照加生命周期策略来处理。
DynamoDB的成本大头在读写容量单位。很多团队为了应付偶发的峰值流量，给表配置了很高的预置容量，平日里大部分时间处于浪费状态。对这类表，最简单的处理是切换为按量计费模式，让价格随实际读写量波动；如果业务流量模式比较规律，可以使用DynamoDB的Auto Scaling设置目标利用率。无论选哪种，都比常年预置高规格要便宜得多。
4. 第三招：用架构手段“抹掉”不必要的成本
前面的操作大多是围绕现有资源的“调优”，但当一个系统的成本问题积重难返时，架构层面的重构往往是更彻底的解法。这一招不追求小修小补，而是通过改变运行模式，让成本结构从根本上发生改变。
4.1 把低频和突发型负载挪到Serverless上
传统的EC2部署模式，无论业务量多低，实例都在运行，都在产生费用，这种固定成本在业务量不稳定时尤其难受。Serverless模式最吸引人的点就是把“容量规划”的活儿交给了云平台，你只需要为实际发生的请求和调用付费，完全没有闲置成本。
适合做Serverless化改造的常见场景包括：定时任务、Webhook接口、内部工具后台、轻量API网关。举个例子，我给一个企业做过一次改造，他们的定时数据处理任务是部署在一台常年运行的t3.medium实例上的，每五分钟跑一次，每次只跑几十秒。这台机器每个月的固定费用加存储费用约合几百元，而如果把这个任务改造成Lambda函数，按调用次数加运行时长计费，每个月的开销基本可以忽略，哪怕把执行频率提高到每1分钟一次，成本也仍然只有原来的几十分之一。
架构改造时注意不要陷入全盘Serverless的执念。对于长连接、实时计算或超大内存需求的应用，传统实例仍然是合理选择。我的判断标准很简单：如果一个服务“有调用才需要运行”，那么没有理由让它7乘24小时地空转。如果是长期高并发的固定负载，Serverless反而可能更贵。这背后是计费模型的不同，评估时不能凭感觉，最好用实际QPS和资源消耗做推算。
4.2 容器化提高资源利用率
对一批需要长期运行的服务，容器化可以相当直接地压低成本。举个例子，原来一个业务拆了三个服务，分别跑在三台EC2上，每台机器利用率可能都只有10%到20%。如果把这几个服务容器化，部署到ECS（Amazon Elastic Container Service）或EKS（Amazon Elastic Kubernetes Service）集群上，共用三台底层节点，资源利用率就可能提升到50%甚至更高，相应的底层节点数量可以从9台缩到3台。
这里要插一句，ECS或EKS本身没有额外软件费用，你只需要为底层EC2节点付费。如果你有测试环境想跑一套小集群，甚至可以用Fargate（无服务器容器）这种按需付费的算力模式，闲时没有流量时费用趋近于零。容器化的收益并不只是成本，它同时还带来了发布效率的提升，是一个“技术上顺手、成本上受益”的双赢选项。
不过容器化也有门槛。团队如果对容器编排工具不熟，贸然引入EKS可能会增加不少学习成本和运维故障。我更推荐从ECS开始，它比EKS简单很多，没有控制平面费用，又有弹性的服务发现和负载均衡集成，适合大多数中小团队。等团队对容器有了手感，再考虑往Kubernetes生态迁移。
4.3 合理使用托管服务替换自建组件
很多自建组件其实是在“用自己的电费养一台发电机”，如果只是为了偶尔的备用电源，完全可以直接接电网。架构上的对应关系是：自建的Elasticsearch集群、自建的Redis集群、自建的Kafka集群，可能消耗了大量EC2资源，但使用的深度和运维的能力又跟不上。
托管版Elasticsearch（Amazon OpenSearch Service）、托管版Redis（Amazon ElastiCache）、托管版Kafka（Amazon MSK）看似单价更高，但它们省去了底层实例的过度冗余、省去了监控告警的建设成本、省去了故障恢复的人力和时间成本。算总账时，托管服务多数情况下并不比自建贵，因为不用为“高可用”冗余这些事去保留过多的缓冲节点。
举个我自己经历的例子。以前我维护过一个自建Redis集群，为了保证高可用，采用了三主三从的架构，共六台实例。后来业务访问量下降，但出于“不敢动”的心理一直没缩，每个月光算力成本就这么持续烧着。后来下决心迁移到了ElastiCache的单分片主从模式，流量完全够用，成本直接降了一大截，运维负担也几乎清零。很多成本问题的根源不是云厂商定价高，而是架构师习惯性地给系统预留了远超需求的保险量。
4.4 架构成本建模：让每一分钱都有归处
架构层面的优化不能只靠一次性的重构，要让成本可持续，需要建立一套“成本建模”的思维。所谓成本建模，就是在新服务设计阶段，就估算它每个月大概要花多少钱，把成本当成和性能、安全同等重要的架构设计约束。
具体的建模方式可以从一个简单的表格开始：业务预计QPS是多少，平均请求处理时间是多少，数据库读写比例是多少，有没有周期性任务，需要保留多少天的日志和备份。这些参数一旦确定，就可以在AWS计算器里把每种服务的月成本估算出来。在架构评审时，让开发团队把这个估算表拿出来和大家对一遍，常常能提前避免很多成本隐患。
我记得有一个项目，业务方原本计划用六台较大规格的EC2集群支撑一组内部API，赶在架构评审前用成本模型算了一笔账，发现业务量根本用不到一半的容量，最终把方案调整成了三台中等规格的机器加一个自动扩缩容策略。这时还没开始迁移，甚至还没有创建任何资源，成本就已经被优化了。这个阶段省下的钱，比事后做任何账单治理都更省力。
5. 构建成本治理的长效机制，防止反弹
降本一时爽，反弹火葬场。如果你只是做一次清理，但没有建立长效机制，三个月后账单大概率会重新涨回去。很多团队问我，为什么优化完过一阵成本又上来了？我的答案往往是：你缺的不是技术手段，而是成本治理的“流程”。
5.1 把“预算告警”做成强制约束
前面提到过用AWS Budgets创建预算，这里我建议更进一步，把预算告警跟团队的工作流打通。比如在预算达到80%的阈值时，除了邮件通知，还可以通过Amazon SNS触发一个Webhook，直接发送到企业微信或钉钉群。这样一来，成本超标不是CTO或财务一个人看到，而是所有研发骨干都能在群里实时感知。
更重要的是，把预算和权限联动起来。AWS身份服务IAM可以基于标签限制用户创建非生产资源，也可以在Cost Explorer里只读查看成本。对于成熟团队，还可以尝试通过服务控制策略，直接禁止在未打Tag的情况下创建EC2和RDS。这种技术手段比苦口婆心地发通告有效得多，因为它是流程层面的硬约束。
5.2 把FinOps责任落到具体人头
成本问题最怕“人人有责”最终变成“人人无责”。我见过很好的一个实践方式，是把月度账单按Cost Allocation Tag拆分后，发给每个团队一份自己的成本报表。当团队看到自己名下那个飙升的EC2费用时，很多优化动作不需要高层推动，他们自己就会去排查。
账目拆分落地时，我建议每种Tag组合对应一个“成本中心”。比如Team=A，Project=order-service，这两者的组合就是一个成本中心。财务在月底对账时，可以通过CUR快速导出各成本中心的花费，而不是去各个产品线问“你们这个月是不是开新机器了”。让每个团队在财务层面“自治”，是FinOps落地中最关键的一步。
要完全落地这个机制，需要在资源创建阶段就把Tag当作必需步骤。实际操作中，我会建议在代码仓库里放一个标准的Terraform模块，模块内部强制所有EC2、RDS、S3的资源都带上Tag，没有Tag直接报错。这样“打标签”就不再依赖个人自觉，而是被固化到基础设施即代码里。
5.3 定期做成本回顾和安全冗余清理
成本治理不是一次性项目，需要周期性运行。我服务于客户的时候，会建议他们按月度开展一次“成本回顾会”——时长不长，30分钟左右。会上只做四件事：一是看总账单环比变化，二是找出涨幅最大的前五个资源，三是由资源owner解释上涨原因，四是确定下个月要执行的优化动作。这套机制运转起来后，成本基本不会再出现“年底才发现超支”的被动局面。
同时在回顾会中，要把“安全冗余”纳入常态化检查。比如，每次业务大促前申请的临时容量，活动结束后是否及时释放了？每次做容灾演练时开启的跨区域复制，演练后是否关闭了？每次测试环境扩出来的机器，用完有没有按计划回收？这些都是“一次性动作”，如果没有治理机制兜底，很容易变成长期支出。不要高估团队的自律性，低估账单的复利效应，这是我在成本治理项目中最深的感受。
5.4 用基础设施即代码固化降本规则
最后一步是把所有人工操作沉淀为代码。比如用Terraform管理EC2自动开关机、用CloudFormation部署带生命周期规则的S3桶、把Budget模板放在代码仓库里统一管理。有了基础设施即代码这层保障，每一套新环境创建出来时，就自带成本治理的配置。新来的同事不会因为不知道规则而开出一台超规格的实例，也不需要资深架构师一遍遍重复审核。
以Terraform为例，一个最基础的CloudWatch告警加Budget配置，可以用几十行HCL写清楚。后续如果某个团队要开新项目，直接复制模板，修改预算数值和Tag，apply一下就能完成基线配置。降本规则一旦进入代码库，就变成了组织的“肌肉记忆”，不需要靠人去盯。
6. 常见问题与避坑心得
做成本优化时，经常收到这样或那样的问题。有些问题比较基础，有些则需要给出提醒，这里统一做一次梳理。
为什么我照着文章做了，成本只降了不到10%？
通常有两个原因。第一是没有找到真正的大头资源，只是在无关痛痒的小项目上折腾，要回到第1节的成本分析思路，先确认自己账户里支出最高的前三项服务到底是什么。第二个原因是只做了资源清理，没有做购买模型优化。长期持有的EC2和RDS不买Savings Plans，相当于每年默许多付了20%到40%的“忠诚税”。
调整EC2配置会影响线上业务吗？
任何变更都有风险，但可以控制。降配前先看两周的监控数据，确认峰值CPU和内存都在安全范围内，再做变更。变更时不要直接resize，而是在生产环境之外先启动一台同规格的新实例，验证业务正常后再切换。如果业务使用了弹性IP，直接绑定到新实例即可；如果用ALB，只需把新实例注册到目标组，从旧实例摘除，整个过程能做到接近零停机。
Spot实例被回收了怎么办？
这是所有使用Spot的人最关心的事。在Auto Scaling Group的容量分配里设置按需实例作为最低池子，Spot实例作为弹性池，当某个Spot实例被回收时，ASG会自动尝试从其他可用区或实例类型里补位。如果你的应用是无状态的，面向用户的流量被ALB分摊到其他节点；如果是任务型应用，最好配合SQS队列做消息缓冲，任务执行到一半断了也没关系，重启后能继续消费队列里的消息。
手动删除EC2实例会不会把数据弄丢？
如果实例本身有数据盘，在终止实例前要确认数据盘是不是设置了DeleteOnTermination属性。如果设置的是保留，实例终止后卷会变成available状态，数据不会丢，但会产生费用。如果你自己不确定数据状况，先在EC2控制台给实例创建一份AMI镜像或快照，再执行终止操作，给自己留一条安全的后路。删除EBS卷和快照前也同理，先确保数据有冗余副本，这和买保险是一个道理。
成本优化会不会影响系统稳定性？
如果正确地做，稳定性反而更高。弹性伸缩让系统在流量上升时及时扩容，避免了固定容量下流量突增导致的资源耗尽；架构改造通常伴随着代码的瘦身和依赖的简化，容错能力并没有降低。但如果只是为了省钱而把生产实例降到一个很低的配置，或者在没有自动恢复机制的情况下粗暴关闭资源，那确实会带来稳定性风险。所有降本动作都要有一个前提：不牺牲系统的高可用和可扩展性。
最后分享一点个人体会。云成本优化这件事，最难的永远不是技术，而是团队是否有持续关注成本的决心。云本身是弹性的，弹性的意思是业务在增长时成本同步增长，业务在下降时成本也能同步下降。实际上大多数团队的账单曲线只体现了弹性增长的那一半，下降的那一半因为人的惰性和管理的缺位被吃掉了。把治理机制建立起来，把每个月的账单当成产品数据一样去分析，降本根本不需要什么惊天动地的黑科技。按文中这三招踏踏实实走一遍，节约四成成本并不是一个夸张的目标。