Aurora Serverless

Aurora Serverless is a mode of Amazon Aurora (AWS’s cloud-native relational database) where you do not pick a fixed server size. Instead, the database automatically grows and shrinks its compute power to match how busy it is right now. This is great when your traffic goes up and down a lot, or when you cannot predict it, because you stop guessing the “right” instance size and stop paying for idle capacity you do not use. The current and recommended version is Aurora Serverless v2, which scales smoothly and in real time rather than in big jumps.

How Aurora Serverless v2 scales

With a normal (provisioned) database, you choose a fixed instance class, for example db.r6g.large, and you pay for that whole instance 24/7 whether it is busy or idle. Aurora Serverless v2 is different: capacity is measured in ACUs (Aurora Capacity Units, where roughly 1 ACU is about 2 GB of memory plus matching CPU and networking). You set a minimum and a maximum number of ACUs, and Aurora continuously adjusts within that range as load changes.

The scaling is fine-grained and fast. v2 can add capacity in small increments (fractions of an ACU) within seconds, so a sudden spike in queries gets more CPU and memory almost immediately, and when traffic drops the database scales back down again. You never reboot, change instance types, or fail over to resize. From your application’s point of view, the database connection string never changes.

When to use this (and when not to)

Workload pattern	Good fit?	Why
Spiky or unpredictable traffic	Yes	Scales up for peaks, down for quiet periods automatically
Dev / test / staging databases	Yes	Cheap most of the time, scales up only when used
New apps with unknown demand	Yes	No need to guess the right instance size up front
Steady, high, predictable load 24/7	No	A provisioned instance (or a Reserved Instance) is usually cheaper
Truly idle databases (zero traffic for long stretches)	Maybe not	You still pay for the minimum ACU floor continuously

The big gotcha: the minimum ACU floor

This is the part most tutorials skip. Aurora Serverless v2 does not scale to zero. The older Aurora Serverless v1 could pause a completely idle database so you paid nothing for compute, but v2 always keeps at least your configured minimum ACUs running. You pay for that floor every second, even at 3 a.m. with no traffic.

That changes the math. If you set a minimum of 0.5 ACU (the lowest v2 allows), you are billed for 0.5 ACU around the clock. For a database that is genuinely idle most of the time, this can cost more than a small fixed instance like a db.t4g.medium. So size the floor deliberately.

Cost gotcha: A minimum of 0.5 ACU running continuously costs roughly 0.5 ACU x ~$0.12/ACU-hour x 730 hours ≈ $44/month in compute alone (prices vary by Region), before storage and I/O. For a dev database that sits idle nights and weekends, that adds up. Compare it against the cost of a small provisioned instance before committing.

Tip: If your database is idle for long, predictable stretches and brief activity, consider stopping a provisioned Aurora cluster on a schedule, or keep the Serverless v2 minimum as low as your workload tolerates. Set the minimum just high enough to keep warm connections and caches healthy, not higher.

Setting up Aurora Serverless v2

Serverless v2 is configured per database instance inside an Aurora cluster by choosing the “Serverless v2” instance class and setting the capacity range.

Using the AWS Management Console

Open the Amazon RDS console and choose Create database.
Select Standard create, then pick Amazon Aurora as the engine type.
Choose your edition: Aurora MySQL-Compatible or Aurora PostgreSQL-Compatible.
Under Instance configuration, choose Serverless v2 for the DB instance class.
Set the Capacity range: a Minimum (for example 0.5 ACU) and a Maximum (for example 8 ACU).
Fill in the cluster identifier, master username, password, and your VPC (Virtual Private Cloud, your private network in AWS) and subnet group.
Choose Create database. The cluster comes up with a writer endpoint that auto-scales.

Using the AWS CLI

First create the cluster, then add a Serverless v2 instance to it with the capacity range. The capacity range lives on the cluster; the instance uses the db.serverless class.

aws rds create-db-cluster \
  --db-cluster-identifier my-serverless-cluster \
  --engine aurora-postgresql \
  --engine-version 16.4 \
  --master-username admin \
  --master-user-password 'ChangeMe123!' \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=8 \
  --vpc-security-group-ids sg-0a1b2c3d \
  --db-subnet-group-name my-db-subnet-group

aws rds create-db-instance \
  --db-instance-identifier my-serverless-writer \
  --db-cluster-identifier my-serverless-cluster \
  --engine aurora-postgresql \
  --db-instance-class db.serverless

Output:

{
    "DBCluster": {
        "DBClusterIdentifier": "my-serverless-cluster",
        "Status": "creating",
        "Engine": "aurora-postgresql",
        "ServerlessV2ScalingConfiguration": {
            "MinCapacity": 0.5,
            "MaxCapacity": 8.0
        },
        "Endpoint": "my-serverless-cluster.cluster-cabcd1efgh23.us-east-1.rds.amazonaws.com"
    }
}

Changing the capacity range later

You can adjust the floor and ceiling at any time without downtime.

aws rds modify-db-cluster \
  --db-cluster-identifier my-serverless-cluster \
  --serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=16 \
  --apply-immediately

Output:

{
    "DBCluster": {
        "DBClusterIdentifier": "my-serverless-cluster",
        "ServerlessV2ScalingConfiguration": {
            "MinCapacity": 1.0,
            "MaxCapacity": 16.0
        },
        "Status": "available"
    }
}

Infrastructure as Code (CloudFormation)

Resources:
  ServerlessCluster:
    Type: AWS::RDS::DBCluster
    Properties:
      Engine: aurora-postgresql
      EngineVersion: "16.4"
      MasterUsername: admin
      ManageMasterUserPassword: true
      ServerlessV2ScalingConfiguration:
        MinCapacity: 0.5
        MaxCapacity: 8
  ServerlessWriter:
    Type: AWS::RDS::DBInstance
    Properties:
      DBClusterIdentifier: !Ref ServerlessCluster
      Engine: aurora-postgresql
      DBInstanceClass: db.serverless

Watching it scale

Use Amazon CloudWatch (AWS’s monitoring service) to confirm scaling is working and to right-size your range. The key metric is ServerlessDatabaseCapacity, which reports the current ACUs in use over time.

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name ServerlessDatabaseCapacity \
  --dimensions Name=DBClusterIdentifier,Value=my-serverless-cluster \
  --start-time 2026-06-15T00:00:00Z \
  --end-time 2026-06-15T01:00:00Z \
  --period 300 \
  --statistics Average Maximum

If Maximum regularly hits your ceiling, raise the max so queries do not queue. If the Average rarely rises above your minimum, you may be paying for a floor that is too high.

Best practices

Set the maximum ACU high enough to absorb your worst expected spike, since hitting the ceiling throttles performance.
Set the minimum ACU as low as your workload allows, but high enough to hold warm caches and active connections without constant micro-scaling.
Remember v2 never scales to zero — for long-idle databases, compare the always-on floor cost against a small provisioned instance before choosing Serverless.
Use CloudWatch ServerlessDatabaseCapacity over a real week to right-size your min and max instead of guessing.
Mix instance types in one cluster if it helps: a Serverless v2 writer with provisioned readers, or vice versa, to balance cost and performance.
For steady, predictable production load, evaluate provisioned Aurora with Reserved Instances, which is often cheaper per hour.