报错是这么冒出来的。为高峰期准备了两个专属推理实例，按小时计费，夜间业务停跑但实例没释放，一天闲置十个多小时，月底账单比按调用量估算的高出四成，控制台里实例状态一直是 running。
中间走过弯路，把「预留实例的最小计费单位是一小时，短时启停不划算」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。专属实例按开机时长计费，与有没有请求无关。还有一种是没有配置闲时自动缩容，实例一直保持常驻。
不容易想到的是，监控只看了 QPS 没看单位请求成本，闲置没有被发现。
上来先统计每天的请求分布与实例在线时长
python -c "print({'peak_qps':42,'night_qps':0,'uptime_hours':24})"然后按时间窗口设置定时缩容
aws application-autoscaling put-scheduled-action --service-namespace custom --scheduled-action-name night-down --schedule 'cron(0 22 * * ? *)' --scalable-target-action MinCapacity=0,MaxCapacity=0给闲置时长加一条告警
python -c "print({'alert_when_idle_minutes': 30})"剩下的就是核算闲置成本占比后再决定保留几台
python -c "print({'idle_cost_ratio':0.4,'keep':1})"恢复的判定其实很直接。夜间实例缩到零，白天按峰值拉起，账单里闲置时长降到两小时以内，高峰期的排队时间没有明显增加。
提醒一点。专属实例买的是确定性，闲置也照付，排班表和伸缩策略要一起设计，不然预算全花在没人的时段。报错文案容易误导，真正的原因往往在相邻那一层的日志里。