Moving from Aurora to Aurora Serverless

Vinu, you can do this, but I will caveat this a little later. Aurora Serverless v2 is billed in Aurora Capacity Units (ACUs). One ACU is combination of approximately 2 gibibytes (GiB) (a gibbibyte is 1024^3) of memory, corresponding CPU, and networking. You don't mention the DB instance type that your provisioned Aurora is using, but let me therefore first give you an example.

Let's assume that you are currently using a db.r6g.xlarge, and sometimes this instance type is under-utilized. This instance has 32GB of Memory, thus if you chose 16 ACUs, as your minimum ACU setting for Aurora Serverless V2 you would be configuring broadly the same capacity as you have from this instance. If you did that, however, you would not save money, and would likely pay more.

So, assuming your database is not using the full 32GB (and you can determine this from CloudWatch), and you have capacity available on the CPU metric, you can reduce this to 8 or even less ACUs. Just be careful that you do not reduce the minimum ACU setting to below that of the amount of memory your database currently needs, else you would end up with potential problems.

For the upper scaling limit, you can choose, in this example, 16 ACUs which would let it scale up to approximately the same size as the current DB instance.

As you can imagine, from the above, costing this out is tricky, and a bit of a guesstimate, that you need to make based on the average memory used by your database, and then multiplying it by the number of ACUs that represent that amount of memory (subject to the database not being CPU constrained at that scaling level), but you can inform yourself if you will be saving money in this instance or not.

A better way, though, is to do an experiment, but bear in mind, there is a cost to this experiment.

1. Provision a read-replica for your database, and configure this read-replica to be an Aurora Serverless V2 member.
2. Configure the minimum ACU to be roughly the same as the minimum memory usage of your provisioned aurora database
3. Configure the maximum ACU to be roughly the same as the memory (2GB / ACU in 0.5 ACU increments) as the provisioned instance that you are currently using.

Observe the scaling of the read-replica, by monitoring it's ACU consumption over a few days of typical use. From this graph, you can then observe the amount you were charged for the read-replica, giving you a much better idea of costs as far as use of Aurora Serverless v2 would be.

Once you are happy, and if you decide moving to Serverless V2 is justified, simply promote the read-replica, and then once this has finished, you can remove the provisioned primary from the cluster. If you have more than one instance in your cluster, you can repeat this process to move them all to Serverless V2.

For a thorough look at this rather involved subject - I suggest you read https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html