Review: Amazon Aurora Serverless - A cloud-native and production-ready relational database?

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.

AWS announced the 2nd generation of Aurora Serverless in April 2022. Check out: Review: Aurora Serverless v2.

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.

Do you prefer listening to a podcast episode over reading a blog post? Here you go!

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.
• 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.

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.

This brings us to a big limitation of Aurora Serverless: AWS does not guarantee an SLA for Aurora Serverless. The Aurora SLA applies to clusters with database instances running in at least two availability zones only, a requirement that Aurora Serverless does not fulfill.

Secure by default

We often complain about clumsy security defaults, see EC2 Instance Connect is an insecure default!, for example.

But Aurora Serverless deserves special praise at this point as it is introducing two crucial security defaults for your database:

1. There is no way to configure a public IP address for Aurora Serverless. So there is no way an attacker can access your database from the Internet.
2. Aurora Serverless enforces encryption-at-rest based with KMS.

This mitigates security risks caused by suboptimal configuration.

RESTful API for SQL: Data API

It has always been a challenge to manage database connections when building Serverless applications even though the problems with the VPC-integration of AWS Lambda has been resolved lately¹.

Luckily, AWS announced the Data API for Aurora Serverless (MySQL-compatible edition only) at the beginning of this year. The Data API allows us to encapsulate SQL statements in RESTful API requests. A perfect fit for Serverless applications which make use of RESTful APIs a lot.

So far, the Data API is only available in the following regions: US East (N. Virginia), US East (Ohio), US West (Oregon), EU (Ireland), and Asia Pacific (Tokyo). Keep in mind that the Data API requires Aurora Serverless, Aurora (Classic) is not supported.

Missing features

Unfortunately, Aurora Serverless still misses some essential features from Aurora (Classic).

Most important, Aurora Serverless does not support replicas. Instead, only a single instance is running at a time. Therefore, Aurora Serverless cannot offer a hot standby (see Single-AZ with multi-AZ failover). Additionally, read requests cannot be distributed among multiple read replicas, one of the critical benefits of Aurora (Classic).

And there are more missing features:

• It is not possible to load/store data from/to S3.
• The point-in-time recovery called Backtrack is not available.
• Does not support multi-master clusters.
• RDS Performance Insights are not available.

And there are more missing features compared to Aurora (Classic). See Limitations of Aurora Serverless for a complete list.

After discussing some missing features, I’d like to close with an evaluation of the service maturity.

Service Maturity Table

The following table summarizes the maturity of the service:

Our maturity score for Amazon Aurora Serverless is 6.6 on a scale from 0 to 10.

Summary

Significant cost savings are possible for unsteady workloads with Aurora Serverless. However, keep in mind that cost may also increase when switching steady workloads from Aurora to Aurora Serverless.

For now, Aurora Serverless does not support replication. Even though the storage layer is distributed over six nodes in three AZs, the compute layer uses only one instance. That’s a bummer. This even means that the Aurora SLA does not apply to Aurora Serverless. Also, Aurora Serverless does not support read replicas which limits the ability to scale.

No question, Aurora Serverless is an exciting service. However, you should weigh the advantages against the described limitations carefully. I’m looking forward to accompanying the further development of Aurora Serverless and am sure that many of the restrictions will soon be a thing of the past.