Introduction
The AWS Aurora is a managed database offering by AWS. It provides enterprise grade capabilities and availabilities thus can be called as True Cloud Database. It has the capabilities like Aurora Global Database, Deep integration with most AWS services, custom reader endpoints, 15 replicas, Highest availability (99.99%) in managed SQL instances family, granular point in time recovery, cross regional replication with latency typically under a second. The suit of features improved multi fold when Serverless capabilities introduced for Aurora and substantial improvement happened in Serverless v2. Refer, Serverless V2 to know details about this version.
The serverless adoption had scaled from non-production to product ready with the new V2 version.
This blog is intended to give you serverless adoption use cases, that help you to select the right database capacity model for your database.
Serverless And Provisioned Capacity Aurora Cluster
You can configure an Aurora DB as Provisioned (Defined Capacity) or serverless while you spin up the cluster. A provisioned capacity cluster is the DB instance with preconfigured CPU, Memory and Storage IOPS for your database. You need to plan your compute requirement and configure while spin up, although you have an option to scale up/down manually the capacity as and when capacity demand increases/decreases. Whereas for serverless, you define the minimum and maximum compute requirement for your cluster, AWS monitors the usage demand and adjusts the compute capacity dynamically. This scaling adjusts the compute (memory and related CPU) of the Aurora DB cluster in contrast to the Read-only node auto scaling option available in Aurora provisioned DB cluster.
Advantages of Serverless
Aligning to the context of this blog, the major advantage of Aurora serverless DB instances are scalability, cost efficiency and minimal operational overhead.
How to Start Using Serverless
You can start Serverless Aurora cluster just by giving few details such as
1) MySQL/ PostgreSQL -Compatible Database engine edition
2) Database Engine version (Please note: - Since, not all MySQL and PostgreSQL version are compatible, selecting older version (for e.g.,- MySQL 5.7) will grayed out “Serverless” option.
3) Select the minimum and maximum Aurora Capacity Unit (ACU).
The following diagram shows the configuration window of Aurora serverless service
Once the deployment is complete, you can connect the Aurora Serverless DB cluster using DB Endpoint provided , you get dedicated endpoints for reader and The below screen shot marks the reader and writer endpoint details from the Aurora DB cluster.
Selection Criteria Between Serverless and Provisioned
The below table provides few common use cases
How Aurora Serverless Scales the Capacity
AWS scales the compute capacity of Reader and writer independently based on the dynamic resource demand. With Aurora Serverless v2, your cluster can contain readers in addition to the writer. You can also have mix of reader and writer aurora instances, i.e., provisioned writer and Aurora Serverless v2 readers or vice versa. Each Aurora Serverless v2 writer and reader can scale between the minimum and maximum capacity values. Thus, the total capacity of your Aurora Serverless v2 cluster depends on both the capacity range that you defined for your DB cluster and the number of writers and readers in the cluster. The capacity is defined at Aurora Capacity Unit (ACU), where each ACU is approximately 2 gibibytes (GiB) of memory, corresponding CPU, and networking. You can scale from 0.5 ACU to 128 ACUs in the increment of 0.5 ACU units.
For details, refer: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.how-it-works.html
Size your minimum and maximum requirements.
Although it is highly benefitted to consider the permissible minimum ACU (0.5) as the minimum capacity, it will have challenges in terms of scaling the capacity. Kindly go through this AWS documentation on guidelines for selecting minimum and maximum ACUs. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html#aurora-serverless-v2.min_capacity_considerations
Monitor Your Aurora Serverless
AWS takes care of scaling of the Aurora capacity behind the hoods and always ensure the capacity demands are satisfied. It is imperative to understand the capacity scales to relook the judgment of serverless or provisioned Aurora cluster and make conversion if necessary.
You can view your Aurora Serverless v2 DB instances in CloudWatch to monitor the capacity consumed by each DB instance with the ServerlessDatabaseCapacity and ACUUtilization metrics.
As the price of AWS Aurora Serverless is higher than the provisioned capacity, it is essential re-validate the serverless option by those metrics.
How to migrate between provisioned and serverless Aurora
You can migrate a provisioned aurora cluster to Serverless and vice versa by introducing a “Serverless” or “provisioned” Replica on to the existing cluster, promote the replica as “writer” instance through failover process. Using this simple, transparent and easy way, you can convert your existing provisioned cluster to serverless cluster and vice versa.
Pricing of Serverless Cluster
Aurora Serverless measures database capacity in Aurora Capacity Units (ACUs) and billed per second. $0.18 per ACU Hour is the price for Serverless V2 in “Mumbai” region. Suppose if I run average 8 ACU (i.e., 16GB Memory) for one month (730 Hrs.), the AWS bill will be 730 * .18(ACU Hour) * 8(Avg ACU), which is $1051.2.
The provisioned Aurora cluster with the memory capacity of 16 GB (db.r6g.large) on-demand is priced at $189.80. With this simple calculation, it reflects that Aurora pricing is almost 5 times higher than provisioned cluster.
The above price comparison is not the real way to calculate the TCO of running a serverless Aurora cluster, as the cluster is assumed to be used in a situation that dial down to minimum of 0.5 (i.e. 1 GB) ACU , which can bring down the cost eventually. The above pricing calculation is just the price of AWS DB instance , there are other cost factor also to be consider such as monitoring and management etc.
Conclusion
Select the best suitable Amazon Aurora capacity model for your database based on the use cases. It is evident that the feature of Aurora serverless (v2) is a good fit for spiky and many specific use cases however the cost of serverless is high, hence leverage the capability as appropriate.
Top comments (1)
Hi,
I couldn't agree more on 6th point. when dynamic capacity needs through out the day how serverless is not suitable one or how provisioned DB is suitable ?