AWS Computer: Lambda Overview

AWS Lambda is a very powerful tool that is often lumped in with the generalized serverless label. Instead of trying to sell you on that I'll be talking about what Lambda can and can't do to provide context in whether or not it's the right tool for a situation.

Serverless

The concept of serverless is essentially that you don't have to manage the server that deploys your code. Lambda in particular is also referred to by the standard category of "functions as a service" (FaaS). The runtime itself which powers Lambda is essentially a specialized container runtime. However, Lambda code is more locked down than a traditional container solution. There are various restrictions to filesystem and system call access to prevent those trying to break out and potentially get access to the host system. This does mean that some low level features such as shared memory won't be available should code require it.

Compliance

All of this locking down makes Lambda ideal when working in compliance based environments. AWS handles network access and filtering so no network firewall audit needs to be done. OS updates and system hardening are all taken care of. However, it doesn't mean compliance is totally solved, as the issue of making sure the uploaded code and the account hosting the Lambda are secure as well.

Cost Savings

Lambdas are meant to be fairly short lived and as such are priced using a second based billing system that takes into consideration resource allocations. This makes it very cost efficient when dealing with small work that happens frequently. That said, there are also potential costs with Lambda interacting with other services so it is something to keep in mind.

Memory Allocation

While Lambda has a number of available options the ones that matter for most cases are fairly small. Memory allocation is the most crucial part of resource allocation, which also effects CPU available. As it directly relates to billing, monitoring lambda functions to see how close they are to the allocated memory is crucial to ensuring a cost optimized setup. I find that 512MB is a good starting point if there's uncertainty as to the initial value.

File Storage

While services such as S3 and DynamoDB are available, a Lambda that attempts to do something like working with a git repository will generally require a local file system for access purposes. By default there is 512MB storage in /tmp that is included with the base lambda cost. Up to 10GB can be added for an additional cost. It's also possible to access EFS if file storage needs to be shared between lambdas.

Networking

Due to AWS having full control over networking Lambda does not have the ability to act as servers standing alone. Another service would have to act for it to handle the listening part such as API Gateway. For access to private VPC resources a Lambda can associate itself to a VPC. Doing so requires the setup of an Elastic Network Interface (ENI) meaning that Lambdas can take slightly longer to bootstrap.

Task Life

Another important factor in the billing calculation is how long a Lambda runs. The timeout in the configuration indicates the max time a Lambda can run before being considered timed out. The current maximum is 15 minutes or 900 seconds. If you're uncertain that a task will take that much time or not you can either:

• Chunk up and use an SQS queue to process
• Keep state somewhere such as S3 or DynamoDB
• Utilize orchestration system such as Step Functions
• Consider an alternative compute service so as ECS or spot instances

Note that the cost of services to keep state may start to outweigh the cost benefits of Lambda so it's a decision which needs to be made carefully.

Code Deployment

There are three main ways that code can be deployed to lambda:

• Direct upload of the code
• ZIP upload (direct or S3 reference)
• Container image (uploaded to ECR)

ZIP upload is the most common option, and code is generally pushed to S3. This avoids dealing with the Lambda service limits around direct code/ZIP uploads. Container images will need to meet specific requirements to work within lambda, so if doing so with a provided container image proves to be too much work an ECS deployment may be a better fit.

Lambda Layers

In a standard deployment, dependencies for the underlying lambda code are bundled with the code itself. If different lambda functions share the same dependencies this can make code upload size have a noticeable size increase. Lambda Layers lets you keep these dependencies as a separate upload that Lambdas can pull in to utilize. One thing to note is that popular Lambda runtimes such as Python have their respective AWS SDK available as part of the runtime so it doesn't need to be included as a dependency bundle.

Event Handling

Lambda can be used by a number of service as an event mapping source. The ability to act as an SQS worker alone makes it very powerful. Integration with API Gateway allows for the creation of simple REST APIs easily. Step Functions can be used to orchestrate workflows using groups of Lambdas.

Conclusion

I hope this gives insight into the possibilities of Lambda. Their cost effective nature and minimal deployment needs can help with basic automation and simple REST API tasks. Even so time and resource limitations means there will be tasks best suited for another service.