ESS智能缩容实战：三步降低阿里云ECS闲置成本

做渠道商这几年，我几乎每个月都会遇到客户拿着账单问：“我们的业务量没涨，为什么阿里云的费用一直在涨？”这时候我会顺手打开控制台看一眼，往往能翻出一堆长期空转的ECS实例。要解决这个问题，最常用的手段就是ESS智能缩容——通过阿里云弹性伸缩服务（Auto Scaling）自动关停低谷时段的闲置实例，腾出资源和费用空间。对渠道商来说，这既是帮客户省钱的卖点，也是续约和增值服务里最容易见效的技术抓手。

这篇文章我打算把三步落地的完整思路、参数配置和踩坑经验都写出来。读者可以是云代理商里的技术交付、客户成功，也可以是负责云成本的运维同学。文中涉及的数值均基于常见按量付费单价估算，实际以控制台账单为准，但配置思路和排错方法是可以直接抄走的。

1. 渠道商为什么盯上ESS缩容这块“成本蛋糕”

1.1 客户账单里真正吃钱的是哪几项

阿里云的账单很细，但渠道商做成本优化时，要看的是“支出大头”。绝大多数客户的费用构成里，占第一位的通常不是带宽，也不是RDS，而是按量付费的ECS实例。原因很简单：按量付费实例一旦创建出来，只要不释放，就会按小时持续计费，哪怕CPU利用率只有5%，账单照样一分不少。

很多客户的应用是从传统机房搬迁上来的，架构上习惯性“买够再租”。为了扛住双11、月底结算、促销活动这些峰值场景，他们往往按峰值规模购买10台甚至20台ECS，活动结束后机器继续留在那里跑空转。这种“为峰值付费”的模式，在包年包月场景下更明显，客户买了一年，每天只用了两三个小时的高负载，剩下的时间都在空转。

对渠道商来说，这就是最直接的优化缺口。ESS智能缩容解决的核心问题，不是“把云计算的单价谈下来”，而是“把客户实际使用的资源量降下来”。如果客户的业务天然存在低谷时段，通过ESS在低谷自动释放多余的ECS实例，月底的账单就会立刻缩水，这比跟客户讲一堆架构理念要有说服力得多。

1.2 ESS智能缩容省下的不止是“实例费”

很多人以为ESS缩容只是省了几台ECS的按量费用，其实释放实例后，关联成本也会跟着下降。

比如随实例创建的云盘，如果释放实例时选择同时释放数据盘，云盘容量费用也会停止；再比如实例绑定的公网IP，如果采用按量付费公网IP的方式，实例释放后IP费用自然停止；还有一部分客户的监控、备份、快照策略是按实例维度做的，实例少了，相关费用也会减少。

不过渠道商在跟客户宣传“省30%”的时候，一定要把节省范围说清楚。像SLB负载均衡、NAT网关、RDS数据库、OSS存储这类固定资源，并不会因为ECS缩容就自动省钱。缩容真正省下的是计算资源，以及一部分与实例生命周期绑定的存储和网络费用。如果客户全年的费用里RDS占了大头，那就需要另外设计数据库降配方案，ESS缩容帮不上太多。

这也是为什么我建议渠道商在给客户承诺“30%成本节省”之前，先打开账单做一次费用拆分。如果计算资源占比超过50%，ESS智能缩容的空间就很大；如果大头都在固定资源上，就要调整方案，别硬套缩容。

1.3 什么样的客户才适合把30%当成目标

ESS缩容不是万能的，我接触过的客户里，真正能把成本压下来30%的，一般都有几个共同特征：业务有明显的波峰波谷，低谷持续时间超过1小时；应用是无状态或可水平扩展的；数据要么在OSS/RDS，要么在共享存储，实例本身不保存关键数据。

建议用下面这张表快速判断客户是否适合：

判断客户是否适合，渠道商不能只看“CPU低不低”，还要看业务能不能接受实例释放后IP变化、本地缓存丢失、再启动时的初始化耗时。如果客户的应用启动要十几分钟，缩容后扩容回来可能赶不上业务恢复要求，那就要慎重。确定客户画像之后，再进入第一步的建模工作，才是稳妥的做法。

2. 第一步：缩容前的“家底”盘点与伸缩组建模

2.1 7天监控画像：先量化再谈缩容

我见过很多渠道商同行，刚在控制台配好ESS缩容策略，就急着跟客户说“明天开始省钱”。结果第二天客户业务突增，机器不够用，页面一打开就502，最后只能灰溜溜把策略停掉。问题出在缺少缩容前的资源画像。

正确做法是先把客户现有的ECS实例接入云监控，导出至少7天的监控数据，重点看CPU使用率、内存使用率、内网带宽、外网带宽这四个指标。不要只看平均值，要看“每天的低谷窗口是否能稳定复现”。比如客户业务是每天早上8点到11点处理报表，那么连续7天里，下午和凌晨时段应该都是明显的低负载窗口，这种规律越稳定，缩容操作越安全。

我自己的习惯是做一个简单的统计：统计每天CPU平均使用率低于20%的持续时长，如果每天低谷累计超过3小时，并且低谷时段集中且规律，那就可以进入下一步。如果低谷时段每天都不一样，或者忽高忽低，那么纯靠缩容不一定安全，可能得先跟客户谈业务限流或架构改造，而不是直接调参数。

拿到画像之后，不要急着创建伸缩组，先在客户侧做一次“人工缩容演练”：挑一台负载最低的ECS实例，手动关闭或从SLB摘除，观察业务是否有异常告警、日志是否中断、客户是否感知。演练通过，再开始建组。

2.2 创建伸缩组：最小实例数、最大实例数和可用区

创建伸缩组是ESS的核心动作，很多参数会直接决定缩容效果。我建议渠道商在控制台操作时，重点盯住这几个参数：区域、可用区、网络类型、最小实例数、最大实例数、默认冷却时间、移出策略。

先说可用区。如果客户业务要求高可用，伸缩组至少要跨两个可用区，防止缩容后所有实例集中在一个可用区，一旦该可用区出问题业务就全挂。我处理过一个客户，为了“省事”把所有实例放在同一个可用区，缩容到最小实例数2后，恰好遇到可用区网络抖动，两台实例同时不可用，业务直接中断。后来改成跨可用区部署，同样缩到2台，风险低了很多。

再说最小和最大实例数。普通客户很容易把最小实例数设成0，觉得“省到极致”，但生产环境一旦触发缩容到0，冷却期内如果来流量，扩容都来不及。我更推荐把最小实例数设为客户的“业务冗余基线”，比如2台；最大实例数设为峰值实例数再上浮20%，避免突发流量被打爆。

创建伸缩组时还要确认负载均衡关系。如果客户业务通过SLB对外提供服务，就在伸缩组里绑定SLB，让ESS自动完成实例注册和摘除。这里有个渠道商容易忽略的点：绑定SLB之后，缩容的实例会被自动从SLB摘除，但这不代表连接立刻断开，还需要在应用侧处理存量连接，否则客户会觉得“页面偶尔卡一下”。

2.3 实例模板和启动配置决定“缩回来后好不好用”

缩容的“后半场”是扩容。如果扩容出来的实例是一台“裸机”，没有初始化好的环境，那缩容省下的钱可能会在扩容时变成新的故障。所以我在给客户做ESS方案时，会把一半以上的精力花在实例模板和启动配置上。

实例模板建议包含三部分：自定义镜像、UserData脚本、云助手任务。

自定义镜像最直观，把客户的JDK、PHP、Nginx、Python等运行环境提前打入镜像，扩容出来的实例直接可用；但镜像也有坏处，如果客户每周发版一次，镜像里的代码就容易过期，所以镜像里最好只放基础环境，不放业务代码。

UserData脚本负责实例启动后拉取最新配置和代码。很多客户会用到内部代码仓库、配置中心或对象存储，这些初始化动作都可以写进UserData。比如从自建Git拉取最新分支、从私有OSS下载配置文件、向注册中心上报地址等。这样每次扩容都是一台“最新的空跑实例”，跟缩容前那批机器的状态无关。

云助手是阿里云提供的一个远程执行命令工具，善用它能解决很多“缩回来之后不好用”的问题：可以在实例加入伸缩组时自动执行部署脚本，也可以在实例即将释放时执行清理命令。渠道商在模板里把云助手的状态配置好，后面做缩容验证会省很多力气。

3. 第二步：把缩容策略调到“既快又不误杀”

3.1 阈值与持续周期：缩容要比扩容更“慢半拍”

ESS的报警任务逻辑是“指标+阈值+持续周期+动作”。比如CPU使用率低于25%，持续15分钟，触发缩容1台。这里有两个参数非常关键：一是判断阈值，二是持续周期。

很多渠道商一上来就把阈值调得很激进，CPU低于50%就想缩容，结果业务一个短暂抖动就触发缩容，过一会儿又触发扩容，形成“伸缩震荡”。我一般建议缩容阈值不要设置得太高，CPU低于20%~25%再考虑缩容；持续周期也不要太短，至少持续10~15分钟，确认业务确实进入低谷，而不是临时低负载。

扩容侧则可以设置得更灵敏一些，比如CPU高于70%，持续5分钟就扩容。这样设计的核心逻辑是：扩容要快，宁可多开；缩容要慢，宁可少缩。一套成熟的ESS策略，应该是“扩容像踩油门，缩容像踩刹车”，油门响应快，刹车带一点缓冲。

另外要注意聚合周期。云监控默认按1分钟或5分钟聚合数据，ESS报警任务需要指定统计周期。如果客户业务本身波动很大，建议聚合周期取5分钟，避免1分钟均值短暂跌破阈值造成误触发；如果波动不大，1分钟聚合更灵敏。

3.2 冷却时间：缩容节奏的“刹车片”

冷却时间（Cooldown）是缩容配置里最容易被忽视、但最容易出问题的参数。它的作用是：每次伸缩动作执行后，在冷却时间内不响应新的伸缩请求，防止频繁扩缩。

默认冷却时间是300秒，但对大多数生产环境来说，300秒不太够。假设客户的应用从实例创建到真正就绪需要8分钟，那么扩容动作执行后，新实例还在启动过程中处于冷却期，如果此时又来一个缩容报警，ESS可能无法正常扩缩，业务健康就会受影响。

我的建议是：把冷却时间至少设为单台实例“从创建到Ready”的时间，再加上2~3分钟的安全缓冲。比如实例启动要8分钟，冷却时间就配置在600秒到900秒之间，宁可让伸缩动作迟钝一点，也不要让实例状态在“创建中”就被下一次判断干扰。

还有一个细节：ESS支持为“扩容规则”和“缩容规则”分别设置冷却时间。如果客户业务缩容后需要较长时间稳定，可以把缩容冷却时间加长到900秒；扩容冷却时间可以短一点，比如300秒，保证扩容响应速度。这种差异化配置，是渠道商跟客户展示专业度的细节之一。

3.3 移出策略：确定先释放哪台实例

每次缩容时，ESS需要决定“先释放哪台实例”，这就是移出策略。默认策略是移出最旧实例，意思是优先释放创建时间最早的ECS实例。这种策略适合大多数业务，因为旧实例往往承载过多次发布，环境相对“脏”，留新实例更可靠。

但有些场景需要调整。比如客户刚做过一次全量发布，新实例在运行过程中有未知问题，客户希望优先保留旧实例，那就把移出策略设置为“移出最新实例”。再比如客户有一部分实例承担了特殊任务，不能随便释放，就需要用到实例级别的“缩容保护”。

缩容保护是ESS的一个独立开关，开启后该实例不会被自动缩容规则释放。渠道商在配置时要注意：如果客户核心实例开启了保护，缩容策略会把它们跳过；如果所有实例都开了保护，那缩容动作就一条都不会执行，客户会以为ESS坏了。正确做法是只对少数“非缩不可”的实例开启保护，比如数据未迁移完的实例、临时调试中的实例、跑批任务中的实例，其余实例保持可缩容状态。

移出策略和缩容保护配合好，缩容才能做到“释放的是该释放的机器，留下的是该留下的机器”。这需要渠道商在配置前跟客户业务团队确认一遍：哪些实例有特殊标签，哪些实例不能动，哪些实例可以随时重建。

4. 第三步：智能预测让缩容从“事后省”变成“事前省”

4.1 预测模式的工作原理与数据条件

报警任务本质上属于“事后缩容”：先出现低负载，再触发释放，多少有一点滞后。更理想的路径是“事前缩容”：在业务低谷到来之前，把实例数量先降下来。阿里云ESS的预测模式就是为了解决这个问题。

预测模式会读取客户过去一段时间的监控数据，识别业务负载的周期性规律，然后预测未来一段时间的容量需求，并自动生成扩缩容计划。如果客户业务每天下午3点到6点负载很低，预测模式可能在下午2点45分就触发缩容，而不是眼睁睁看着3点到了再开始释放实例。

这个功能听起来很智能，但对数据有一定要求。如果客户刚迁移上云、监控数据不足7天，或者业务本身没有明显周期性，预测结果就不够准确。我在实际项目中，一般会先让客户按报警任务方式跑两周，积累足够数据后，再开启预测模式，把它和报警任务搭配使用。

还要注意一个边界：预测模式只能基于历史规律，无法预知突发的业务事件。如果客户突然做一场线上促销，历史数据里没有这个高峰，预测模式可能会给出偏保守的容量判断。因此，启用预测模式不等于去掉报警扩容，该保留的兜底规则必须保留。

4.2 定时任务：应对固定活动的“笨办法反而最稳”

预测模式适合周期性不固定但波动规律可学习的场景，但有些客户的业务规律是“写死”的，比如每天早上7点同步数据，晚上8点停止对外服务。这种场景反而用定时任务最直接。

定时任务允许你指定时间点执行指定伸缩活动，比如每天20:00执行“缩容到5台”，每天7:00执行“扩容到10台”。这种方式不需要等报警、不需要学习数据，只要客户的业务时间表固定，就足够稳定。

渠道商在做定时任务时，要考虑“时区”和“固定任务之外的波动”。国际业务客户可能分布在多个时区，定时任务要按业务所在时区配置；如果客户偶尔有临时加班的批处理需求，定时任务固定缩容会把运行中的实例杀掉，所以最好加上“至少保留几台”的约束，别把实例数缩到业务无法运行。

定时任务、预测模式、报警任务三者不是互斥关系。我更推荐组合使用：预测模式处理长期趋势，定时任务处理固定时段，报警任务兜底突发流量。这样即使预测出现偏差，报警任务也能及时扩容回来。

4.3 云监控告警与缩容前的“体检”

无论采用哪种缩容方式，渠道商都必须把云监控告警配好，否则缩容动作就是“盲操作”。我通常会在ESS策略里嵌入两类告警：一类是缩容事件告警，比如触发缩容时通知到钉钉群或短信；另一类是缩容后健康度告警，比如实例数低于最小阈值、SLB后端健康检查异常、应用错误率上升。

触发缩容后，必须观察“缩容后状态”：缩了几台、还剩几台、SLB后端是否正常、业务QPS有没有下跌。很多渠道商只关注“有没有省到钱”，忽略了业务健康，等客户发现页面打不开了才来排查，往往已经晚了。

我自己的习惯是：每次为渠道商客户上线ESS方案后，第一周每天看一次“伸缩活动记录”，列一个简单表格记录“触发的缩容时间、缩掉的实例ID、当时的负载指标、缩容后是否有告警”。至少连续观察7天，确认缩容动作和业务低谷基本匹配，再逐步放开预算和推广到更多业务。这一步虽然耗一些时间，但能把后期的运维风险压到最低。

5. 一个真实案例：从10台到7台，30%成本是怎么完成的

5.1 客户现状与成本拆分

我把之前做过的一个案例简化后分享出来。客户是一家做报表生成和统计服务的企业，每天白天有大量定时任务在跑，晚上和凌晨业务量很低。客户有10台ecs.g6.large（2核8G）按量付费实例，统一通过SLB对外提供服务，没有固定IP需求。

成本拆分级大概是这样的：按量付费实例单价按0.2元/小时估算，单台实例一个月费用约0.2×24×30=144元，10台一个月约1440元。除此之外客户还有SLB、RDS、OSS等固定成本，但缩容优化只针对ECS计算资源。

计划是把低谷时段实例数从10台降到5台，平时按需保留7台左右，整体月度ECS计算费用目标从1440元降到1008元，节省432元，刚好约30%。这个案例的特殊之处在于客户业务有非常明显的低谷，且应用是无状态的，数据都写入RDS和OSS，实例本地不保留任何数据，所以缩容的安全性很高。

5.2 实际配置与操作记录

整个落地过程分五步进行：

1. 创建伸缩组：区域选择客户主账号所在的cn-hangzhou，网络选择客户已有的VPC，可用区勾选两个，最小实例数设为2，最大实例数设为12，默认冷却时间设为600秒。
2. 创建实例模板：使用客户打好基础环境镜像的自定义镜像，绑定安全组，配置好云助手，UserData脚本里包含从代码仓库拉取最新版本的命令。
3. 配置报警缩容规则：CPU使用率低于25%，持续15分钟，缩容1台；同时配置扩容规则CPU高于70%，持续5分钟，扩容1台。缩容冷却时间900秒，扩容冷却时间300秒。
4. 配置定时任务：每天20:00周期性执行“缩容到5台”，每天7:00周期性执行“扩容到10台”。
5. 配置云监控告警：触发缩容事件后向客户运维群推送通知，同时创建“SLB后端健康检查异常”告警，保证缩容后业务不掉线。

这里要特别说明，客户原来的10台机器没有纳入伸缩组之前，是由人工管理的。创建伸缩组后，我先把现有10台实例逐一添加到伸缩组，并把最小实例数设为2，最大设为12，这样系统不会一上来就疯狂缩容。前三天只启用报警缩容规则，定时任务等业务验证稳定后才打开。

5.3 成本节省核算与验证

方案运行一个月后，我看了一下伸缩活动记录：缩容事件共触发了21次，定时缩容每天都执行，整体低谷时段实例数基本上维持在5台左右，白天高峰最多时扩容到10台，没有出现扩容不及时导致业务中断的情况。

最后月账单里，ECS计算资源费用从1440元降到了1045元左右，节省比例约27%，接近30%的目标。第一个月之所以没有达到精确的30%，是因为有几天客户临时跑了额外的离线任务，缩容窗口被占用了，这是正常现象。第二个月业务恢复规律后，节省比例稳定在30%~32%之间。

这个案例也验证了一个判断：ESS智能缩容的成本节省，靠的是“按需购买”。在业务低谷释放多余实例，在高峰按需扩容回来，本质上把客户的云资源从“包月包年”变成了“按使用量呼吸”。渠道商如果能把这种账算给客户看，客户很容易接受后续的优化建议。

6. 渠道商落地时最容易翻车的几个隐藏坑

6.1 数据盘被释放，等于帮客户把数据删了

ESS缩容时释放实例，默认会把随实例创建的数据盘一并释放。如果客户在实例本地数据盘上存了日志、临时文件甚至业务数据，缩容一触发，这些数据就彻底没了。这是整个ESS缩容最危险的地方，也是我每次给客户做方案前必须检查的第一项。

解决办法有三层。第一层：重要数据一律放云数据库或对象存储，实例本地不保存任何持久化内容；第二层：如果业务确实需要数据盘，购买云盘时不要勾选“随实例释放”，或者创建独立云盘再挂载到实例，这样缩容时云盘还在，可以重新挂到新实例上；第三层：在缩容规则生效前，通过云助手在实例上执行备份脚本，把需要保留的文件同步到OSS，再触发缩容。

渠道商哪怕只省一点时间，也要把“数据盘保护”这四字牢牢记住。客户的任何一次数据丢失，都会直接毁掉渠道商跟客户之间的信任关系。

6.2 缩容保护把策略变成了“摆设”

有个新同学曾经跟我反馈：“我们给客户配了ESS缩容策略，但活动记录里一条缩容都没有，不是没触发，而是信息提示‘实例受保护，跳过缩容’。”后来我去看，发现客户为了“防止误删”，给所有实例都开了缩容保护。结果就是，缩容规则形同虚设，机器一台也没少。

排查这类问题，可以先看伸缩活动记录里的跳过原因，再逐一确认每个实例的“缩容保护”开关状态。正确策略是：只给少数承担特殊功能的实例开启保护，比如还在初始化中的实例、正在跑批处理的实例、需要长期保留IP的实例，其他普通实例一律不开启保护。把保护范围缩小，才能既保护关键实例，又让缩容策略真正生效。

6.3 冷却时间与优雅下线时长不匹配

客户业务实例被缩容时，最理想的流程是：先从SLB摘除流量，等待存量请求处理完成，再停止业务进程，最后释放实例。但ESS默认的缩容动作是直接释放实例，并不会自动执行“优雅下线”全套流程。

如果客户应用的存量请求处理需要30秒，而ESS的缩容流程在这30秒内就把实例释放了，客户侧就会出现请求中断。所以渠道商要做到两件事：一是在应用实例模板中加入优雅下线脚本，比如通过云助手在实例释放前执行“从注册中心摘除、清理连接、停止服务”等命令；二是把冷却时间设置得足够长，确保缩容后系统有充足时间观察新状态，而不是立刻又触发下一次伸缩动作。

每一次缩容都像一次“有损手术”，操作前必须想清楚业务能不能承受，操作后必须做好验证。

6.4 跨账号代运维时的RAM权限边界

很多渠道商是同时管理多个客户账号的，这时候给客户配置ESS缩容，最好不要用客户的主账号直接操作。渠道商的交付人员应该通过RAM子账号来做日常配置和查看，最小够用权限建议包括ESS的读写权限、云监控的只读权限、ECS的只读权限，以及SLB的只读权限。缩容动作属于高危操作，如果子账号权限过大，一旦误操作可能批量释放客户实例。

建议使用资源目录和SCP策略，限制子账号只能操作指定伸缩组或指定标签下的实例，同时把操作审计打开，记录谁在什么时间做了缩容释放操作。渠道商给客户做优化，安全永远是第一位的，成本节省的前提是不能出事。

我个人的习惯是，在给任何客户上线ESS缩容方案前，先拿一个低风险业务跑一周，确认数据安全、冷却时间、缩容保护这三个点都没有问题，再推广到整个伸缩组。这套“先验证再扩张”的方式，让我少踩了很多次半夜被客户叫起来处理“实例没了”的坑。ESS智能缩容本身不复杂，复杂的是控制住它带来的不确定性和风险。