# Amazon Aurora Serverless gets faster burst scaling AWS has changed Aurora Serverless scale-up behavior so platform-version 3 and 4 clusters can add about 12 ACUs of capacity within a second before continuing toward 256 ACUs, materially reducing the first-step lag for sharp traffic bursts. Aurora Serverless can now add roughly 12 ACUs in the first second of a scale-up event on platform versions 3 and 4. The change is automatic and is most useful for bursty SaaS, API, batch and agent workloads, but it does not remove the separate resume delay when a database has scaled all the way to zero. - Status: Active - Published: 2026-08-21T06:20:14+12:00 - Updated: 2026-08-21T06:20:14+12:00 - Categories: Cloud & Infrastructure, Databases & Storage - Tags: Amazon Aurora, Aurora Serverless, AWS, database autoscaling - Canonical HTML: https://beyondthe.news/dossiers/amazon-aurora-serverless-faster-burst-scaling ## 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. ## Key details - AWS announced the faster Aurora Serverless scale-up behavior on August 5, 2026. - The service can add about 12 ACUs within one second during a scale-up event, then continue scaling toward a configured maximum of up to 256 ACUs. - One ACU represents approximately 2 GiB of memory plus corresponding CPU and networking, making the initial step roughly 24 GiB of memory-equivalent capacity. - The enhancement is enabled by default on Aurora Serverless platform versions 3 and 4; platform versions 1 and 2 need an upgrade to version 4. - AWS's platform-version-4 test scaled an Aurora PostgreSQL instance from 0.5 ACU to 12 ACUs within one second. - A DevelopersIO check independently observed a jump from 1 to 13.5 ACUs in one second after scaling began, but its trigger was a MinCapacity configuration change rather than workload autoscaling. - Scaling beyond the first roughly 12 ACUs remains incremental; the independent test took about 3 minutes 45 seconds to reach 30 ACUs after the configuration change. - Scale-from-zero remains a separate path: AWS documents a typical auto-resume time of about 15 seconds, or 30 seconds or longer after a deep sleep. - Aurora Serverless capacity remains billed per second in ACUs; the cost impact of the faster initial jump depends on workload shape and minimum-capacity settings. ## Builder takeaways - Check `ServerlessV2PlatformVersion` before assuming the new behavior is active. Platform versions 3 and 4 receive it automatically; older platform versions need an upgrade. - Re-test the minimum ACU setting for bursty workloads. If a high minimum was primarily insurance against slow scale-up, the new first-step capacity may let you lower that floor without the same performance risk. - Do not size only around the 12-ACU jump. Workloads that need materially more capacity still depend on subsequent scaling, so load-test the time to reach your real peak and set the maximum high enough. - Treat scale-to-zero separately from burst scaling. If requests cannot tolerate roughly 15 seconds of resume latency, keep a nonzero minimum or design connection and retry behavior around the documented resume path. - Monitor `ServerlessDatabaseCapacity` and `ACUUtilization` at fine granularity during realistic spikes before and after changing capacity settings; the economic benefit comes from lower idle headroom only if burst allocation does not create unacceptable spend or latency. - Use AWS's provisioned-instance comparison as directional evidence, not a sizing guarantee. Cache warmth, engine version, query mix, connection behavior and data shape can materially change results. ## What to watch - Independent workload-triggered benchmarks for both Aurora PostgreSQL and Aurora MySQL across different starting capacities and spike shapes. - Whether AWS increases the size of the instant first scaling step beyond about 12 ACUs or shortens the subsequent climb toward high capacities. - Whether scale-from-zero resume latency improves separately from active-instance scaling. - Real production cost data showing whether teams can safely lower minimum ACUs enough to offset the faster allocation of capacity during bursts. ## Uncertainties - AWS's one-second and provisioned-performance comparisons are vendor-produced benchmarks, not independent measurements across representative production workloads. - The independent DevelopersIO test was a single platform-version-4 Aurora PostgreSQL measurement triggered by a MinCapacity change with no database load; it corroborates the capacity jump but not workload-triggered end-to-end latency. - The new one-second scaling behavior does not imply a one-second resume from 0 ACUs or instantaneous scaling to 256 ACUs. - Actual cost effects are workload-specific because faster scaling can both reduce the need for idle minimum capacity and allocate more billable ACUs earlier during a burst. ## Sources - [Amazon Aurora serverless now scales faster to support agentic AI and other bursty workloads](https://aws.amazon.com/about-aws/whats-new/2026/08/aurora-serverless-instant-12-acu-scaling/) — Amazon Web Services · primary · 2026-08-05T00:00:00+12:00. Primary launch announcement for the higher initial scale-up capacity, platform-version eligibility and default enablement. - [Faster scaling for Aurora serverless to support agentic AI and other spiky workloads](https://aws.amazon.com/blogs/database/faster-scaling-for-aurora-serverless-to-support-agentic-ai-and-other-spiky-workloads/) — Amazon Web Services · primary · 2026-08-14T00:00:00+12:00. AWS technical post with the 0.5-to-12-ACU one-second test and vendor-produced comparison against a provisioned db.r8g.xlarge instance. - [How Aurora serverless works](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html) — Amazon Web Services · primary. Current documentation for ACU composition, capacity ranges and scaling behavior. - [Scaling to Zero ACUs with automatic pause and resume for Aurora serverless](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2-auto-pause.html) — Amazon Web Services · primary. Primary documentation separating auto-pause/resume from active scaling and documenting typical resume latency of about 15 seconds. - [Amazon Aurora Pricing](https://aws.amazon.com/rds/aurora/pricing/) — Amazon Web Services · primary. Current pricing and billing model for Aurora Serverless ACU capacity, storage and I/O. - [Aurora serverless: Faster performance, enhanced scaling, and still scales down to zero](https://aws.amazon.com/blogs/database/aurora-serverless-faster-performance-enhanced-scaling-and-still-scales-down-to-zero/) — Amazon Web Services · primary · 2026-04-20T00:00:00+12:00. Primary context for the earlier doubled scaling rate, platform-version-4 performance changes and vendor-produced cost/performance benchmarks that preceded the August initial-jump enhancement. - [I measured the initial capacity performance of the Aurora Serverless v2 update "Up to 12 ACUs in under 1 second"](https://dev.classmethod.jp/en/articles/aurora-serverless-v2-initial-capacity-12acu-measurement/) — DevelopersIO · secondary · 2026-08-06T00:00:00+12:00. Independent single-run check that reproduced a roughly 12-ACU one-second initial jump; importantly, it used a MinCapacity configuration change with no workload.