It's typically fine - AWS bills by GB/s (in ms), not by number of functions in an account.

There are limits to the number of functions per account, and number of resources per CloudFormation stack (etc); but within those parameters it's usually a good idea to use one function for a specific controller or action. This allows you to limit IAM permissions, configure memory/CPU, and define associated resources at a per-controller level.

You will definitely run into more cold starts though, if that is a consideration for your project

A serverless function that never cold-starts is just a container.

That doesn’t mean that more cold starts aren’t bad.

Sure but if you can’t tolerate the added latency of a cold start, serverless might not be right for you.

Conversely, if you’re doing something like processing message queues and you don’t care about latency at all, serverless is perfect.

I'm guessing it also helps keep deploys small (atomic?) when a controller method changes. The unmodified lambdas stay untouched.

this makes logging much more difficult to search through

maybe this will eventually have an algorithm for deciding when to deploy separately and when not to, based on cost, performance, etc.

I've built some nice small frameworks for projects on both CloudFlare Workers and GCP Functions that do exactly this. They are so simple to build that I can't imagine needing to even open source them... but maybe should write up a blog post on the details at some point. So many people seem to miss this detail for some reason.

The main benefit is that it sure is a lot easier/faster to deploy one function than one for each route (CI/CD goes so much faster). As well as the cold starts.

Nothing prevents you from routing everything to a single function, no need to even split by controller.

The disadvantage of having a huge number of Lambdas is the ratio of cold starts. The advantage is that you can granularly tweak resource utilization on a per-operation basis.

> granularly tweak resource utilization on a per-operation basis

This is a really good point. Either I took a thorny path learning Lambda or they don't make it terribly obvious that when you pre-allocate larger amounts of RAM (thus more $$$ in GB/s cost) you also gain substantially better CPU performance.

So when you have a compute intensive task with a low memory footprint and want to improve latency, you may actually want to allocate lots of unused RAM.

I don’t know how this works. But I’m curious:

Wouldn’t it be more cost effective to have one big address space than a lot of fine tuned ones? Even if you’re stateless, you could benefit from the fact that utilization spikes can be handled with less overall redundancy. Assuming the dollar cost is proportional per allocation.

provisioned concurrency pretty much nukes the concern.

This is not as trivial as you make it sound. You would need to know the amount of functions you want to have provisioned at all times, if you need more, cold starts will occur. In addition this creates base costs, which would not exist otherwise.

I would argue that if you needed n number of functions, where n is unknown, or n cannot be set to a reasonable number that can handle traffic, and cold starts are unacceptable, you would be using the wrong bit of infrastructure.

I agree. Usually it is a a trade-off between cold starts and the costs of `n` warm functions.