Skip to Content

A Guide on selecting Amazon Aurora Serverless and provisioned Database cluster

Posted on October 25, 2022 by

Categories: AWS

Tags:

The managed database service provided by AWS is called Aurora. It is an actual cloud database since it offers business-grade features and functionalities. It provides features including cross-regional replication with latency often under a second, the Aurora Global Database, deep interaction with most AWS services, custom reader endpoints, 15 replicas, and the highest availability (99.99%) in managed SQL instances family. When Serverless capabilities for Aurora were launched, the suite of functions multiplied, and a significant improvement occurred with Serverless v2. Refer to Serverless V2 for more information on this version.
With the release of the new V2 version, serverless usage increased from non-production to production ready.
To assist you in choosing the best database capacity model for your database, this blog will provide you with serverless adoption use cases.

Serverless Aurora Cluster With Provisioned Capacity

While the cluster is spinning up, you may set up an Aurora DB as Provisioned (Defined Capacity) or serverless. A predefined CPU, memory, and storage IOPS cluster is known as a provisioned capacity cluster. Although you have the opportunity to manually scale up or down the Capacity as and when Capacity needs to grow or fall, you must plan your compute requirement and configure it while spinning up. While you specify the minimum and maximum computing requirements for your cluster when using serverless, AWS monitors use demand andynamically changeses the compute Capacity. In contrast to the Read-only node auto-scaling option offered in Aurora supplied DB cluster, this scaling modifies the Aurora DB cluster’s compute (memory and associated CPU).

The benefits of serverless

Scalability, cost-effectiveness, and little operational overhead are the main benefits of Aurora serverless DB instances in the context of this article.

Introduction to Serverless

You may launch a Serverless Aurora cluster with just a few details, such as 1) a compatible database engine edition for MySQL or PostgreSQL.
2) Database Engine version (Please note: – Choosing an earlier version (for example, MySQL 5.7) will make the “Serverless” option greyed out since not all MySQL and PostgreSQL versions are compatible.
3) Decide on the Aurora Capacity Unit’s minimum and maximum (ACU).
The setup window for the Aurora serverless service is depicted in the diagram below.

How Capacity is Scaled with Aurora Serverless

Based on the fluctuating demand for resources, AWS adjusts the computational capability of the Reader and Writer separately. Your cluster may now include readers in addition to writers with Aurora Serverless v2. A combination of readers and writers, such as a provided writer and Aurora Serverless v2 readers, or vice versa, is also possible. Every writer and reader in the Aurora Serverless v2 platform may scale between the minimum and maximum capacity levels. As a result, the number of writers and readers in your Aurora Serverless v2 cluster and the capacity range you selected for your DB cluster, affect the cluster’s overall Capacity. Each Aurora Capacity Unit (ACU), which has about 2 gibibytes (GiB) of memory, a commensurate CPU, and networking, defines the Capacity. Scaling from 0.5 ACU to 128 ACUs in a 0.5 step is possible.

Size your desired minimum and maximum.

Although it is highly advantageous to assume the permitted minimum ACU (0.5) as the minimum Capacity, growing the Capacity will provide difficulties. Please review this AWS documentation for minimum and maximum ACU selectio recommendationsn. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.min capacity considerations

Monitor Your serverless Aurora

Behind the scenes, AWS manages the scaling of the Aurora capacity and constantly checks to ensure the capacity requirements are met. Understanding the capacity scaling is crucial to review the serverless or provisioned Aurora cluster decision and making conversions as needed.
The ServerlessDatabaseCapacity and ACUUtilization metrics in CloudWatch allow you to keep track of the Capacity used by each Aurora Serverless v2 DB instance.
It is crucial to re-evaluate the serverless option using those metrics because the cost of AWS Aurora Serverless is higher than the provided Capacity.

How to switch between serverless and provisioned Aurora

By adding a “Serverless” or “provisioned” Replica to the current cluster and elevating the Replica to the status of a “writer” instance through the failover procedure, you may convert a provisioned Aurora cluster to Serverless and vice versa. You may convert your current provided cluster to a serverless cluster using this straightforward, transparent method and vice versa.

Serverless Cluster Pricing

Database capacity is measured by Aurora Capacity Units (ACUs) and charged per second in Aurora Serverless. The cost of Serverless V2 in the “Mumbai” location is $0.18 per ACU Hour. For example, if I use an average of 8 ACU (i.e., 16GB of memory) for a month (730 hours), my AWS cost will be $1051.2: 730 *.18 (ACU Hour) * 8 (Avg ACU).

Priced at $189.80, the provisioned Aurora cluster with a 16 GB memory capacity (DB.r6g.large) is available on demand. This straightforward calculation shows that the cost for Aurora is about five times that of a supplied cluster.

As the cluster is expected to be utilized in a circumstance that dials down to a minimum of 0.5 (i.e., 1 GB) ACU, which can gradually bring down the cost, the above pricing comparison is not the proper approach to assess the TCO of running a serverless Aurora cluster. The pricing estimate above just considers the cost of an AWS DB instance; additional costs, such as those associated with monitoring and maintenance, must also be considered.

Conclusion

Choose the optimum Amazon Aurora capacity model for your database based on the use cases. It is clear that the serverless feature of Aurora (v2) is an excellent match for many specific use cases, but serverless is expensive; as a result, it employs the capability as needed.