The Problem with AWS Lambda

Is AWS Lambda reliable?

Short answer, yes. Reliability is a key aspect of AWS Lambda and serverless computing.

But what is reliability. According to AWS, reliability means...

"the ability of a workload to perform its intended function correctly and consistently when it’s expected to." - The Reliability Pillar | AWS Well-Defined Architecture

This means Lambdas are available to run whenever they are called. AWS does a great job of achieving high availability through replicating services across "availability zones" in different regions.

AWS is so good at this that they define a service level agreement (SLA) of 99.95%. This means there's only a .01% chance your function won't run when its' invoked.

So while AWS Lambda has it's issues, reliability isn't one of them...

The limits of serverless computing

So what are the limits of serverless computing? If they are extremely reliable then why not run everything as a lambda all the time!

It turns out there are some serious limitations still existing with AWS lambda, including...

Time limits

AWS Lambdas run for up to 15 minutes.

This is great if your retrieving records from a database but awful if your doing batch processing.

Many dev teams have overnight jobs that take hours to move data, parse files, etc making such things bad choices for AWS Lambdas.

Resource limits

AWS Lambda sets default usage limits.

While you can always request quota limit increases, these are some of the default limitations:

1. 1,000 concurrent executions
2. 75GB for code storage (.zip file archivals and versioning)
3. 250 ENI for VPC (for running Lambdas within a virtual private cloud)
4. 10,240 MB memory allocation
5. 4KB for environment variables
6. 6MB for invocation payloads (20 MB if streamed and synchronous, 256 KB if async)
7. 1,024 execution threads

Vendor limits

When you're using AWS Lambda, you're playing AWS's game. While you can always contact support for potential resource quota increases, you are at the mercy of what AWS will let you do.

Limitations will exist with any cloud vendor you choose. Spending more can usually solve problems but it's important to understand the threats of "vendor lock-in".

Runtime limits

Some of these have already been discussed, but remember the following runtime limits:

• 15 minute runtime execution limit
• 1,000 concurrent executions
• 1,024 execution threads
• 10,240 MB memory limit

The security risks of serverless computing

The AWS ecosystem has plenty of tools for emphasizing security.

Execution roles and permissions combined with IAM policies allow you to have fine grained control over who can create, update, and execute Lambdas.

Lambdas only work work over HTTPS so data in transit will be encrypted.

Lambdas allow you to set environment variables for encrypting sensitive information at rest.

If you have a VPC hosted in AWS, Lambdas can be configured to run inside it.

PLEASE NOTE: Just because AWS Lambda does a great job of addressing security risk, it doesn't mean it's completely hands off. It's still important to implement secure coding practices and ensure your code runs on the latest secure supported platform etc. It's also up to you how you implement access control through IAM policies etc.

The performance issues of serverless computing

Performance issues can always occur when considering the runtime and resource limits outlined above. It's important to remember that this is NOT an issue with AWS Lambda itself but rather the implementation choices.

For example, if you try to run something inside a Lambda that takes longer than 15 minutes then you will face performance issues. That doesn't mean AWS Lambda causes poor performance. It means you didn't understand the best ways to leverage the technology.

AWS Lambda doesn't have performance issues. It has performance limitations. It's important to fully understand these limitations when deciding if AWS Lambda is the best choice for what you're trying to do.

What is the biggest disadvantage of AWS Lambda?

It's not performance. It's not reliability. It's cost.

The disadvantage of using serverless computing

Cost is the main disadvantage, but not for reasons you'd think...

Compared to the alternatives (GCP, Azure) AWS is competitive. The real cost of using Lambda is not fully understanding the limitations and ideal use cases for your needs.

Don't let the convenience of serverless allow you to become lazy in understanding the resources it takes to execute what you're trying to do in Lambda.

Remember that AWS can always increase their prices. It is crucial that you understand what you are using Lambda for and if it is the best choice.

What AWS Lambda is NOT good for

1. Batch processing
2. Replacement for needing to understand low level design details and resource needs
3. Shared state
4. Highly predictable workloads - latency overheads during "cold starts" may mean running your process in a continuously running container/server makes more sense

Conclusion

AWS Lambda functions should be used as part of a larger architectural design.

While Lambdas can be very convenient for hosting functionality without a server, they have their resource and runtime limits. It's important to understand these limits when designing your system.

Your thoughts?