AWS于8月12日宣布，Amazon Aurora Serverless改进突发负载的扩容速度。数据库在需要增加容量时可以先快速提升到最多12个Aurora Capacity Unit，并在流量继续增长时向最高256 ACU扩展。
这次变化面向请求突然出现、持续时间不固定的数据库工作负载。Agentic AI任务、批量处理和活动型网站都可能在较长空闲期之后迅速产生大量查询，传统的平缓扩容容易在最初几秒形成等待队列。
扩容开始后1秒内可达到12 ACU
新的扩容机制会在检测到容量需求时提供更高的初始增量。AWS给出的指标是最多可在1秒内达到12 ACU，减少数据库从低负载状态追赶突发请求的时间。
ACU是Aurora Serverless的容量单位，每个ACU大致对应2 GiB内存，并配套相应的CPU与网络资源。12 ACU不是固定实例规格，而是服务在扩容过程中的一个快速容量水平。
达到12 ACU也不代表所有请求都能在1秒内完成。查询复杂度、锁竞争、连接建立、缓存命中率和下游服务仍会影响应用响应，实际收益需要用业务请求验证。
容量上限仍可继续扩展到256 ACU
初始提升完成后，Aurora Serverless可以根据负载继续扩展，最高达到256 ACU。团队可以用较低容量承接日常流量，同时为不可预测的峰值保留更大的增长空间。
最大容量并不会自动解决低效SQL。缺少索引、全表扫描、大事务和热点行锁会随着并发增加放大资源消耗，即使容量能够上升，也可能出现延迟与费用同时增加。
生产数据库应设置与预算和业务峰值匹配的最小、最大容量，并为ACU使用量、连接数、CPU、内存和查询延迟配置告警。只提高上限而不观察增长原因，容易把异常流量转化为持续账单。
Agentic AI带来更不规则的查询波峰
Agentic AI应用会根据任务自主拆分步骤、调用工具并反复读取状态。一次用户请求可能触发多轮检索、记忆读写和工作流更新，数据库并发不再简单跟随网页访问量线性增长。
这类任务常有明显的空闲窗口，也可能在批量代理同时执行时形成瞬时高峰。更快的初始扩容能够缩短容量准备时间，尤其适合无法准确预估每轮任务会产生多少查询的场景。
数据库仍应与模型推理、向量检索和任务队列分层。把所有中间状态都高频写入关系数据库，可能制造不必要的热点；缓存、队列与写入合并仍是控制延迟和成本的重要手段。
空闲时降至零可减少计算费用
Aurora Serverless v2支持符合条件的数据库在无活动时自动暂停并降到0 ACU，工作负载重新到来后再恢复。暂停期间不收取数据库实例容量费用，但存储、备份和其他相关服务仍可能计费。
降到零适合开发测试、内部工具和间歇任务，不一定适合持续在线接口。恢复数据库需要时间，依赖连接池的应用也要处理断开后的重连，不能把自动暂停理解为完全无感。
部分功能或配置会影响自动暂停资格。启用前应按照当前Aurora版本文档核对限制，并用真实空闲周期测试恢复延迟，而不是只依据最低容量参数估算体验。
上线前应测试连接与扩缩容边界
更快扩容主要改善容量追赶速度，但应用连接仍可能成为瓶颈。突发任务如果同时新建大量数据库连接，会增加认证、内存和线程压力，可考虑使用连接池或RDS Proxy控制并发。
压测应包含从低容量或暂停状态突然升高的场景，并记录首批请求延迟、达到目标ACU的时间、错误率和费用变化。只在数据库已经预热的稳定高负载下测试，无法反映此次更新的主要价值。
团队还要为缩容行为设置观察窗口，避免短周期波动导致容量频繁变化。把最大ACU、查询治理、连接管理和成本告警一起设计，才能让快速扩容真正服务于不规则业务，而不是掩盖数据库结构问题。
