Important AWS Lambda Technical Constraints

Lambda is still a relatively new service, and it is evolving quickly. I often talk about serverless development at conferences. It’s been quite fun to review my slides about problems and constraints and have to remove things every few months. Things like start-up times and Payment Card Industry (PCI) data compliance were a serious limitation in 2017, but then got fixed. A common complaint against Lambda was that there was no service-level agreement guarantee for it, but in October 2018, AWS published an SLA for Lambda as well. (It’s currently 99.95%.)

Technical limitations

By the time you read this, the constraints might have changed slightly, but at the time this was written, there were four important technical limitations that you needed to consider when evaluating whether something should run in Lambda:

• No session affinity
• Non-deterministic latency
• Execution time-limited to 15 minutes
• No direct control over processing power

No session affinity

Because the hosting provider controls scaling, you generally don’t get to decide about starting up or shutting down instances. Lambda will decide whether it needs to create new virtual machines to handle requests, as well as when to reuse an old machine and when to drop it. It might send two subsequent requests coming from the same user to the same container or to two different containers.