When and how to use Amazon Aurora Serverless databases?
When we talk about the managed relational database services inside AWS, currently two primary services support different kinds of workloads, for different use cases. They are Amazon RDS and Redshift.
Within RDS, one of the databases engines supported is Amazon Aurora which was custom built by AWS with high performance and scalability in mind. It currently supports API compatibility with MySQL and PostgreSQL.
The main selling point for Amazon Aurora is that it provides most of the features of traditional commercial databases at a fraction of the cost of those commercial databases along with the ease of use and deployment of the cloud. It provides improved performance and scalability by separating the compute and the storage layers within the database that way they both can be scaled separately.
It currently supports up to 15 replicas per database instance, with the writer and replica database instances sharing the same storage layer. Any of these replicas can be configured to be automatically promoted to become the new primary DB instance, in case the original primary instance happens to go down for some reason.
In addition, Amazon Aurora saves multiple copies of the data across 3 availability zones inside the storage layer for high availability. The storage layers support autoscaling up to 64 TiB. I can go on and on about the features available within Amazon Aurora, but I’ll save that for another article.
The main focus of this article is the Serverless offering inside Amazon Aurora. I think the word ‘Serverless’ is a bit overloaded.
Actual servers are running somewhere within an AWS data centre that are running our databases, just that we don’t have to worry about standing up and managing those servers, unlike provisioned RDS databases where we need to select the database instance class to run our databases on.
So, you might ask, what are the major selling points for Aurora Serverless? Let me spell it out for you:
Now let’s get our hands dirty and let’s stand up an Aurora Serverless database from inside the AWS console.
While creating a new RDS database from inside the AWS console, when we select ‘Amazon Aurora’ as the engine, we can see the ‘Serverless’ option inside the capacity type.
We can select the Maximum and Minimum ACUs between which we want to scale the Aurora Compute Capacity. The maximum ACU that we can get as of this writing is 256 ACUs which equates to 466 GiBs of RAM. As we can see in the below screenshot, it is a multiple of 2 GiB RAM and appropriate CPU units for that amount of RAM. We can also select if we want to scale the compute capacity down to 0 ACUs after a configurable period of inactivity which can be up to 24 hours.
One other setting that I would like to highlight, is the ‘Data API’ setting inside ‘Web Service Data API’. When we enable this setting, then we can interact with the database directly over a Web API endpoint without the need to connect to the database. It also enables running queries directly against the database from inside the AWS console, as we will practically see later.
One thing you will notice during Aurora Serverless database provisioning is that the database creation process is quite fast, it should take only about a minute or two for the actual database creation.
Now let’s try to connect to this newly created database from right inside the AWS RDS console, by clicking on ‘Query Editor’ inside the left menu, putting in the database connection details in the resulting pop-up and then clicking on ‘Connect to Database’.
Once we are successfully authenticated and connected to the database we will be presented with a query editor right inside our browser, where we can type and execute queries directly against our Aurora Serverless databases. We can also get a listing of recently executed and saved queries.
We can also use the AWS CLI and the AWS SDKs in any of the supported programming languages to interact with the Aurora Serverless databases. I think Aurora Serverless would be an ideal candidate backend relational database for Lambda functions.
Now let’s talk about the Aurora Serverless pricing. Aurora Serverless is going to cost us a flat $0.06 per ACU Hour. That should result in quite a bit of cost-saving for us as we do not need to pay for our database compute instances running at all times.
All in all, I can say that Aurora Serverless is a good option when we want to provision a cloud database for supporting sporadic workloads. Databases for supporting developer and testing workflows is an ideal candidate use case. Saving costs on such non-production workloads should be of concern to us. Below are links to AWS documentation related to Aurora Serverless, in case you need more information.
What are you waiting for? Let’s start using Aurora Serverless for our developer and testing workloads and start saving!
Thank you for reading.