1. 成本优化这件事2026年为什么更难也更重要做了这么多年 AWS 咨询和代理服务我见过太多客户在月度账单出来的时候倒吸一口冷气。平时开发测试跑得欢月底一看数字比预期高出三四成然后火急火燎来找我们“降本”。说实话AWS 成本优化从来不是什么新话题但 2026 年这个时间节点上事情确实起了一些变化AI 类负载快速增多GPU 实例一开就是每小时几十美元数据量越来越大S3 存储桶里堆了几年没动过的文件再加上各家云厂商的计费口径越来越细账单上密密麻麻的收费项目非专业人士根本看不明白。我说的“难”主要难在三个方面。第一资源规模变大了。以前一个中小型项目可能就是十几台 EC2现在动不动就是几十个服务、上百个函数、跨区域的数据同步要理清楚每一笔钱花在哪本身就是一个工程问题。第二业务变化更快。尤其是互联网行业的客户流量峰值和低谷的差距可能达到十倍以上如果还用传统“按峰值买机器”的思路成本一定压不住。第三厂商的折扣体系越来越复杂。Savings Plans、预留实例、Spot 实例、资源包、免费额度……每个产品都有自己的计价逻辑组合起来更是千变万化没有专业经验的人很容易买错或者买多。那“更重要”又怎么说2026 年的企业 IT 预算普遍比前几年更紧张。降本增效已经不只是财务部门的 KPI更是技术负责人向上汇报时必须拿出来的成绩单。换句话说能不能把云成本控制住很多时候直接决定了项目的生杀予夺。我们团队这几年做 AWS 成本优化前前后后帮客户省下来的钱换算成月均也有几十万美元。这篇文章我想把最核心的五条策略完整梳理一遍包括底层逻辑、具体操作步骤、参数怎么算以及那些我们踩过的坑。不管你是自己管理 AWS 账号的架构师还是帮客户做代维的代理商这篇内容应该都能派上用场。先交代一下背景下面讲的策略全部基于我们实际服务过的客户案例覆盖了电商、SaaS、游戏、金融科技等行业涉及的账号从小型创业公司月账单几千美元到中型企业月账单几十万美元都有。具体数字我会做脱敏处理但计算方法和判断逻辑完全保留。2. 策略一用承诺型折扣锁定基础成本——Savings Plans 与 RI 的选择与计算2.1 Savings Plans 和 RI 到底怎么选很多客户第一次接触 AWS 成本优化听到的第一句话往往是“买预留实例”。这句话没有错但非常不完整。AWS 现在主推的承诺型折扣产品有两个一个是老牌的 Reserved Instances简称 RI另一个是后来推出的 Savings Plans简称 SP。两者都能帮你换取更低的小时费率但适用范围和灵活度差异很大选错了反而会绑住手脚。先看 Compute Savings Plans。它的核心优势是“按每小时承诺金额付费覆盖范围横跨所有 EC2 实例包括不同家族、不同规格、不同地域甚至覆盖 Fargate 和 Lambda”。打个比方你承诺每小时花 10 美元那么无论你这一天跑的是 t3.medium 还是 m5.large是美东还是美西系统都会自动按折扣价计算。这种弹性对于业务变化快的团队来说非常友好我们给客户做方案时默认首推的就是这种。再看 EC2 Instance Savings Plans 和标准 RI。它们绑定的是“特定实例家族 特定地域”比如你承诺在 us-east-1 区域使用 m5 家族实例多少小时折扣会比 Compute SP 再深一点但换来的代价是如果你想把 m5 换成 c5或者把资源搬到另一个区域这些承诺就浪费了。标准 RI 还要更死板一些连实例大小都得选好虽然现在也有大小灵活度但仅限同家族同地域。实操中我的建议很简单如果你能比较准确地预测未来 1-3 年的 EC2 用量且底层工作负载相对稳定可以考虑 EC2 Instance SP 或 RI如果业务波动明显或者正在做容器化、Serverless 改造无脑选 Compute Savings Plans 大概率不会错。2.2 购买比例的量化计算方法光知道选哪种不够最关键的是算清楚“买多少”。买少了折扣覆盖不全买多了超出实际用量的部分就是纯浪费。下面分享一套我们内部常用的计算流程。第一步从 Cost Explorer 导出过去 30 天建议 90 天更平稳的 EC2 按需费用数据按“实例家族 地域”维度聚合。第二步按业务重要性把实例分为“基础底座”和“弹性扩展”两类。基础底座是 7×24 小时必须开着的比如数据库、核心应用服务弹性扩展是白天跑晚上关、或者根据流量自动伸缩的那部分。第三步基础底座的累计小时数 × 对应实例的小时价格得到月度承诺金额。为了安全起见建议在计算值上打个 9 折留出 10% 的余量给突发扩容。第四步把月度承诺金额除以 730一个月的平均小时数得到每小时承诺值这就是你要购买的 Savings Plans 的小时承诺。举个例子。某客户有 10 台 m5.large 长期运行按需单价约 0.096 美元/小时10 台一个月的费用是 0.096 × 10 × 730 700.8 美元。按我们的方法取 90% 后是 630.72 美元/月则小时承诺设为 0.864 美元/小时。再加上另一部分 c5 家族服务器也照此叠加。最后统一折算成一份 Compute SP 或几张 EC2 Instance SP。每次我讲完这套算法都会有人问那我用 Cost Explorer 的“Savings Plans 推荐”功能直接买行不行行但我不建议完全照搬。AWS 的推荐算法基于历史用量默认覆盖你所有的按需开销往往倾向于给你算出“买满”的建议。如果你照单全收可能把本应用来跑 Spot 的临时负载也包进了承诺里反而多花钱。2.3 实操心得先买 1 年还是 3 年要不要混合关于承诺期限AWS 给出了 1 年和 3 年两种选项3 年折扣更深通常比 1 年再多个 5%-10%。我们的经验是除非业务非常稳定且已经验证过至少 6 个月的用量趋势否则首批建议买 1 年。原因是云技术演进太快很多客户买了 3 年 RI结果第二年就开始容器化改造原来承诺的实例类型用不上了退出、转换都有各种限制非常被动。1 年期的灵活度高很多代价只是折扣少几个点综合来看其实是更划算的风控方案。另外一个容易忽视的点是“有效期错配”。有些客户为了追求最低折扣把所有承诺都集中放在一个时间段比如全部在 1 月 1 日生效。问题来了如果这时候业务突然缩水你没法减少承诺如果业务涨了你又得补买按需实例等于两头吃亏。我们的做法是“阶梯式购买”比如把总承诺金额拆成三份分别在 1 月、4 月、7 月生效这样即使后续用量发生变化也只是一部分承诺受影响不至于整体翻车。注意Savings Plans 购买后无法取消只能通过 AWS Support 申请部分退款且条件苛刻。所以购买前一定要用最近 90 天的真实用量数据做测算不要拍脑袋。3. 策略二弹性伸缩不是“配置项”而是成本架构的核心3.1 自动伸缩组的正确打开方式很多客户觉得我已经用了 Auto Scaling Group怎么账单还在涨问题往往出在伸缩策略的配置上。默认情况下AWS 的 Auto Scaling 有两种指标CPU 利用率和网络流量很多人选一个就完事了。实际上只用 CPU 指标有一个常见漏洞——大部分应用是 IO 密集型或内存密集型CPU 可能常年只有 20%但内存已经快满了。这时候伸缩组判断“负载不高”不帮你扩容结果用户响应变慢或者反过来伸缩策略太敏感稍微一点流量波动就加机器然后流量回落了又不及时缩成本自然飙升。我的建议是至少做两件事。第一自定义伸缩指标。用 CloudWatch 收集更贴近业务真实负荷的信号比如队列深度、并发连接数、应用层响应时间。通过 PutMetricAlarm 创建自定义指标告警挂到 Auto Scaling 策略上比默认指标可靠得多。第二设置冷却时间和缩容保护。冷却时间Cooldown建议默认 300 秒不要改得太短否则容易出现“抖动扩容”—刚启动的实例还没开始处理请求新一轮扩容又触发了。缩容保护则要小心不要直接基于“过去 5 分钟 CPU 低”就立刻缩容而应该看过去 15-30 分钟的趋势避免把还在处理长任务的实例杀死造成请求失败然后业务方为了稳定又去手动加固定实例成本问题就回到了原点。这里有一个非常多客户会踩的坑Auto Scaling 组里设了“最小实例数 2”。理由是高可用。但如果你只跑一个非关键环境或者所有节点都无状态且前面有负载均衡做故障转移这个最小实例数其实是可以降到 1 的。一台 t3.large 一个月大约 60 美元看起来不多但几十个环境加起来就是一笔不小的开销。我们也服务过一家客户他们的测试环境有 30 多个微服务每个服务都做了双副本结果一算光是测试环境每个月就浪费了两三千美元。后来我们帮他们把非核心服务的最小副本数改为 0允许缩容到零配合定时任务在早晨自动扩容晚上自动缩容成本直接降了 60% 以上。3.2 用 Lambda 和 Fargate 干掉“睡眠中的服务器”我在做成本审计时最喜欢看的就是那些“7×24 小时运行但实际每天只用 2 小时”的服务器。一本书读不读你放在书架上不花钱一台服务器开着不管有没有流量每一秒都在计费。这类负载如果应用架构允许最好的归宿就是 Serverless。拿定时任务来说。很多团队跑报表生成、数据同步习惯性开一台 t3.small 挂着 cron。其实用 Lambda EventBridge 定时触发代码写好之后一个月省下来的钱非常可观。t3.small 按需价格大约 0.0208 美元/小时一个月 15 美元一年 180 美元。换成 Lambda 跑同样频率的定时任务可能一年就几美元。差距不是一点点。还有一类是偶尔才有请求的 Web 服务。以前必须用 EC2 的现在完全可以用 Fargate 或者 App Runner 部署。Fargate 的好处是按秒计费不运行时不花钱。当然Fargate 的单价按 CPU/内存算比同等 EC2 实例的“标价”要贵一些但它有内置的伸缩和免运维优势。我们一般建议客户这样做评估如果负载稳定且常年满负荷运行EC2 加 RI/SP 可能是总成本更优解如果负载有峰谷、或者一天内大部分时间处于低流量Fargate 缩容到零反而更省钱。顺便提醒一下容器镜像的构建方式。很多客户在 Fargate 上跑容器为了让实例尽快启动非得把镜像打到几个 GB。镜像大不影响 Fargate 的计费但会导致启动慢、扩容不及时最后业务方为了保险又去提高了常驻实例数。这里面的隐性成本也需要重视。3.3 Spot 实例能省 60%-90%但你必须接受“可能被回收”Spot 实例在成本优化里的地位非常特殊。它的价格通常只有按需实例的 10%-40%如果你跑的负载是容错的、可中断的用 Spot 几乎是“白嫖”计算资源。但很多客户第一次接触时很抗拒担心实例被回收影响业务。这种担心合理但完全可以靠架构设计来规避。实操中我们会把工作负载分成三类第一类无状态的批处理任务比如大数据分析、视频转码、爬虫抓取这类任务随时可以重跑直接上 Spot。第二类有状态但对中断容忍度较高的任务比如带断点续传的数据处理配合 Spot 实例的停用通知两分钟预警把中间状态持久化到 S3实例被回收后从断点恢复即可。第三类核心在线业务比如数据库、API 网关后面的应用节点这类不建议用 Spot但可以考虑混合部署——比如在 Auto Scaling 组里同时配置 Spot 和按需实例让 Spot 先承担扩展流量按需实例作为安全垫底。另外还有一个选型细节Spot 实例的池子相同实例类型 可用区非常多价格时刻在变。如果你在启动模板里指定了一个非常冷门的实例类型可能经常拿不到资源反过来如果你指定多个实例类型和可用区组合并且设置了容量再平衡Capacity Rebalancing拿到的概率会大幅提升。我们在一个数据 pipeline 项目里把 80% 的计算节点切到 Spot整体成本下降了接近 70%而且跑了大半年最严重的回收事件也只是一次性重跑了两个小任务完全没有伤筋动骨。4. 策略三存储成本——那些静悄悄累积的 S3、EBS 和快照费用4.1 S3 存储分层的生命周期管理S3 的计费看着简单——每 GB 多少钱——但真正让账单膨胀的往往是数据量本身以及你为“很少访问的数据”付了“经常访问的价格”。很多客户的桶里存了大量日志、备份、历史订单数据访问频率极低却都放在 STANDARD 存储级别每 GB 每月大约 0.023 美元。听起来不贵但你算一下如果有 100 TB 这样的冷数据一个月就是 2300 美元一年接近 2.8 万美元而这些数据可能一整年都没人碰过。正确的解决思路是配置 S3 生命周期策略让数据按访问频率自动流转。我们常用的一条规则链是这样新写入的数据先放 STANDARD保证最近的业务访问速度。30 天后如果未被访问自动转为 S3 Standard-IA低频访问存储单价降约 40%但按读取量额外收费。90 天后转入 S3 Glacier Instant Retrieval 或 Glacier Flexible Retrieval存储单价进一步降低但取回数据需要几分钟到几小时。180 天后如果明确是备份归档类数据可以放进 Glacier Deep Archive每 GB 每月只要 0.00099 美元是所有级别里最便宜的。这里的核心是“从业务价值反推数据保留策略”。建议你先给公司内部的数据分个级核心生产数据、合规审计数据、临时中间数据、废弃残留数据。不同级别的数据设计不同的流转路径然后落到生命周期规则里。我们有一次帮客户梳理光是库存里一个 60 TB 的 S3 桶把大量日志从 STANDARD 调成 Glacier Deep Archive 之后月成本直接少了近 70%。4.2 S3 的版本控制和分片上传隐藏开销S3 生命周期能帮你省存储费但如果版本控制没管好坑更大。开启版本控制后每次覆盖写对象都会产生一个新版本旧版本依然占存储空间。很多客户为了数据安全开了版本控制结果忘记设置生命周期清理“非当前版本”于是一年下来桶里堆积了成百上千个旧版本存储量可能是实际业务数据的 5-10 倍。我们的做法是给桶加一条生命周期规则明确“非当前版本的对象在距当前版本 N 天后自动删除”N 通常取 7-30 天具体看你对回滚窗口的要求。这样既保留了版本控制的安全能力又不会让历史版本长期堆积吃掉预算。另一个容易忽视的是 S3 的分片上传Multipart Upload。如果你上传大文件时中间断掉没有调用 AbortMultipartUpload那些未完成的分片会一直在 S3 里以隐藏形式存储并计费。尤其是用命令行工具批量同步数据时失败重试是很常见的事。我们建议定期用 S3 Inventory 结合生命周期规则清理超过 7 天的未完成分片上传。4.3 EBS 和快照最容易被“习惯性配置”浪费的地方说完了 S3再讲块存储 EBS。客户的 EC2 实例通常会挂几块 EBS 卷但很多人在创建实例时随手选了 gp3 甚至 io1/io2 类型也不管实际需要多大的 IOPS 和吞吐量。io1 的单价可能是 gp3 的好几倍。我见过一个客户四台应用服务器全都挂了 io1 卷每块卷配置了 3000 IOPS实际用下来连 500 IOPS 都用不到每个月白白多掏上千美元。这类问题的解法特别简单先用 CloudWatch 查每块卷过去 14 天的平均 IOPS 和吞吐量峰值然后把类型降到 gp3甚至到 st1/sc1 这种吞吐优化型或冷 HDD。gp3 本身已经支持按需调整 IOPS基准 3000 IOPS 免费对绝大多数应用场景足够了。快照成本更是重灾区。AWS 对 EBS 快照收费而且快照是增量存储——你每次打快照新增的数据块会累积但删除旧快照时如果某些数据块还被其他快照引用这部分空间不会释放。很多团队每天定时打快照从不清理半年后快照体积可能是磁盘本身的好几倍。我们的建议是建立快照保留策略比如每天一个快照最多保留 7 个每周一个最多保留 4 个超过的自动删除。配合 Data Lifecycle Manager 设置规则改完之后基本不用人工干预。注意EBS 快照的删除策略和 S3 版本控制逻辑并不一样。快照本身存在“引用依赖”不要以为删除最早的那个快照就一定能释放全部空间。如果项目已经结束、不再需要任何历史快照直接全部删除即可如果还需要某个时间点的恢复能力请至少保留那个时间点的最后一个快照。5. 策略四网络流量成本——AWS 账单里最“无声”的黑洞5.1 搞懂网络费用的计费结构计算费和存储费大家都会盯着看网络流量费却常常被忽略。AWS 的网络计费有几个关键点首先是区域间数据传输比如从 us-east-1 传到 eu-west-1每 GB 大约 0.02 美元双向都收其次是公网出方向流量Data Transfer OUT从 S3 或 EC2 通过公网访问用户每 GB 0.09 美元起步量越大单价越低但这部分费用在很多业务里是刚需很难省掉最后是同一区域内的服务互通流量目前同一 VPC 内走私有 IP 是免费的但跨 VPC、跨可用区、经过 NAT 网关或 Transit Gateway 的流量都有各自的计价。我们踩过的坑里最常见的是“微服务跨可用区调用”。很多高可用架构把应用节点分布到多个可用区这没有问题但如果微服务之间的调用链路没有做就近路由大量流量在可用区之间横跳NAT 网关费用和跨 AZ 数据传输费用会非常明显。尤其是 NAT 网关它按“每 GB 处理流量”和“每个 NAT 网关每小时”双重计费一个 NAT 网关一个月光固定费就要 32 美元左右流量多了更是笔不小的开销。5.2 用 CloudFront 省钱不只是加速更是降本CloudFront 是 AWS 的 CDN 服务大家通常把它看作加速工具但它同时也是一项非常强的成本优化工具。原因很简单从 CloudFront 出网的流量单价比从 S3 或 EC2 直接出网要低不少。以 2025 年的价格为例S3 直接公网出流量大约 0.09 美元/GB而 CloudFront 出流量大约 0.085 美元/GB量大的时候还有阶梯折扣最低到 0.02 美元/GB 区间。更重要的是如果数据通过 CloudFront 分发源站S3只接收回源请求大部分终端用户请求直接从边缘节点命中S3 的请求费和出网流量费都可以大幅下降。我们优化过一个视频类客户每个月从 S3 直出流量大约 80 TB光流量费就是 7000 多美元。后来把分发全部切到 CloudFront配合对象缓存和范围请求Range Requests支持月度流量费用降到 4000 美元出头同时用户体验还更好了。不过用 CloudFront 有一件事千万注意缓存命中率不能太低。如果你设置了很短的 TTL比如 60 秒或者缓存 key 里带了太多用户特定参数那么大量请求都会穿透到源站这时候 CloudFront 带宽折扣带来的收益就会被打折扣还可能因为请求数增加而多付费用。我们建议在 CloudFront 的 Cache Statistics 里定期观察 Per-viewer 和整体命中率如果命中率长期低于 80%就要排查是不是缓存配置的问题。5.3 区域间流量和 Direct Connect 的使用边界在 2026 年多区域部署已经是很多全球化业务的标配。跨区域传输的流量费用如果不控制一个月下来也不小。我见过一个客户业务主节点在美东灾备在美西每天同步增量日志大约 2 TB。粗算一下2 TB × 0.02 美元/GB 40 美元/天一个月就是 1200 美元这还只是数据同步这一项。措施上无非是三类第一压缩数据以后再传输日志类文本数据的压缩率往往能到 5:1 甚至 10:1直接把同步流量成本降到原来的五分之一第二去掉不必要的实时同步很多场景其实每小时甚至每六小时同步一次就够了不必追求秒级第三如果两地之间的长期传输量大且稳定可以考虑专线服务因为专线的包月费用固定和传输量无关适合常态化、大批量的数据传输场景但对偶尔同步几次的业务来说性价比不高。另外提一句S3 的复制功能有“同区域复制SRR”和“跨区域复制CRR”后者会产生额外的跨区域流量费但目标区域的存储费用不变。很多客户开启 CRR 是为了容灾这个没问题但如果你的数据更新频率极高建议考虑用事件驱动的异步复制方案而不是全量开启 S3 复制这样能显著降低跨区域流量的次数和费用。6. 策略五FinOps 实践——让成本治理变成团队的习惯6.1 用标签、预算和告警把“看不见的钱”变成“看得见的数”前四种策略都是具体的省钱手段但真正能让成本长期不反弹的是建立一套成本治理机制。我们内部管这个叫“FinOps 最小闭环”。第一步就是给资源打标签。标签这个东西听起来简单做起来最容易被忽视。没有标签的资源在 Cost Explorer 里是一团迷雾你根本分不清哪笔钱是哪个项目、哪个团队花的。我们建议客户在账号创建初期就强制推行标签策略Tag Policies最少包含三组标签Project项目名、Environment生产/测试/开发、Owner负责人邮箱。如果已经有存量资源可以用 AWS Resource Groups 和 Tag Editor 批量补打虽然有些历史资源没法完美追溯但至少从当前时间点开始每一笔新资源都有归属。有了标签之后就可以做成本分配报告按项目、按团队去查看各自的月度开销。你会发现一旦成本归属到了具体人头浪费行为会立刻减少一大截。第二步是设置预算和告警。AWS Budgets 支持按成本、按用量、按 RI/SP 覆盖率设置预算并且可以基于标签筛选范围。我们的习惯是给每个项目设置月度预算并配置三种告警阈值达到 50% 通知、80% 紧急提醒、100% 触发停机如果是非生产环境。告警渠道建议接 SNS 到邮件和 IM 群机器人。不要只设一个总预算那样等触发的时候已经来不及调整了。6.2 定期治理节奏月度巡检 季度复盘光有工具没有节奏制度等于空转。我们帮客户建立了一套月度巡检的流程核心是检查六项指标按需 EC2 使用率目标占比低于 30%其余应被 SP/RI 覆盖或用 SpotEBS 卷利用率目标超过 10% 的卷 7 天平均 IOPS 低于 100应降配S3 生命周期策略覆盖情况目标所有桶都应配置至少一条生命周期规则闲置资源检查是否有连续 14 天 CPU 低于 5% 的实例是否有从未被访问的负载均衡器、弹性 IPNAT 网关和未使用弹性 IP后者每个闲置 IP 每月要收大约 3.6 美元积少成多Cost Explorer 里近 30 天费用变化趋势环比增幅超过 20% 的部分要逐项解释原因。季度复盘则更偏“人”的维度哪些资源创建之后一直没有 Owner 认领如何处理哪些项目已经下线但资源没有释放下个季度的容量规划和 SP 购买计划要结合业务预期做一次调整。这其实就是在回答“云成本为什么省下来之后还能保持住”这个问题。成本优化从来不是一次性的项目而是一个反复循环的过程。6.3 代理商的独特优势与建议写到这里我把最常被问到的问题整理一下。首先是“我自己做成本优化和找代理商做有什么区别”。区别在于信息的颗粒度和资源池。代理商因为有多个客户的实践数据对哪些实例类型在哪些区域更便宜、哪些 Savings Plans 组合最划算有更敏锐的直觉。比如某个客户的数据库负载适合 r6i另一个客户的 CI 集群适合 c7g这种匹配经验不经过多个项目的积累是拿不到的。如果你的团队没有专职的 FinOps 人员找代理商做一次季度成本审计大概率是值的。但我也要泼一盆冷水代理商给你的建议不代表你可以完全不作为。成本优化需要业务方提供真实的容量预期和保留策略否则再好的方案也只是纸上谈兵。我们给每个客户做完方案之后一定会拉一个微信群每个月同步账单变化和优化进度确保成本治理不是一锤子买卖。7. 常见问题与排查技巧实录7.1 为什么买了 Savings Plans账单反而变了有些客户开了 SP 之后发现 EC2 的费用明细发生变化单价降低了但总费用没有明显下降。这种情况第一反应是看“覆盖率”。SP 不是按“你买多少就给你多少钱折扣”来运作的而是按实际使用量中“被 SP 覆盖的部分”打折。如果你买的小时承诺是 5 美元/小时但实际按需用量只有 3 美元/小时那么剩余 2 美元/小时的承诺是浪费的不会退。反过来如果你实际用量是 8 美元/小时超出 5 美元的部分仍按按需价计费。所以正确做法是买之前算准买之后每个月定期看“Savings Plans 覆盖率”和“浪费率”两个指标。浪费率超过 5%说明买多了覆盖率长期低于 70%说明买少了。7.2 成本分析工具推荐哪个Cost Explorer 还是第三方工具AWS 自带的 Cost Explorer 功能已经很强可以按服务、按标签、按账号、按地域拆分费用并且支持导出 CSV。对大多数场景先用它就够了。缺点是“预算是事后告警策略是手动配置”没法对实时费用做精细管控。如果你的规模到了多账号、多 BU 的阶段建议上第三方的 FinOps 平台比如 CloudHealth、Spot.io、或者国内一些做多云成本管理的 SaaS。它们的好处是自动发现闲置资源、提供更细粒度的调度建议甚至可以直接帮你暂停开发环境的实例。不过注意第三方工具的接入本身也有成本小账号月账单低于 5000 美元用第三方工具可能得不偿失。7.3 测试环境永远最烧钱怎么破我几乎在每一个客户那边都能看到测试环境资源泛滥。解决方案除了前面提到的“非工作时间缩容到零”还有一招是“环境分级”核心测试环境比如预发布环境保留常驻实例但规格可以降一档非核心联调环境和功能测试环境全部走按需 定时启停。我们有个客户以前测试环境一个月要 1.2 万美元后来按这套规则重排缩到 3500 美元每月。代价只是测试人员需要等待实例冷启动 2-3 分钟——这个代价绝大多数团队完全能接受。7.4 混合使用多个云厂商成本怎么对比有的客户同时用 AWS、Azure 和阿里云做成本优化时容易陷入“单云视角”。我的建议是建立“统一成本看板”把各家账单按服务类型计算、存储、网络归一化按“单位成本”去对比。比如每 vCPU 每小时的价格、每 GB 存储的价格、每 GB 出网流量的价格。只有在同一度量口径下你才能做出“哪个业务放哪朵云”的决策。当然迁云本身有成本不要只看单价要把迁移的工作量、风险、数据同步的长期费用都算进去。最后分享一下这段时间带团队做 AWS 成本优化的几点体会我第一次帮客户做成本优化还是很多年前那时候的整份策略就是“关掉不用的机器、买预留实例、把存储降级”跟现在比起来简直是砍柴和做外科手术的区别。现在的 AWS 账单复杂度逼着你必须具备体系化的思维计算、存储、网络、治理每一个维度都不是孤岛。我也越来越意识到省钱的本质不是压缩需求而是精准匹配供给——你需要多少、要多久、能承受什么风险然后选择合适的计价模型和资源形态。另外一个感受是成本优化要和业务节奏对齐。每次大促前我们都会主动帮客户把弹性能力开到最大SP 买足但预算告警调高大促结束后又立刻把临时资源释放掉该缩容的缩容该降配的降配。有些客户不好意思主动提“缩容”总觉得那是消极信号其实恰恰相反极致的弹性才是云计算的精髓。最后分享一个小技巧在处理客户账单时如果发现一个费用项找不到出处,可以先在 Cost Explorer 里按“Usage Type”维度拆再按“关联账号”拆最后按“标签”拆。大多数问题都能在这三步里定位到。实在找不到的资源用 Service Quotas 里的“近期使用量”反查基本不会漏。这个方法我们也写进了团队的内部手册算是被反复验证过的老经验了。AWS 的成本优化说到底拼的是对业务的理解和对账单的敏感度。希望上面这五条策略和一堆踩坑经验能让你在自己的账号里也试出效果来。后续如果遇到特定场景下的成本疑难欢迎一起交流。