Wow, there's so much misinformation and outright lies in the comments here. You do not have to "notify" anyone at AWS to scale your lambda up to whatever your

Wow, there's so much misinformation and outright lies in the comments here. You do not have to "notify" anyone at AWS to scale your lambda up to whatever your account invocation limits or spending limit. Also you can run whatever code you want, native libraries, etc. If you need a cache you can use the disk or connect to some in-memory data store. You can log to wheverer you like, or throw your logs away. Local development is easy and there are several frameworks that abstract away AWS' wart-like configuration API. The limitations with lambda mostly have to do with the fact you're basically doing distributed processing with finite resources, and under an ephemeral model. Many libraries aren't written in that way, so you'll need to do some first principles work here and there but I'd argue the resultant architecture, independent of AWS, is worth it. You can share databases, S3 files, whatever. Generally speaking lambda is good for workloads that aren't always at 100% (basically almost every kind of long-tail application in computing). The cost per CPU cycle is made up when you consider this, and there's nothing to stop people from setting up lamda-style processing on their own clusters, machines, or bare metal if you think you can optimize for utilization better/cheaper than lambda/AWS. If you're in the 1 or 2% of applications where your system is latency sensitive or always at 100%, you either need to consider other architectures or ways of solving your problem. If that's not possible, lambda might not be for you. If you're someone that doesn't like new technology and is resistant to change, by all means continue to spend your time provisioning and tending to your flock of instances. You're just going to pass that cost on to your customer or user anyway.