Jeremy Daly writes about serverless architecture on AWS, covering Lambda, Aurora Serverless, microservice patterns and database connection handling.
Commenters cite it for practical details on Aurora Serverless capacity, connection limits and early performance, and for reusing database connections across Lambda invocations.
It's fairly difficult to find actual details on ACUs and how it all works, the best I found after spending significant time looking was things like:
https://www.jeremydaly.com/aurora-serverless-the-good-the-bad-and-the-scalable/
According to AWS you're paying for chunks of CPU and memory on a per second basis: https://aws.amazon.com/rds/aurora/faqs/
It's hard to imagine that the CPU capacity is measured in anything other than CPU cycles (time slices of physical capacity) — in the same way it's hard to imagine that the memory capacity is measured in anything but bytes. But whatever, I don't care. It's cool, good for them. The point was... you don't think you're paying for reads of records that are cached? I give up, I fail to see how this can really be a good faith discussion.
I don't know how all other serverless database offerings do pricing. What difference does it make? They're all different. As a user, you want it to be based on your usage and to be fairly and reasonably priced while also being easily audited and predictable. Those are the key properties I would care about.
I honestly cannot see how you could be missing the point by this much and still be operating in good faith so I'll for real, for real stop. :-)
Lambda may not be a magic reliability wand, you definitely still need to manage downstream pressure.
That said:
> The code creates a MySQL connection during each invocation.
This is not a correct implementation for Lambda.
You shouldn't recreate a connection on every invocation. Instead, create your connection outside of your handler code. Then each invocation of a warm container will re-use the same handler. (1)
This will help cut down on cold start time, as well as help manage running out of connections.
You should limit your maximum number of concurrent invocations to be equal to the limit of your database threadpool. This is all in their documentation, as well as several blog posts. (2, 3, 4)
[1] https://docs.aws.amazon.com/lambda/latest/dg/services-rds-tutorial.html
[2] https://www.jeremydaly.com/reuse-database-connections-aws-lambda/
[3] https://medium.com/faun/reusing-connections-lambda-functions-poc-1eb8068fd1db
It’s interesting that lambda still requires a nosql db for good perf. The example they link to from this article uses dynamodb. Not a great choice for a general purpose web app, where sql would be a better choice for many use cases.
https://github.com/serverless/components/tree/master/templates/8-fullstack-application
It’s cool that aws has the data api for lambda to connect to aurora serverless. But then you’re stuck with MySQL instead of postgres, and also stuck with ~100ms db access times.
https://www.jeremydaly.com/aurora-serverless-data-api-a-first-look/
It has a hard limit on max_connections based on the "Aurora Capacity Unit", e.g. for 16 ACU's max_connections it is 2,000. We see spikes of 10x to 100x concurrent users in a matter of minutes (think hug of death style). And although our queries run fast and we see limited increase of CPU on the cluster we almost instantly hit the connection limit.
https://www.jeremydaly.com/aurora-serverless-the-good-the-bad-and-the-scalable/
Declare your connection outside of your handler function - this post is from 2017 but it shows it clearly:
https://www.jeremydaly.com/reuse-database-connections-aws-lambda/
It will get re-used across lambda invocations as long as the instance of it isn't killed which typically happens after a few minutes
If you're into serverless stuff and you like this personal feel, you might like Jeremy Daly's Off by None: https://www.jeremydaly.com/newsletter-issue-35/ .. I think it takes that chatty newsletter approach quite far.