Set Up Aurora Serverless Instant Scaling: Walkthrough

This walkthrough gets you a real, working demonstration of Aurora Serverless instant scaling — you’ll stand up a cluster, confirm it’s on the right platform version, hammer it with a quick load test, and watch the ACU count jump in CloudWatch in near real time. Budget about 30 minutes, plus a few dollars in AWS charges you’ll tear down at the end.

Prerequisites

Before you start, make sure you have: the AWS CLI v2 installed and configured with credentials that can create RDS resources; an existing VPC with at least two subnets in different Availability Zones (Aurora requires this); the psql client or an equivalent (or the RDS Data API if you’d rather skip network access setup); and an IAM role or user with permissions for rds:CreateDBCluster, rds:CreateDBInstance, and rds:ModifyDBCluster.

One more thing worth knowing going in: this whole exercise costs real money, even at the small scale we’re using here. A cluster sitting at MinCapacity=1 for the roughly half hour this takes runs a few cents, and the brief scale-up during the load test adds a little more. It’s not going to surprise anyone on a bill, but don’t let the cluster run past this walkthrough — the cleanup step at the end isn’t optional busywork, it’s the actual point where the meter stops.

1. Create the Aurora Serverless v2 cluster. This provisions a PostgreSQL-compatible cluster with scaling bounds set from the start — MinCapacity 1 keeps it warm, MaxCapacity 16 is plenty for this test.

   aws rds create-db-cluster \
     --db-cluster-identifier scaling-demo-cluster \
     --engine aurora-postgresql \
     --engine-version 16.4 \
     --master-username demoadmin \
     --master-user-password 'ChangeMe12345!' \
     --serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=16 \
     --vpc-security-group-ids sg-0123456789abcdef0 \
     --db-subnet-group-name default

2. Add a serverless instance to the cluster. The cluster alone has no compute — you need at least one instance with the db.serverless class.

   aws rds create-db-instance \
     --db-instance-identifier scaling-demo-instance-1 \
     --db-cluster-identifier scaling-demo-cluster \
     --engine aurora-postgresql \
     --db-instance-class db.serverless

3. Wait for the cluster to become available, then confirm the platform version. Instant scaling only kicks in on platform version 3 or later — this confirms you actually have it.

   aws rds wait db-instance-available \
     --db-instance-identifier scaling-demo-instance-1
   
   aws rds describe-db-clusters \
     --db-cluster-identifier scaling-demo-cluster \
     --query 'DBClusters[0].[Status,ServerlessV2PlatformVersion]' \
     --output table

   If the platform version field looks unfamiliar, cross-check it against the Aurora serverless administration guide — new clusters created today land on the current platform version by default, so you shouldn’t need to do anything extra here.

4. Grab the cluster endpoint and connect.

   aws rds describe-db-clusters \
     --db-cluster-identifier scaling-demo-cluster \
     --query 'DBClusters[0].Endpoint' --output text
   
   psql -h  -U demoadmin -d postgres

5. Create a table with enough rows to make a load test meaningful. Inside psql:

   CREATE TABLE load_test (id serial PRIMARY KEY, payload text);
   
   INSERT INTO load_test (payload)
   SELECT md5(random()::text)
   FROM generate_series(1, 500000);

6. Open a second terminal and start watching the ACU metric live. This polls CloudWatch every 30 seconds so you can see capacity move in near real time.

   watch -n 30 "aws cloudwatch get-metric-statistics \
     --namespace AWS/RDS \
     --metric-name ServerlessDatabaseCapacity \
     --dimensions Name=DBClusterIdentifier,Value=scaling-demo-cluster \
     --start-time \$(date -u -d '5 minutes ago' +%Y-%m-%dT%H:%M:%S) \
     --end-time \$(date -u +%Y-%m-%dT%H:%M:%S) \
     --period 60 --statistics Maximum \
     --query 'Datapoints[*].[Timestamp,Maximum]' --output table"



7. Fire the load test. Back in your psql session (or a script hitting it concurrently), run a query heavy enough to force a scale-up — a full sort across the half-million rows works well:

   SELECT payload, count(*) OVER ()
   FROM load_test
   ORDER BY payload
   LIMIT 100000;

   Run that a handful of times back-to-back, ideally from a few concurrent connections, to simulate the kind of burst an agentic workload throws at a database.

8. Watch capacity climb in the second terminal. You should see ServerlessDatabaseCapacity jump quickly toward — and potentially past — the 12 ACU mark within the first minute of sustained load, well before it would have under the pre-August-2026 scaling curve. Check the official announcement for the exact mechanics of the instant jump.
9. Let it idle and confirm scale-down. Stop running queries and keep watching — capacity should step back down toward your MinCapacity of 1 ACU over the following several minutes as load clears.
10. Tear everything down. Don’t leave this running — even at MinCapacity 1, you’re paying for it.

    aws rds delete-db-instance \
      --db-instance-identifier scaling-demo-instance-1 \
      --skip-final-snapshot
    
    aws rds delete-db-cluster \
      --db-cluster-identifier scaling-demo-cluster \
      --skip-final-snapshot

Reading What Aurora Serverless Instant Scaling Just Did

If your CloudWatch output showed capacity climbing past 12 ACUs within the first minute or two of sustained load, you just watched the exact behavior AWS shipped on August 5, 2026 — the difference from the old gradual ramp is most obvious if you happen to have an older cluster around for comparison, since the pre-update curve took noticeably longer to reach the same capacity. If your numbers looked flatter than expected, double-check two things: that your load test actually generated enough concurrent, expensive queries to register as real demand (a single lightweight query rarely moves the needle), and that your cluster genuinely landed on a current platform version rather than an older one that predates this change.

It’s also worth noting what scaling back down looked like. Aurora Serverless doesn’t drop capacity instantly the moment load clears — it holds capacity for a stabilization window before stepping down, which avoids flapping between capacity levels if your traffic is naturally spiky rather than a single clean burst. That’s a deliberate tradeoff: slightly more conservative scale-down in exchange for not thrashing your cluster’s capacity every time load dips for thirty seconds.

What You Built

You now have hands-on proof of how Aurora Serverless instant scaling behaves under real load — not just a description from a launch announcement. You provisioned a cluster with explicit MinCapacity/MaxCapacity bounds, verified it landed on a platform version that supports the faster scale-up, generated enough load to force a scaling event, and watched the ACU metric respond in CloudWatch in near real time. That same pattern — set your bounds deliberately, watch ServerlessDatabaseCapacity, and load test before trusting it in production — is exactly what you’d do before pointing a real agentic workload or bursty API at this cluster, just with higher stakes and a bigger MaxCapacity.

At Enkompass (enkompass.net), this is our home turf. We’ve load-tested Aurora Serverless configurations for clients before their AI features hit production, catching MaxCapacity ceilings that would’ve throttled real traffic. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.