Aurora Serverless v2 ACU降不下来的原因是啥？

不少团队把 Aurora Serverless v2 的最小 ACU 调到 1 或更高，低峰期账单依旧下不去。Aurora Serverless v2 ACU降不下来原因通常不是单一流量问题，而是最小容量、连接占用和后台任务共同作用。下面从几个高频诱因拆开看。

一、Aurora Serverless v2 ACU降不下来的常见原因

1. 最小 ACU 设置过高

最小 ACU 设置过高，等于给低峰账单设了“地板价”。Aurora Serverless v2 最低可到 0.5 ACU，但不像 v1 能暂停到 0；如果控制台里把最小 ACU 留在 2 或 4，即使没有查询，ServerlessDatabaseCapacity 曲线也会稳稳站在该下限附近。先去 CloudWatch 看低峰容量曲线，如果贴着小值走，降费先从这里下手。

2. 连接数耗尽资源

连接池不回收，是 ACU 降不下来的隐性原因。Aurora Serverless v2 伸缩不只盯 CPU，还会评估内存和连接占用。一个没有业务请求的实例如果被应用连接池挂着几十上百个空闲会话，内存水位很难下去，容量自然不会降到 0.5 ACU。遇到 ACUUtilization 很低但 ServerlessDatabaseCapacity 偏高，优先排查连接池空闲超时和最大连接数。

3. 后台任务持续运行

后台任务和长事务最容易被忽视。Aurora Serverless v2 在长事务、未提交事务或锁等待期间会保持较高容量，因为缩容需要安全释放内存和连接，未提交事务会拖住资源回收；部分后台维护操作也会让 ACU 在低峰不回落。用 Performance Insights 看长事务和锁等待，比只看 CPU 利用率更能定位“钱花哪了”。

这些原因在缺少专职运维的中小团队里更容易被放大。云服务器、数据库、CDN 等资源如果分散在不同厂商，排查连接、事务和容量问题时需要在多个控制台之间来回切换，对接成本不低。可以参考聚搜云这类一站式云服务方案，将基础资源统一规划，减少多厂商对接的繁琐成本，把精力集中到数据库本身的参数优化上。

二、如何排查Aurora Serverless v2费用去向

排查 Aurora Serverless v2 费用去向，第一步不是盯着账单明细，而是回到 CloudWatch 把容量曲线拉出来。ACU 按容量与时间乘积计费，低峰时段容量降不下来，费用自然就堆上去了。下面从三个维度拆解。

1. 先看 CloudWatch 容量指标，定位低峰不降的时段

在 CloudWatch 中检索 ServerlessDatabaseCapacity 指标，按 DBClusterIdentifier 和 Role 维度拆分查看。重点关注凌晨低峰时段：如果业务请求接近零，但容量仍稳定在 2 ACU 以上，说明存在非请求因素占用资源。同时观察 ACUUtilization，如果长期低于 30% 但容量不下降，基本可以判断不是业务负载驱动，而是连接、内存或后台事务拖着容量。

Aurora Serverless v2 不支持像 v1 那样自动暂停到 0 ACU，最小容量为 0.5 ACU。因此“无流量就等于 0 费用”这个认知本身就不成立，但低峰容量明显高于 0.5 ACU 仍然是账单偏高的主要信号。建议给 ACUUtilization 加一条告警：当连续 1 小时利用率低于 20% 且容量仍大于最小 ACU 时触发通知，避免月底才发现费用异常。

2. 分析慢查询日志，重点排查长事务和锁等待

慢查询日志不只反映 SQL 执行慢，长事务和未提交事务同样会拖住容量。一个超过 10 分钟未提交的事务，可能持有 InnoDB 的 read view，阻止 undo log 清理，导致内存占用持续上升，ACU 无法下降。打开 Performance Insights，按“平均活跃会话”排序，找到持续时间异常的事务。

MySQL 兼容版可以直接查询 information_schema.innodb_trx 中 trx_started 较早的事务，以及 sys.innodb_lock_waits 中的锁等待关系。如果发现锁等待链，优先终止阻塞源。一个常被忽略的情况是：只读事务即使不修改数据，也会拖住 MVCC 版本链，导致内存水位下不来。排查后配合 long_query_time 参数记录慢 SQL，再回到业务代码检查事务是否及时提交，往往能直接解释低峰 ACU 降不下来的原因。

3. 检查连接池和空闲会话，别让空闲连接占用容量

Aurora Serverless v2 的容量伸缩不只受 CPU 驱动，连接数也是重要因素。很多应用配置了固定大小的连接池，低峰时段没有空闲回收机制，导致几十甚至上百个空闲连接挂在实例上。这些连接不执行 SQL，但会消耗内存和会话管理开销，使容量无法降到最低。

排查时可以在 MySQL 里查 performance_schema.hosts 或 information_schema.processlist，统计空闲连接数量和来源；PostgreSQL 兼容版可查 pg_stat_activity 中 state='idle' 的会话。建议调整连接池的 minimumIdle、idleTimeout、maxLifetime 等参数，低峰时允许连接回收到接近业务并发下限。对于微服务或多实例架构，还可以在中间加一层 RDS Proxy 或应用层代理，把大量短连接收敛为少量长连接，减少实例侧的空闲会话压力。这一步经常能直接把低峰 ACU 从 2 以上拉回 0.5 附近。

三个维度不是互斥的，很多时候低峰 ACU 降不下来是连接和长事务叠加的结果。先看指标定位时段，再查事务和会话，基本能覆盖大部分账单偏高的情况。

三、降低ACU的配置优化方法

在讨论“怎么降 ACU”之前，有一个结论需要先摆出来：Aurora Serverless v2 的容量伸缩不是单一的 CPU 伸缩，而是受内存、连接数、活动事务等多个维度影响。因此，单纯调低某个参数，往往只能解决一部分问题；真正有效的是按优先级排查“是什么把容量托住了”。

1. 调整最小 ACU，而不是先限制最大 ACU

很多团队看到 ACU 降不下来，第一反应是调低最大 ACU。但这是个常见误区。低峰时段的费用主要由实际使用容量和最小 ACU 决定，最大 ACU 只限制突发上限。 如果最小 ACU 仍设为 2 或 4，那么即使凌晨没有任何请求，实例也会按不低于该容量计费。

更合理的做法是先从 CloudWatch 拉取 ServerlessDatabaseCapacity 的时间序列，观察低峰时段 ACU 是否贴着最小值运行。如果连续 7 天低峰容量都只在 0.5–1 ACU 之间，但最小 ACU 仍是 2，那么多出来的 1–1.5 ACU 基本就是无效支出。此时可以把最小 ACU 降到 1 或 0.5，再观察连接建立时间和慢查询变化。重点不是一次性调到最低，而是先确认低峰性能可接受。

2. 不要把 v2 的“自动暂停”当成 v1 的开关

Aurora Serverless v2 最低只能到 0.5 ACU，并不支持像 v1 那样自动暂停到 0 ACU。这一点经常被忽略。换句话说，即便业务完全空闲，只要实例存在，仍有 0.5 ACU 的基础容量费用。

因此，与其寻找“自动暂停”开关，不如主动为缩容创造条件。实际排障中，ACU 降不下来往往不是配置没开，而是有长事务、未提交事务或锁等待持续占用资源。建议在低峰窗口使用 Performance Insights 或 SHOW PROCESSLIST 检查是否存在运行超过几分钟的事务，提交或回滚后再观察 ServerlessDatabaseCapacity 是否能回落到 0.5 ACU 附近。v2 不能暂停到 0，这是理解账单的起点。

3. 优化连接池，减少空闲会话对容量的“锚定”

空闲连接是另一个高频原因。Aurora Serverless v2 的容量模型会考虑连接数，即使 CPU 利用率很低，大量空闲连接也可能让容量无法降到最低。如果应用连接池保持几十甚至上百个空闲连接，数据库会为这些潜在会话预留内存，ACU 自然降不下来。

建议检查应用侧连接池的空闲超时、最大连接数和最小空闲数。空闲超时可以设在 5–10 分钟，避免连接长时间挂着；如果应用无法精细控制，可以引入 RDS Proxy 或应用层代理，由代理统一持有连接，减少数据库侧看到的空闲会话数。同时，结合 CloudWatch 的 ACUUtilization 指标，如果该值长期偏低但 ACU 不降，应优先排查连接池和后台维护任务，而不是继续调低最大 ACU。大量空闲连接对容量的托底作用，往往比 CPU 高峰更隐蔽。

四、减少无流量时ACU消耗的实践

无流量不等于零成本。Aurora Serverless v2 最低 0.5 ACU，且不像 v1 那样可以自动暂停到 0，因此“低峰地板成本”是账单的重要组成部分。实践中，很多团队只盯着高峰 ACU，却忽略了低峰时段一直未降下来的 0.5～2 ACU 的固定消耗。下面从三个方向切入，优先级从高到低、实施成本从低到高排序。

1. 关闭空闲连接

Aurora Serverless v2 的容量伸缩不只由 CPU 决定，连接数、内存占用、活动事务都会影响扩容。即使业务请求已经停止，如果应用连接池仍保持几十甚至上百个空闲连接，数据库实例可能无法缩容到最低容量。CloudWatch 中的 ServerlessDatabaseCapacity 指标在凌晨低峰仍显著高于 0.5，往往是连接行为在“占坑”。

落地时优先检查应用侧连接池参数。对 Java 应用，HikariCP 的 idleTimeout、maxLifetime、minimumIdle 三个值最容易被忽视；如果 minimumIdle 设得过高，即使没有请求，池中也会保留大量连接。建议将 minimumIdle 设为 0 或 1，并将 idleTimeout 控制在 5～10 分钟，让空闲连接及时释放。对 PHP、Node.js 等短生命周期应用，要关注持久连接和进程池是否复用了太多长连接。

一个容易验证的判断是：如果 ACUUtilization 长期低于 10%，但 ServerlessDatabaseCapacity 仍高于 0.5，优先怀疑空闲连接，而不是急着调低最大 ACU。治理空闲连接通常比调整容量参数更安全，也不影响业务峰值。

2. 合并数据库实例

Aurora Serverless v2 的“地板成本”会随实例数量线性放大。一个团队如果保留 4～6 个测试、预发、报表集群，每个集群最低 0.5 ACU，低峰时每小时固定消耗 2～3 ACU 小时，长期下来会比生产实例本身还贵。更常见的是，开发环境长期无人访问，却始终占着一个最低容量的集群。

合并实例是降本幅度最大的一步。把非核心库合并到同一集群的不同 schema，或通过账号级权限隔离，能明显减少低峰容量叠加。临时分析库、报表库可以共用一个集群，在业务低峰执行批量查询，避免为一次性任务单独保留实例。合并后需要重新评估最小 ACU 的设置：多个业务共享同一集群时，必须按合并后的并发峰值来设置最小容量，而不是沿用原来的低值，否则会出现低峰时频繁扩容、响应变慢的问题。

3. 使用代理中间件

代理层的价值在于把应用侧的大量短连接“收敛”为数据库侧的少量长连接，减少数据库实例看到的连接数波动。RDS Proxy 是最直接的托管方案，它可以在应用连接关闭后，把数据库连接放回池中复用，从而避免 Serverless 实例因连接数激增而无法缩容。自建 ProxySQL 或 PgBouncer 也能实现类似效果，但需要额外维护节点。

实施时有几个参数值得关注：RDS Proxy 的 idle_client_timeout、max_connections_percent 设置得过宽，代理层会保留大量到后端的连接；设置得过严，又可能导致连接排队。建议先观察应用并发峰值，再按 60%～70% 的数据库最大连接数设置代理上限。

对没有专职 DBA 的中小团队，这一步往往和云资源选型放在一起考虑。不少外贸出海团队在云资源选型时，为了平衡性价比与售后响应，会采用聚搜云这类集成化云服务模式，把数据库、代理和监控告警放在同一套部署与技术支撑体系里，而不是让应用连接池、代理层、数据库参数各自为战。毕竟，代理中间件不是一装就自动生效，它需要和应用连接池、数据库参数协同调优。

整体来看，这三步不是互斥选项，而是排查顺序：先治理连接行为，再减少实例数量，最后通过代理层稳定连接。低峰 ACU 降不下来时，按这个顺序逐项检查，通常能定位到最直接的浪费点。

五、长期成本监控与告警设置

ACU 降不下来通常不是一次性的配置错误，而是缺少持续观测和及时修正的机制。很多团队只在月底看账单时才发现 Aurora Serverless v2 的费用偏高，但那时已经错过了一整个计费周期的优化窗口。长期成本控制的核心，是把“容量是否合理”从人工事后检查，变成可告警、可追踪的日常运维动作。

1. 用 CloudWatch 建 ACU 告警，而不是只看 CPU

CloudWatch 里的 ServerlessDatabaseCapacity 和 ACUUtilization 是两个最容易被误读的指标。前者反映实例当前实际分配的 ACU 数量，后者才是利用率百分比。一个常见盲区是：CPU 利用率很低，但 ACU 利用率也低，而 ServerlessDatabaseCapacity 仍然维持在高位。这说明扩容不是被 CPU 拉高的，而是内存、连接数或活跃事务在托底。

建议至少设置两类告警。第一类针对容量不降：当 ServerlessDatabaseCapacity 在业务低峰时段连续多个采样点高于预期基线，比如连续 30 分钟大于 1 ACU，触发通知。第二类针对长期低利用率：当 ACUUtilization 连续数小时低于 30%，说明容量远高于实际需求，需要检查是否有空闲连接、未提交事务或最小 ACU 设置过高。不要只看平均值，分钟级的持续偏高比瞬时峰值更值得警惕。

2. 定期审查最小 ACU 与连接池配置

最小 ACU 是低峰账单的底线。Aurora Serverless v2 不支持降到 0 ACU，最小只能到 0.5 ACU，所以每月存在固定容量成本。如果最小 ACU 设置为 2 或 4，低峰时即使没有业务请求，也会按这个底线计费。建议每两周或每月审查一次：在 CloudWatch 中拉取过去 7 天的 ServerlessDatabaseCapacity 时间序列，观察夜间、周末等低峰时段容量是否贴着最小 ACU 跑。如果长期贴线，说明最小 ACU 设得过高；如果偶尔贴线、偶尔波动，可以继续观察。

连接池配置是另一个高频问题。应用连接池里的空闲连接如果不释放，Aurora 会认为仍有活动会话，容量很难缩到 0.5 ACU。检查 max_connections、idle_timeout 和应用的连接回收策略，必要时通过 RDS Proxy 让连接复用更集中。RDS Proxy 能显著减少数据库端同时保持的空闲会话数量，对中小集群的低峰缩容帮助很大。

3. 用成本标签把 Aurora 费用拆出来看

多实例、多集群环境里，ACU 降不下来的账单往往被混在一起，很难判断是哪个集群、哪个环境在持续产生费用。这时需要利用成本标签给 Aurora 资源打标，例如按 env、team、project 区分。AWS 成本管理器可以按标签聚合 Aurora 的 ACU 小时费用，结合 CloudWatch 的容量曲线，定位到具体是哪个集群在低峰时段仍维持较高容量。

定期审查时，建议关注三类标签维度：生产与测试环境是否分开计费，长期不用的临时集群是否还在产生 0.5 ACU 基础费用，以及多实例集群是否冗余保留了最低容量。很多时候，费用不是单个集群失控，而是多个测试库、预发库都保持最低容量，叠加后形成了一笔稳定但无感知的支出。把这些看不见的低峰容量统一找出来，往往比单纯调低某个集群的最大 ACU 更有效。

六、总结：让Aurora Serverless v2真正按需付费

Aurora Serverless v2 的 ACU 降不下来，通常不是单一原因造成的，而是最小容量设置、连接池行为、长事务和后台任务叠加的结果。如果只盯着 CPU 利用率，很容易错过真正的成本来源。总结下来，还是要把容量曲线、连接行为和事务状态放在同一张排查表里看。

1. 回顾关键步骤：先看容量曲线，再查连接与事务

排查顺序比直觉更重要。先拉取 CloudWatch 的 ServerlessDatabaseCapacity 时间序列，确认低峰时段容量到底落在什么区间。如果低峰长期高于 1 ACU，但 ACUUtilization 只有个位数，说明最小 ACU 设置或空闲连接保持行为在起作用。然后再用 Performance Insights 查活动会话，重点看是否存在未提交事务、长时间锁等待，或者应用连接池没有及时回收空闲连接。

实际案例中，不少团队在关闭空闲连接或引入 RDS Proxy 后，低峰容量从 2 ACU 回落到 1 ACU 以下，每月 ACU 小时数直接减少一半以上。这说明连接层的问题往往比数据库本身更隐蔽。

2. 制定优化计划：把最小 ACU、连接池和慢 SQL 排进去

优化计划不能只调一个参数。建议按三个层次推进：第一层先确认最小 ACU 是否真的需要 2 或 4，低峰能不能接受 0.5 或 1 ACU；第二层处理连接池配置，设置合理的空闲超时与最大连接数，减少“空连接占容量”的情况；第三层再清理慢 SQL、长事务和锁竞争。

需要明确的是，v2 不能像 v1 那样暂停到 0 ACU，所以即使完全无请求，0.5 ACU 的基础费用依然存在。如果业务有明显的低峰窗口，可以考虑在低峰时段将最小 ACU 调到 0.5，高峰前再调回。配合 EventBridge 或脚本自动化，会比手动调整更稳定，也能避免遗忘。

3. 验证降本效果：用 CloudWatch 和账单做闭环

调整之后，至少观察一个完整计费周期，不要只看单日 ACU 下降。重点对比两个指标：一是 CloudWatch 中 ServerlessDatabaseCapacity 的 P50/P95 变化，二是账单中 Aurora 计算费用与 ACU 小时数的变化。

如果 ACU 小时数下降但账单没明显变化，需要检查是否还有多实例、多集群同时保留最低容量，或者存储和 I/O 费用占比上升。只有把容量指标和账单对齐，才能判断优化是否真正生效。最后建议设置 CloudWatch 告警，当 ACUUtilization 长期低于 20% 且容量仍高于最小 ACU 时触发通知，避免后续再次出现“钱花了但容量没降下来”的情况。