What changed
On August 5, 2026, AWS announced a new initial scale-up behavior for Amazon Aurora Serverless: supported clusters can add about 12 Aurora Capacity Units (ACUs) within a second, then continue scaling as demand rises, up to the configured maximum of 256 ACUs. AWS says the behavior is enabled by default on serverless platform versions 3 and 4, with no configuration change required; clusters on platform versions 1 and 2 can upgrade to platform version 4. Each ACU represents approximately 2 GiB of memory plus corresponding CPU and networking, so the initial jump represents roughly 24 GiB of memory-equivalent capacity. AWS followed the launch with a technical post showing an Aurora PostgreSQL platform-version-4 cluster scaling from 0.5 ACU to 12 ACUs within one second under its test workload.
Why it matters
A core Aurora Serverless trade-off is how low to set minimum capacity without leaving too much performance headroom to recover when traffic spikes. A much larger first scaling step narrows that trade-off: a lightly provisioned active database can acquire materially more CPU and memory almost immediately instead of climbing through small capacity increments while a burst is already in flight. That can make lower minimum-capacity settings more practical for spiky SaaS, API, batch and agent workloads and reduce the need to pay continuously for idle headroom. The boundary is important, however: this is not instant scaling to 256 ACUs, and it does not eliminate the separate resume latency for an instance that has auto-paused at 0 ACUs.
The first scaling step is now much larger
AWS says Aurora Serverless can now add 12 ACUs to its current capacity within a second and that this instant step is supported at any ACU level inside the cluster's configured minimum and maximum range. Capacity can continue scaling afterward to as much as 256 ACUs. The enhancement is on by default for platform versions 3 and 4; older platform-version 1 and 2 clusters need to move to version 4 to receive it. Because one ACU includes approximately 2 GiB of memory with corresponding CPU and networking, a 12-ACU jump is roughly 24 GiB of memory-equivalent capacity arriving in the first scaling step.
AWS's benchmark shows the intended burst behavior
In AWS's August 14 technical post, an Aurora PostgreSQL cluster on platform version 4 with a 0.5-to-12-ACU range reached 12 ACUs within one second after the workload triggered scaling. AWS also compared a 4-to-16-ACU serverless cluster with a provisioned db.r8g.xlarge under a 256-thread Sysbench write workload and reported that the serverless cluster closed the initial throughput gap after roughly one minute and then matched the provisioned instance for the remainder of the run. That comparison is vendor-produced and should be treated as an illustrative benchmark rather than independent proof of equivalent performance across workloads.
An independent check reproduced the large initial jump, with caveats
DevelopersIO independently measured a platform-version-4 Aurora PostgreSQL cluster in Tokyo by raising MinCapacity from 1 to 30 ACUs. The cluster began scaling 15 seconds after the configuration change, then moved from 1 to 13.5 ACUs in one second before continuing more gradually to 30 ACUs, which it reached about 3 minutes 45 seconds after the change. The test is useful corroboration of the large initial step, but it used a MinCapacity configuration change with no workload rather than production autoscaling, so it should not be generalized into a universal end-to-end latency claim.
This does not make scale-from-zero instant
Aurora Serverless can still auto-pause at 0 ACUs when configured with a zero minimum, but AWS documents the resume path separately. A typically paused instance can take about 15 seconds to resume, and an instance that has remained paused for more than 24 hours can take 30 seconds or longer. Builders with strict connection-latency SLOs therefore should not read the new one-second scaling claim as a one-second cold start from zero.
The cost effect depends on how minimum capacity is set
Aurora Serverless capacity is billed per second in ACUs, with storage and applicable I/O billed separately. Faster initial scaling does not introduce a separate feature charge, but it can change when capacity is consumed: a burst can cause more ACUs to be allocated immediately, while teams may also be able to keep a lower minimum because the database has more headroom to react. AWS's earlier platform-version-4 benchmarks reported faster completion with lower total ACU consumption than prior platform versions, but those are vendor benchmarks. The practical cost question is workload-specific and should be tested with CloudWatch capacity and utilization metrics before changing minimums.