[soamv]

Lambda has always been the most expensive compute you can buy on AWS -- you could think of that as the premium for being the most "elastic". So this feature is about giving away some of that elasticity for (a) performance predictability and (b) a bit of total cost savings. Note that you can still happily "burst" into exactly as much concurrency as you could before, you'll just have cold starts.

People used to write cron jobs to keep their functions warm, which besides being ugly didn't even work well -- you could at best keep one instance warm with infrequent pinging, i.e. a provisioned concurrency of 1. So this feature addresses that use case in a much more systematic way.

There's some precedent for features like this -- provisioned IOPS and reserved instances come to mind. In both those cases you tradeoff elasticity and get some predictability in return (performance in one case, cost in another).

[WatchDog]

I doubt there are that many people that want a provisioned concurrency of greater than one.

If you have a reliable base-load of a few requests a second and you don't have some constraint that forces you to use lambda, you are going to get much better value running your application on ecs/ec2.