阿里云ECS规格选型与弹性伸缩降本实战指南

Flexera 2024年云成本报告里有一个刺眼的数据：企业上云后的平均资源浪费率仍高达32%。这相当于每三台运行的云服务器中，就有一台的钱是白花的。当“上云即省钱”的叙事红利消退后，阿里云ECS规格选型与弹性伸缩降本正在从运维课题上升为企业财务纪律的硬指标——它不是要你少用云，而是要你把每一分钱花在真实的负载上。

一、阿里云ECS成本优化为何成企业刚需

多数技术团队对上云成本的感知停留在“月账单没超标就行”，但拉出七天的资源利用率曲线图，CPU常年趴在15%-25%的实例比比皆是。问题不在于团队不关心成本，而在于缺乏业务画像后本能地按峰值配置——这是一种安全冗余思维，却成了成本泄漏的最大敞口。当单条业务线的月消耗从五位数滑向六位数时，规格选型就不再是技术偏好问题，而是一个需要被量化治理的财务问题。弹性伸缩和精准选型，本质上是同一件事的两面：让资源供给曲线尽可能贴合业务负载曲线，而非始终准备着那场永远不会同时到来的流量洪峰。

1.  云资源浪费三大源头

云资源浪费并非来自某个单一决策失误，而是三重惯性叠加的结果。第一重是按峰值静态配置——团队为应对每年可能只出现两次的流量尖峰，让实例全年运行在顶配规格上，日常利用率不足30%。第二重是业务波动响应滞后，促销结束三天后实例才缩容，甚至忘记缩容，导致按量付费的资源持续空转。第三重是跨团队资源孤岛，不同业务线各自申请实例却无统一标签和分账机制，没人能说清哪台机器还在用、哪台早已闲置。三重惯性环环相扣，单靠人工巡检根本破不了局。

2.  弹性伸缩的降本价值

弹性伸缩的降本逻辑不是“少买机器”，而是把固定成本转化为可变成本。以一个日均CPU利用率从25%提升至65%的无状态应用集群为例，通过设置基于平均CPU使用率的伸缩规则，高峰时段自动扩容、低谷自动缩容，可将原本按峰值常驻的实例数量压缩至原来的三分之一到二分之一。配合负载均衡的会话保持和优雅下线机制，缩容不会造成业务中断。弹性伸缩的冷却时间和步长设置才是真正考验功力的地方——过短引发抖动，过长则浪费，这个参数的调优决定了伸缩策略是降本工具还是故障触发器。

3.  选型失误的隐性成本

选型失误的代价通常不会出现在任何一张账单报表上，但它实实在在地侵蚀着性能底线和成本结构。用通用型g7实例跑高IO的数据库场景，为弥补云盘性能短板不得不挂载更高规格的ESSD PL3云盘，最终月成本反而高于直接选用本地SSD的i4实例。另一个更普遍的误区发生在轻量级场景：开发测试环境、微服务网关这类大部分时间低负载、偶有突发的业务，使用标准实例全额付费，而实际上T6突发性能实例在满足基准性能的前提下，利用CPU积分应对峰值，可将这部分的支出压降40%到60%。选型的本质不是挑配置，是匹配工作负载特征——算错这一步，后续所有优化都是在错误基线上修补。

二、ECS实例规格选型的核心方法

云上资源浪费已是公开的秘密，Flexera 近几年的报告持续指向一个数字：企业平均有 30%–45% 的云支出被闲置资源吞噬。根因很少出在“买少了”，而在于“选错了”——用计算优化型实例跑纯内存缓存，或者给偶发低负载的测试环境配置标准规格，这类错配导致的隐性成本远高于单价本身。真正有效的规格选型，不是对比配置表上的 vCPU 数量和内存数字，而是把工作负载的特征翻译成实例规格族的参数约束。以下三个维度基本决定了选型是否准确。

1.  vCPU 与内存配比：从业务画像出发，而非凭峰值估算

很多团队不敢缩减资源规模，根源在于缺乏业务画像，只能按照想象中的峰值配置。结果一批实例的 CPU 和内存使用率常年徘徊在 30% 以下，即使偶尔冲到 50%，也远未触及瓶颈。更危险的做法是盲目追随“一线配置”：用通用型实例去承载高并发计算任务，或者把数据库这种内存敏感型应用塞进计算优化型实例里，导致性能不达预期后又被迫升配，花了两份钱。

正确的姿势是以 7–15 天的资源利用率数据作为选型基线。从云监控中拉取 CPU、内存、网络和磁盘 I/O 的时间序列，区分稳态均值和真实峰值，而不是凭经验下判断。计算密集型应用（如批量处理、视频转码）通常需要更高的 vCPU 配比，内存与 vCPU 的比例可以低至 1:2 甚至更低；而内存密集型场景（如 Redis、JVM 堆大的 Java 应用）则应挑选内存与 vCPU 比例达到 1:8 甚至更高的规格。通用型实例只适用于没有明显资源偏好的均衡负载，强行用一个规格族覆盖所有场景，意味着至少有一半的工作负载在持续浪费资源。主流云平台提供的资源优化建议工具也可以快速定位闲置或过量配置的实例，但最终的判断仍需工程团队结合业务特点做出，工具只是缩短了数据收集的时间。

2.  网络与存储性能影响：规格族差异并非只体现在 CPU 和内存上

不少人选型时只盯着 vCPU 和内存，却忽略了实例规格对网络带宽、存储吞吐和 IOPS 的隐含限制。这在高 I/O 和网络转发密集的场景中几乎必然踩坑。一个典型的案例是关系型数据库：如果使用通用型实例挂载云盘，数据库的高并发随机读写很快就会压满云盘的 IOPS 上限，而改用带有本地 NVMe SSD 的存储优化型实例（如 i 系列），不仅能获得更高的 IOPS 和更低的延迟，单 IOPS 成本反而更低。同样，对于用于流量转发、网关或高频消息收发的服务，网络增强型实例的包转发率和带宽上限远高于通用型，用后者去承载等于人为制造瓶颈，再靠水平扩展去弥补，算下来总成本往往更高。

因此，在选型阶段就需要明确应用的 I/O 和网络倾向。磁盘 I/O 密集应用应优先考虑存储增强或本地 SSD 实例，而非通过叠加高性能云盘来拼凑性能；网络密集型应用则需要关注实例规格族标称的网络带宽和收发包能力，避免在负载升高后出现带宽削峰。如果已经上线的业务因存储或网络性能不足而频繁抖动，第一步不应是盲目升配，而是检查当前规格族是否与 I/O 模式匹配——更换为正确的规格族，有时不需要增加多少预算，就能让延迟指标大幅改善。

3.  突发性能实例：轻量波动的低成本解，但不是免费午餐

突发性能实例（如 t5、t6 系列）利用 CPU 积分机制，在基准性能之上可以短时间爆发，特别适合平时低负载、偶有峰值的轻量级场景，比如开发测试环境、微服务容器集群中的低流量节点、轻量 Web 服务器等。在满足基线性能的前提下，这类实例相比同 vCPU 的标准实例可以节省 40%–60% 的成本，是很多团队容易忽略的降本杠杆。

但关键误区在于把“突发”当成“常态”。CPU 积分一旦耗尽，实例性能会被严格限制在基准线附近，任何超出基准的计算需求都会变得极度缓慢。因此，突发性能实例不应承载存在持续高负载的服务，也不适合作核心数据库或延迟敏感的在线业务。更值得警惕的操作是把竞价实例当作稳定承载来用——虽然竞价实例折扣可达 90%，但其随时可能被回收的特性决定了它只适合无状态、容错性高的批量任务或 CI/CD 流水线，如果把它当作持久化应用的常驻节点，稳定性风险会完全对冲掉成本收益。正确的做法是，将稳定长线的基础负载交给预留实例或节省计划覆盖，将弹性波动的部分交给伸缩组的突发实例和按量实例混合承担，这样既能享受高折扣，又不会因为实例回收而导致业务中断。

三、弹性伸缩策略设计与关键配置

弹性伸缩不是简单的“加机器、减机器”，而是一套需要精心调校的自动化运维体系。根据 Flexera 2023 年的云成本报告，企业平均有 32% 的云支出被浪费，其中伸缩策略配置不当是第二大贡献因子——仅次于资源规格超标。问题通常不在伸缩本身，而在规则设计上过于粗糙：要么阈值设置不合理导致反复抖动，要么冷却时间欠缺让扩容变成“应激反应”。

1.  规则配置：定义什么是“真的忙”

指标选择和阈值设定直接决定伸缩质量。CPU 平均使用率是最常见的触发指标，但它在不同场景下的意义完全不同。对于计算密集型应用（如视频转码），CPU 超过 70% 确实意味着算力吃紧；但对于 IO 密集型应用（如消息队列），CPU 可能还在 40%，磁盘 IOPS 已经打满。正确的做法是基于应用画像选择指标组合——至少接入两种指标做“与”或“或”的判断。一个实际案例是，某电商平台的订单服务伸缩策略从单一 CPU 阈值改为“CPU>65% 且 QPS>5000”后，无效扩容次数下降了 70%，因为过滤掉了数据库慢查询导致的 CPU 假性飙高。

阿里云的伸缩规则支持定时、指标、混合三种模式，推荐采用“指标打底、定时修正”的策略。指标规则确保日常弹性响应，定时规则处理已知的业务高峰期（如每晚 8 点促销、每周一晨会流量高峰），避免指标规则的滞后性——因为从监控触发到实例就绪通常有 2-3 分钟延迟，对于瞬间涌入的流量冲击，这个窗口足以让服务雪崩。

2.  最大实例数的隐性风险

“最大实例数设高点，反正用不上也不会收费”是常见的认知陷阱。实际上，设上限不只是成本控制，更是安全阀。2022 年某 SaaS 公司因代码缺陷导致死循环，每个请求都新建线程并占用内存，监控系统判定“负载升高”触发扩容，从 10 台一路扩到 200 台——最大实例数设了 1000 且没有告警。三小时后运维发现时，账单已增加 4 万元。正确的做法是：最小实例数由基础可用性决定（至少 2 台跨可用区），最大实例数按预算上限换算（比如月度预算 ÷ 单实例小时单价 ÷ 30×24），并设置扩缩容通知推送到企业微信或钉钉。

冷却时间同样是“省钱细节”。过短的冷却时间（如 120 秒）会导致“扩-缩-扩”的乒乓效应，不仅增加按量实例的计费时长（最短 1 小时起算），频繁创建销毁还可能在系统内部产生脏数据。建议默认冷却时间设置为 300-600 秒，让新实例有足够时间完成应用启动、预热和流量接入，也让监控数据积累至少两个采样周期后再判断是否继续扩缩。对于 Java 类重启动应用，这个值可以拉长到 900 秒。

四、基于实际负载的规格降本技巧

Flexera 2024年的云成本报告再次印证了那个尴尬的现实——大多数企业的云资源浪费率依然稳定在30%上下。根本原因不是企业不想省，而是不敢动。运维团队往往抱着“宁滥勿缺”的心态，用峰值负载做常配，导致大量ECS实例的CPU和内存利用率常年低于30%。真正的降本，不是简单关掉几台机器，而是从理解负载的底层特征开始。

1.  从历史监控数据重构实例选型逻辑

凭经验估算配置的时代该终结了。一个被反复验证的操作路径是：导出云监控中至少7到15天的CPU、内存、网络吞吐和磁盘IO数据，画出负载曲线，区分出真实峰值、平均水位和波动脉冲。这三条线能告诉你完全不同的答案。

多数人只看峰值，结果就是为每天可能只出现20分钟的尖峰配置了24小时的高规格实例。一个典型的例子是跑数据库的实例，如果平均IOPS稳定在3000以下但峰值能冲到12000，用本地SSD实例（如i3系列）叠加云盘，性能比通用型g7强制挂载ESSD PL3更稳定，单实例月成本反而能降25%以上。原因在于存储I/O密集型负载对实例的底层带宽和队列深度有硬要求，通用型实例的虚拟化开销在持续高IO下反而会成为瓶颈。这里的关键认知是：升配不一定解决问题，错配才是成本的根因。

对于轻量级Web服务器、微服务或开发测试环境，T5/T6这类突发性能实例的降本效果被严重低估了。这类实例通过CPU积分机制运行，只要基线性能能满足日常负载，偶发的请求尖峰由积分消化，实际成本可比同等配置的标准实例低40%到60%。但这里有一个硬约束——积分耗尽后CPU会被限流，所以不适用于持续高负载的场景。判断标准很直接：如果监控显示CPU平均利用率持续高于基线性能，说明该用标准型了；如果只是间歇性脉冲，突发实例就是最优解。

2.  用混合计费模型搭建稳态与弹性分离的架构

实例选型解决的是单点资源利用率问题，但规模化降本的核心在于将工作负载按“稳态”和“弹性”拆开处理。这是一个被Gartner反复验证的成本优化范式：7×24小时运行的稳定基础负载，最适合被预留实例或节省计划覆盖，一年期或三年期的承诺折扣可以把这部分成本压到底；而促销流量、定时任务、批处理这类可预判的弹性负载，交给按量实例或竞价实例处理。

实操中最常见的错误是拿竞价实例跑持久化应用。竞价实例折扣高达90%不假，但它的释放机制是随时随地的，只适合无状态、可重试、容错性高的任务——CI/CD流水线、无状态API网关、批量数据处理。一个合理的混合比例是：底层30%预留实例覆盖基本水位，30%按量实例应对正常波动，剩余40%用竞价实例承接弹性部分。这个配比在保证服务可用性的前提下，能将整体计算成本压缩到纯按量部署的50%到60%。

伸缩策略本身也需要成本治理。不设最大实例数上限的伸缩组，遭遇应用死循环或外部攻击时可能触达账户配额上限，这个账单对财务团队的冲击远超运维的预期。冷却时间过短则会导致频繁扩缩，每次伸缩活动本身有开销，抖动带来的业务影响更是隐性成本。一个成熟的实践是：最小实例数锚定基本可用性，最大实例数严格参照预算上限和账户配额设定，同时对竞价实例中断设置SNS或云监控告警，在释放前30秒的预警窗口内完成流量摘除，避免异常蔓延到用户侧。

五、构建持续优化的成本治理闭环

将规格选型与弹性伸缩真正转化为成本竞争力，不能靠一次性调整，而需要建立起一套持续发现、调整、验证的治理闭环。多家调研机构的数据指向同一个事实——企业云资源浪费率长期在 30%–45% 区间徘徊，其中规格不匹配与缺乏动态调整机制是最大的成本泄漏点。正因为如此，优化不会止于一次“削峰填谷”，而必须嵌入日常运维流程。

1.  关键监控指标与告警

成本治理的起点是全面且准确的监控，而非事后的账单惊讶。CPU 利用率、内存使用率、网络吞吐量及磁盘 IOPS 四个维度的长周期数据，是判断规格是否匹配的核心依据。大量团队习惯于只看 CPU，却忽视内存或 IO 瓶颈——例如将数据库跑在通用型实例上，CPU 尚可但云盘 IOPS 打满，导致响应延迟上升，被迫升配，实则换成本地 SSD 实例性能更优、成本更低。因此，监控至少要以 7 天为最小窗口，采集峰值、平均值与 P99 延迟等分位数，才能有效定位真实资源画像。

更重要的是，监控必须与告警联动。突发性能实例在 CPU 积分耗尽后，性能会被限制在基线以下，若缺乏积分余量告警，轻量 Web 或开发环境就可能突发降级，影响业务。伸缩活动同样需要独立告警：伸缩失败、达到最大实例数上限、竞价实例被提前释放等事件，都应在几分钟内推送到运维群组。没有这类实时告警，弹性伸缩反而可能成为“静默故障源”——实例扩不出来，服务靠存量硬撑，待发现时已经上演流量事故。实践中，我们建议至少设置三层告警：资源水位告警（如 CPU 持续高于 70% 触发扩容评估）、容量边界告警（最大实例数触碰预警）、以及特定实例类型风险告警（竞价实例中断通知），将成本优化约束在安全边界之内。

2.  定期优化流程与工具

闭环的核心在于将监控数据转化为具体动作，并以固定节奏执行。每两周或每月进行一次“资源瘦身”迭代，是被验证行之有效的方法。借助云平台提供的资源优化建议，可以快速筛出长期低负载实例——比如 CPU 和内存连续 14 天低于 30% 的机器，列为降配或释放候选。但要注意，直接看平均值容易漏掉周期性的短时高峰，因此优化建议必须结合业务“生物钟”：若一个实例每天凌晨 2 点有 5 分钟的 100% CPU 批处理，平时几乎空闲，降配可能致任务超时。此时更优解是将其迁入突发性能实例，或归并入弹性伸缩组，以定时任务触发临时扩容，而非保留过量规格。

工具层面，云监控导出的性能数据可以直接导入自建的选型分析表，对不同业务线建立“资源效能比”模型。例如，每单位 CPU 核数支撑的并发请求量、每 GB 内存承载的缓存命中率等，当效能指标出现 15% 以上偏离，就触发规格重选评估。此外，定期拉取未使用资源报告——未挂载的云盘、闲置公网 IP、未释放的弹性网卡等附带资源，是极易被忽视的成本长尾，处置这些“僵尸资源”能带来立竿见影的账单下降。这种周期性的清理动作，应作为固定议题纳入团队双周运维复盘。

3.  跨团队成本治理实践

多云账号、多业务线场景下，成本治理的最大障碍往往不是技术，而是责权不清。没有严格的标签规范与分账机制，优化就找不到对象——账单上一条数千元的支出，不知道对应哪条业务线，没人认领，也就没人负责优化。因此，资源强制打标是治理闭环的第一道硬性门槛。标签维度至少应覆盖“团队-业务-环境”，例如“数据平台-实时推荐-prd”，并利用云平台的标签策略禁止创建无标签资源。

在此基础上，每两周按标签维度导出账单，计算各业务线的单位运营成本——例如每千次 API 请求的实例成本、每 TB 缓存数据的资源开支。数据公开透明后，成本意识才会从运维扩散到产品和研发团队。我们发现，当研发团队看到自己名下开发环境一个月花费数千元，且 70% 时间处于闲置时，会自发推动资源降配或引入突发实例，而非一味要求“规格不变”。更进一步，可设立成本优化专项预算，将节省金额的一定比例用于团队激励，驱动由下而上的治理文化。最终，监控、优化、复盘三个齿轮咬合运转，规格选型与弹性伸缩才能在动态业务中持续兑现降本承诺，而不是沦为一次性的纸上方案。

六、企业降本典型场景与案例解析

把云资源成本单纯归咎于“用了太多机器”是一种偷懒。在一线实操中，真正的主因往往是两个错配：实例规格与实际负载的错配、资源供给与业务节奏的错配。下游的账单只是结果。以下三个典型场景，分别对应周期性爆发、实时波动和长期稳态下的资源治理，它们共同证明一件事——正确的规格选型与弹性伸缩设计，可以把浪费的那30%–45%云支出找回来，且不牺牲服务等级。

1.  电商大促弹性应对：从“为峰值买单”到“为真实负载编程”

一家年GMV超十亿的垂直电商，常年在300多台ECS上跑着微服务化后的商城主站、订单、商品和推荐链路。过去为了扛住双11和618，技术团队按预计峰值流量的1.3倍进行预留，大促结束后的两周内再手动缩容。这种做法造成了两个慢性病：日常CPU平均利用率仅17%–23%，但无人敢把整体规模压下去；突发大流量时，手工扩容的速度跟不上流量爬升的斜率，某年大促前10分钟因扩容延迟曾导致短暂限流。

他们把优化拆成两件事：稳态基线重塑和峰值弹性解耦。

首先基于连续14天的云监控数据（CPU、内存、网络吞吐及磁盘IOPS），将24小时常驻的服务群体做了规格重匹配。商品和推荐这类计算密集型服务从原先的通用型g5迁移到计算型c6，利用更高主频和计算优化，单实例QPS吞吐提升了约26%，反而可以减少28%的常驻实例数。订单、支付等逻辑复杂但计算密度不高的服务，则保留了通用型，改为一年期预留实例加节省计划，阶段性折扣把固定开销削掉约35%。一个常被忽视的点是：大量非核心的轻量Web前端、管理后台以及预热缓存，被迁移到了突发性能T6实例上，依靠CPU积分应对偶尔的管理并发，该项变动使得该部分年成本下降了约52%。

弹性的部分，用上了“定时+指标”双模伸缩。大促前1小时，按照预定计划将伸缩组的最小实例数拉高到稳态的3倍，同时配置基于平均CPU利用率（阈值75%）的追踪策略，一旦定时扩容未能完全覆盖秒级流量尖峰，指标伸缩立即补位。伸缩组内混合配置了c6和c6a两个实例规格族，防止单一规格库存不足导致扩容失败，这一做法在当年双11零点自动扩容成功率保持在99.7%以上。冷却时间设在300秒，避免了频繁抖动；缩容策略则使用“先停止、再终止”，给连接优雅关断留出15分钟窗口。

最终效果很直观：全年总计算成本同比下降41%，大促零限流、零紧急人工干预，日常CPU利用率抬升到45%左右，不再为“一年只跑72小时的峰值”支付全部账单。

2.  游戏服动态扩容：把竞价实例用在正确的地方

一个主打MOBA玩法的游戏工作室，各区服采用“战斗服+大厅服”的经典架构。波峰波谷极不规则——晚间和周末在线人数是凌晨的4～8倍，且新赛季开始的第一周会出现难以预测的超高峰。先前一律采用固定的高配通用实例，单战斗服承载上限锁定，扩容依赖运维批量跑脚本，缩容靠人工判断，很容易漏掉凌晨低负载的闲置资源。一次赛季更新当天，因扩容跟不上涌入的玩家，多个战斗服排队严重，流失惨重，而服务器账单里，凌晨CPU不足10%的实例占了很大一部分。

改造的核心思路是：把延迟敏感的常驻会话与可中断的非关键任务拆开，用不同实例类型与计费模式匹配。

战斗服和游戏逻辑对网络时延和稳定性要求极高，保留7x24小时运行的预留实例，规格从通用型改为网络增强型实例g6e，充分利用高网络包收发能力来降低玩家指令的尾部延迟。大厅、匹配、聊天等无状态且有明显波动的服务，接入弹性伸缩组，基于“平均网络连接数”这种更贴近游戏在线的指标来自动扩缩。夜间最低保留实例数设为白天的1/4，冷却时间配合游戏房间生命周期设置为600秒，避免缩容过快导致正在对战的房间被销毁。

真正的点睛之笔是引入了竞价实例，用于处理批量计算任务——赛季结算、离线排名计算、回放数据分析。这些任务允许中断和重试，本身就适合抢占式资源。工作室将此类任务打包成容器化作业，放进混合伸缩组，底层60%为按量实例保底、40%为竞价实例，一旦竞价实例被回收，任务调度器自动转移到新的竞价实例上重新执行。这个组合使这部分算力的成本降至原先的不到1/3。

整个改造后，月度计算成本下降57%，扩容响应从原先的平均15分钟缩短到不到90秒，缩容不再依赖人工，闲置资源被控制在极低水平。唯一的代价是需要工程团队接受“竞价实例随时可能消失”的事实，并在代码层面做好检查点和断点续算——这笔一次性投入在长期成本面前基本可以忽略。

3.  SaaS平台资源优化：标签治出来的35%空间

一家服务逾千家企业客户的B2B SaaS平台，在同一阿里云账号下同时维护着生产、预发、测试三套环境，多条业务线（CRM、协同、数据分析）共享底层资源。财务一直反映云成本年增长30%以上，但技术侧却说不清每一条业务线具体花了多少钱，只能粗略平摊。翻开资源清单，数百台ECS实例里，运行I/O密集型数据库和搜索服务的竟有相当比例是通用型g5，磁盘延迟高、抖动频繁，为了弥补性能被动升配，内存和vCPU大量闲置；开发测试环境24小时开着标准实例，周末和夜间几乎零负载，却在持续计费。

治理分三步走。

第一步，强制标签与分账。所有资源按“业务线-环境-负责人”三级标签打标，利用分账账单将每条业务线的计算、存储、网络成本暴露在各自的负责人面前。透明本身就是一种压力。

第二步，规格重映射。数据分析业务的ClickHouse和Elasticsearch集群，对磁盘吞吐和IOPS极其敏感，之前用通用型叠加ESSD云盘，性能瓶颈在云盘的带宽上限。将这些节点迁移到搭载本地NVMe SSD的i3实例后，查询延迟下降了40%，并且因为性能释放，集群总节点数从24个减少到16个，直接省下1/3的硬件成本。CRM业务的大量无状态应用，从标准规格迁移到同代计算优化型c6，实例数不变但资源利用率更健康。

第三步，用弹性解决环境与时段浪费。测试环境和预发环境全面改用突发性能T6实例，基线和积分机制刚好覆盖白天的低频率访问，夜间的低频负载几乎不消耗积分，无需额外付费。同时针对测试环境设置定时伸缩：工作日23:00至次日7:00将最小和期望实例数收缩为0，仅保留必要的数据卷和快照；早晨再自动恢复，每月为此节约的非生产环境费用达原有水平的62%。生产环境中，那些按固定周期跑批的任务（每日凌晨2点运行的报表计算），通过一次性伸缩组触发一批竞价实例执行，结束后自动释放，保证功能不缺失的同时不占用稳态资源。

三个阶段走完，年度云成本增速由30%回落到个位数，绝对金额降低35%，更重要的副产品是：每条业务线的单位服务成本（Cost per Tenant）第一次被精确量化，为后续的定价和资源投入决策提供了清晰依据。这件事说明，当技术架构与财务治理并行时，降本才真正可复现、可持续。