It was never easier to scale your compute layer. EC2 Auto Scaling, Fargate, and Lambda enable horizontal scaling. But how do you scale your database? Use a NoSQL database like DynamoDB, one could say. But what if you don’t want to miss all the advantages of an SQL database? You should check out Amazon Aurora Serverless, a cloud-native SQL database.

The MySQL-compatible edition is generally available since August 2018. Recently, AWS announced a PostgreSQL-compatible edition as well. It’s high time to put the service through its paces.

Would you rather hear than read? We have published a podcast episode about this blog post.

Introducing Amazon Aurora Serverless

As shown in the following figure, an Aurora Serverless database cluster consists of two layers:

The storage layer replicates the data among multiple availability zones by default. On top of that, the storage capacity scales from 10 GiB to 64 TiB. Also, the I/O throughput of the storage layer scales nearly endlessly.

replicates the data among multiple availability zones by default. On top of that, the storage capacity scales from 10 GiB to 64 TiB. Also, the I/O throughput of the storage layer scales nearly endlessly. The compute layer scales vertically from 1 ACU (approximately 1 vCPU and 2 GiB memory) to 256 ACU (approximately 64 vCPU and 488 GiB memory) and adapts to the current workload automatically. It is even possible to pause the whole compute layer.

The scalable compute layer is a game-changer for unpredictable workloads or scenarios where there are no queries to the database for significant timespans.

Want to learn more about the storage layer? Werner Vogel explains the design of Amazon Aurora. For more information about Aurora Serverless, I do recommend the re:Invent session Aurora Serverless: Scalable, Cost-Effective Application Deployment (DAT336).

Pausing the database

Obviously, the best way to reduce costs in a pay-per-use pricing model is to tear down unused resources. Aurora Serverless supports to pause the compute layer when there are no database queries for five minutes.

To repeat that in other words: the compute layer of your database scales to 0. You will not pay for the compute layer when paused. Of course, charges apply for the storage layer, which stores your data even when the compute layer is paused.

Establishing a database connection to modify or query data will resume a paused database cluster automatically. There’s only one catch to this: resuming the database adds latency to the first incoming requests. In my experience, it takes approximately 15 seconds to resume a stopped database. Peter measured the activation time more accurately and published the results in his blog post Amazon Aurora Serverless – The Sleeping Beauty.

So there is a trade-off between cost reduction and long latencies for some requests. We are using Aurora Serverless for a web-based accounting solution that is only used by a few people a few times per day. High costs savings justify waiting a few seconds for the database to resume in this scenario. Important note: pausing the database is optional. It is up to you to enable or disable auto-pausing.

Speaking about cost savings, let’s have a look at the pricing for Aurora Serverless.

Pricing

The following table compares the costs for the compute layer between Aurora Serverless and Aurora (with provisioned instances). The calculation does not include storage costs and is based on prices for us-east-1 . Assuming that Aurora Serverless is running 24/7 without scaling the compute layer (ACU) you pay a 50% surcharge on the price for the compute layer compared to using Aurora.

ACU Aurora Serverless Aurora Surcharge 1 $0.06 per hour $0.041 per hour 46.34 % 32 $1.92 per hour $1.160 per hour 65.52 % 256 $15.36 per hour $9.280 per hour 65.52 %

In my opinion, an additional charge of this amount for the service offered is not justified. However, you can still make significant cost savings by using Aurora Serverless.

For example, think about an application that is only used during working days from 9 to 5. Outside office hours, there is no or almost no load on the system. Switching from Aurora to Auora Serverless will result in costs savings of up to 65 % for the compute layer, as shown in the following calculation:

Aurora: 24 hours * 30 days * $0 .041 = $29 .52 per month

Aurora Serverless: 8 hours * 21 days * $0 .060 = $10 .08



So, depending on your workload costs for the compute layer of your database will either increase or decrease significantly.

Single-AZ with multi-AZ failover

Reliability is critical for a database. As mentioned before, the storage layer is distributed among multiple availability zones by default. To be more precise: data is replicated six times among three availability zones. That’s impressive.

However, Aurora Serverless operates in single-AZ with multi-AZ failover mode. The compute layer consists of a single instance. In case of an outage, Aurora Serverless will spin up a new instance in another availability zone. As the storage layer is replicated among multiple availability zones, data is not at risk. But it will take some time until the new instance can serve requests.