1) AWS administration-related actions (required for non-trivial mgmt.)
2) end-user actions (optional).
AWS throttles and limits everything, so expecting 100,000 requests in 20 seconds on a default AWS account is unreasonable.
The Cloud doesn't mean unlimited capacity.
Also, I haven't seen anybody version control lambda code, even in compliance environments, so something to investigate.
What ? That does not make any sense to me. I know I do and I think many do too.
We have anything that gets deployed to lambda go through a jenkins job. Pulls code from GH and builds/uploads it to lambda. Very few people have the ability to manually edit lambda jobs through AWS. While it isn't a perfect solution, it's worked pretty well for us.
Huh, how is it any different building and deploying to anything else.
I store the code in git, build it in team city, and deploy it to S3 using octopus deploy which updates the lambda to point to the new versioned off zip.
I've built a lot of lambda apps and never used it, pretty much everything I do requires dependencies.
Sure, I used a lambda to turn on/off a build server during particular hours. I wrote it directly into the console.
For actual applications tho, I don't use the console.
Just because the console exists doesn't mean people are flat out not versioning their code.
Edit: my AWS support rep explained it: Without pre-provisioned capacity, it would take 34 minutes to scale our Lambda functions to the peak concurrency we needed. And it would cost several thousand dollars.
Completely insane cost. Also, EFS is ridiculously expensive.
You would need to pre-arrange that with your account manager too.
An ALB is hosted on servers, and when you hog those servers, they would need to migrate to bigger.