As most of us know by now, Serverless computing allows us to build and run applications and services without thinking about servers. Serverless applications don’t require us to provision, scale, and manage any servers.
We can build them for nearly any type of application or backend service, and everything required to run and scale our application with high availability is handled for us.
Building serverless applications means that us developers can focus on our core product instead of worrying about managing and operating servers or runtimes, either in the cloud or on-premises. This reduced overhead lets us reclaim time and energy that can be spent on developing great products which scale and that are reliable.
So far the Serverless realm was mainly confined to code and functions – i.e. charging only for the number of invocations of those functions, zero maintenance of the environment that house those functions and their scaling and high availability.
When it came to database integration with Serverless technology, things have been a little tricky so far..
A typical MySQL database is not really ‘Serverless’ – it doesnt really autoscale and needs to be managed.
It’s usually a provisioned, vertically scaled instance (possibly with a replica in another availability zone) – this creates somewhat of a conflict of philosophies when used in a serverless context
On top of this, running provisioned instances can get costly – after all they have to be ‘on’ all of the time. This leads to minimum monthly costs depending on the the number of hours an instance is running.
Aurora Serverless MySQL..
Aurora configuration now come with a ‘Serverless’ capacity type option (as apposed to provisioned) which allows one to configure a minimum and maximum number of resources for a database cluster.
With the Serverless capacity type (currently available for Aurora MySQL 5.6), the Aurora DB cluster automatically scales database capacity up or down based on your workload.
Aurora Serverless uses ACUs (Aurora Capacity Units) to measure database capacity. Each ACU has approximately 2 GB of memory with corresponding CPU and networking resources that are similar to provisioned instances of Aurora.
Similar to DynamoDB you can set the minimum and maximum capacity for the cluster, which will scale ACUs up if CPU utilization is >70% or >90% of connections are being used – and also scale down based on whether CPU usage <30% and connections used is <40%.
Whereas provisioned Aurora instances utilize ‘per hour’ billing based on instance size, Aurora Serverless, on the other hand, use ACUs (Aurora Capacity Units) to measure database capacity. Each ACU has approximately 2 GB of memory with corresponding CPU and networking resources that are similar to provisioned instances of Aurora.
ACUs are billed by the second at a flat rate of $0.06 per hour. You are billed per second of usage but there is a minimum of 5 minutes billed each time the database is active. (The rest of the time the database is considered paused and is you are not billed for this time – yay! and especially double yay for pet projects )
There is also a minimum provisioning of 2 ACUs (with 4 GB of memory). You can scale all the way up to 256 ACUs with approximately 488 GB of memory.
It’s worth noting that waking up a ‘paused’ serverless database can lead to some initially slow queries but there is an option to switch off this if preferred – obviously this will lead to higher costs though.
Learn more about Aurora Serverless here