Amazon discontinues Aurora scale-to-zero database in favor of always-billed replacement

Amazon discontinues Aurora scale-to-zero database in favor of always-billed replacement

Amazon Web Services will discontinue the Aurora Serverless version 1 database manager. Customers will need to migrate to Aurora Serverless 2, which, unlike its predecessor, does not scale to zero.

According to a discussion on Reddit, customers received an email late last year stating that “as of December 31, 2024, Amazon Aurora will no longer support Serverless version 1 (v1).” We took a quick look and Serverless version 1 no longer shows up as an option in the RDS (Relational Database Service) management console, and there is no Getting Started link on the product page – despite features being added to Aurora Serverless 1 as recently as May 2023, when PostgreSQL 13 support was introduced.

Aurora Serverless was first available in August 2018 with the promise that “you no longer have to provision or manage database capacity … you pay by the second, and only when the database is in use.”

This last feature, paying only when the database is in use, does not apply to Aurora Serverless 2, made generally available in April 2022. 

AWS bills for Aurora Serverless in units called ACUs (Aurora Capacity Units.) Each ACU is around 2GB of memory with what the docs describe as “corresponding CPU and networking.” In Aurora Serverless version 1, “when your Aurora Serverless v1 DB cluster has no active connections, it can scale down to zero capacity (0 ACUs).” There is still a charge for database storage, from around $0.10 per GB/Month. Aurora Serverless version 2 though has a minimum of 0.5 ACUs at all times. An ACU is around $0.12 per hour, so it works out that a mostly idle Aurora Serverless 2 instance will cost around $45 monthly.

Although a small amount in enterprise terms, it makes a big difference to the use cases for the service. The AWS product page for Serverless 2 focuses on it supporting the “full breadth of Aurora features,” as well as scalability and availability, and lists use cases such as variable workloads, unpredictable workloads, and enterprise database fleet management.

By contrast, for Serverless 1 the use cases are infrequently used applications, development and test databases – for which Serverless 2 is no longer so well suited. Although developer instances were likely not profitable, they often lead to production instances so losing this feature may be short-sighted on the part of AWS.

Users on Reddit were quick to observe that a service that is always on is no longer serverless. “These new crop of ‘serverless’ offerings (Aurora v2, Elasticache, Opensearch) should never have been called serverless. AWS should have created a new name that’s in between managed and serverless. I blame the marketing department,” said one.

It is also now less obvious why customers should choose Aurora Serverless at all. The trade-off with serverless compute is that it is more expensive than permanently provisioned compute, but saves money and resources when not in use. Even regular Aurora has auto-scaling for read replicas, another user said, adding that “the number of AWS customers who have a need for auto-scaling write instances (which is the only thing Aurora Serverless V2 is good for) must be small.”

Some customers use many instances of Aurora Serverless 1, each for a different application, precisely because of its cost-effectiveness. The costs for running many instances will now be much higher.

Thanks to Renato Losio for spotting this issue on InfoQ.