The Aurora Serverless Road Not Taken
Two Auroras Serverless diverged in a prod account,
And sorry I could not deploy to both.
And being one developer, long I stood
And looked into v2 as far as I could
To where it scaled beyond my budget.
Then looked at the first, just as arcane,
And having perhaps the better model,
Because it scaled to zero and had a data API;
Though it did not support multiple regions
And scaling up dropped connections unto the ground.
I shall be telling this with a sigh
On-call pages and pages hence:
Two Auroras Serverless diverged in a prod account, and I—
I took the one newly launched,
And now production is both expensive and broken.
The broken promises of Aurora Serverless v2
The woeful tale of AWS’s diverging Aurora Serverless offerings began when Amazon Aurora Serverless v1, was announced at re:Invent 2017. V1 has some problems that are a bit gnarly and, frankly, make it tough to justify trusting it with production. So I was on board when Aurora Serverless v2 was announced at re:Invent 2020. It became generally available after a year-and-a-half period of public preview and purports to solve all of the problems with v1. But each word of “Aurora Serverless v2” is a lie.
“Aurora” is AWS’s custom database engine that’s named after a fairy-tale princess. Unlike every Disney movie you ever watched as a kid, AWS’s relational database services fall short of the implicit promise for a happy ending assured to heroines, from Ariel to Jasmine to EVE.
“Serverless” gets the bulk of my irritation here. Unlike its predecessor, Aurora Serverless v2 actually offers multi-region capabilities. But it violates other implicit promises of serverless — most abhorrently, that it doesn’t scale to zero.
“V2” is the final betrayal. The second version of an AWS service is supposed to be notably better across the board and able to entirely supplant the v1. As it stands now, Aurora Serverless v2 is nowhere near that point.
An expensive scaledown
The implicit promise of serverless is “you pay per request, and when it’s not in use, it scales to zero.”
Yes, you pay for data storage, but that’s always been the case. Aurora Serverless v1 understood this; it scaled down to nothing and would stop charging you. The first request would “wake the system up,” albeit at a potential latency cost of up to a minute. OK, not great, but surely v2 can fix this!
Well, it did, but in the worst possible way. Buried in the documentation, AWS states that “Currently, Aurora Serverless v2 writers and readers don’t scale all the way down to zero ACUs.” As a result, the lowest you’ll pay a month for one of these things is the princely sum of just shy of $45.
Explain to me again why, for light workloads, you wouldn’t just run your database engine of choice on a less-expensive RDS instance or even on top of EC2? I really hope that this gets fixed between the time I write this and the time I publish it, because calling Aurora Serverless v2 “serverless” is going to get folks sideways about what the term means. Sadly, there’s a strong argument that it’s already a lost cause.
A broken system for database management
One of the reasons to have a serverless database is that AWS handles all of the scaling problems attendant to serverless applications. It could be sitting there idle, then 5,000 Lambda functions spin up and basically pummel a database to death.
Aurora Serverless v1 handled this super well by introducing a Data API that Lambdas can hit without knocking the underlying service over with a flood of new connection requests all at once. For some workloads, this is awesome!
The Aurora Serverless v2 eschewed using it entirely, instead opting to use Amazon RDS Proxy. This thing’s minimum charge is another 12¢ an hour on top of the underlying Aurora Serverless v2 databases — while still forcing you to manage the database connection pooling yourself, lest your Lambdas once again hug the thing to death.
AWS, untangle Aurora’s thorny paths
The confusing thing to me is that Aurora Serverless v2 was in preview from December 2020 to April 2022. AWS had ample time to take a solid whack at a v2 that truly fixed the problems with the first version, then let it become functionally deprecated.
Instead, we’re staring down two diverging roads for Aurora Serverless. AWS now has a v1 and a v2 of the same service, each offering different capabilities and trade-offs. They amount to two different services that are sold under the same name. Customers are going to be confused. Hell, I’m confused! I have to hope and trust that this is a temporary situation that will rapidly improve — but today, I’m unconvinced.