These one-sided arguments come up every time there's a Lambda thread. They're useful and easily cheaper almost anywhere you have sparse compute or RAM requirements, even for heavyweight tasks like transcoding. A t3.nano meanwhile can simultaneously be overpriced ($3.50 for an idle task) and a bottleneck (30Mbit/s sustained network) in just as many places as a Lambda could be applied incorrectly.

▲

ryandvm 2 hours ago | parent [-]

They're also good for extremely bursty loads. I use Lambdas extensively for a radar imagery API that delivers the images for an Android live wallpaper that shows weather radar.

That particular use case can go from hardly any traffic at all to a hurricane of traffic during something like, well, a hurricane.

For consistent processing loads, I think I could save money by just running on dedicated EC2 instances, but you cannot beat the instant scale of Lambdas.

Shameless plug: https://play.google.com/store/apps/details?id=app.radarlove....

▲

CharlieDigital an hour ago | parent [-]

There's nothing particularly special about Lambda's scaling. You can do the same with GCP Cloud Run[0] or Azure Container Apps[1]

Specify the maximum number of allowed instances and maximum concurrency per instance. Optionally configure more targeted scale rules. It will scale it from 0 - n as needed.

[0] https://docs.cloud.google.com/run/docs/about-instance-autosc...

[1] https://learn.microsoft.com/en-us/azure/container-apps/scale...

▲

badatnames an hour ago | parent [-]

So long as you don't count >2 orders of magnitude difference in scaleup time as particularly special..

	▲	CharlieDigital an hour ago \| parent [-]
		That's not how it works since each instance can handle multiple requests (up to 1000 per instance). So you may set this to scale at say 75% load level. Indeed if you configured each instance as a single threaded handler, you will not have fun.