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