If there is another request "in the queue", a lambda that is done with a request will just pick that one up instead of closing down and letting a new lambda spi

If there is another request "in the queue", a lambda that is done with a request will just pick that one up instead of closing down and letting a new lambda spin up to deal with the next request. So as soon as you have enough traffic that you have $CONCURRENCY_LIMIT amount of lambdas running (otherwise you would never build up a queue of course), the execution model of lambdas approximates fastCGI much more than regular CGI. Personally I think the enthusiasm for lambdas stems from several things: - A (legitimate) interest in outsourcing non-essential things like server maintenance to somewhere else with more ops experience. This frees up the devs to work on business logic instead of worrying about backups and log rotations. - Some people are REALLY enthusiastic about the whole scale-down-to-zero thing. I personally think that that is somewhat shortsighted, since that means trading (expensive!) engineering time to save a few 100 USD per month on your AWS bill. Sometimes it is definitely worth it to cut costs, but usually it's engineers overoptimizing the one aspect of profit they have significant influence over (ie hosting costs). - Some people are very enthusiastic about how you can instantly get to "web scale" with lambdas by just putting a very large max concurrency number. That is somewhat true, but massive overkill for the vast majority of companies. It's "engineer it like Google" syndrome but with Amazon instead.