AWS Lambda is a serverless compute service for running self-contained applications written in supported languages. Serverless computing allows users to run code without managing the underlying infrastructure, such as provisioning the right number of servers, and setting up the associated auto-scaling.
The key advantages of AWS serverless architectures, apart from no need to manage their infrastructures, are:
- Pay-as-you-go pricing model – without serverless services, you need to provision the correct number of servers leading to overprovisioning and users paying for unused space or idle CPU.
- Auto-scaling included in the service – the serverless services scale up to the demand automatically – no need to worry about any auto-scaling policies.
- Fault-tolerance built into the service – AWS Lambdas are available across multiple Availability Zones (AZs) in each AWS Region allowing for resilience for data center failures, and maintenance windows.
- Simpler Code – the serverless code are usually simple single-purpose functions that are easier to develop and maintain than non-serverless code.
AWS launches your code in response to some underlying events, such as a change of state of an AWS resource, or an application level event such as a user registering to your web app or an incoming call from AWS API Gateway. The code can also be launched manually.
Internally, each Lambda function is run in its own container.
Key Features of AWS Lambda
- AWS Lambda functions are stateless, meaning that they themselves do not keep any persistent storage. For persistent storage, use AWS S3 or AWS EFS or AWS DynamoDB / RDS.
- For each Lambda function, you can choose the amount of RAM memory and the amount of temp disk storage, and AWS Lambda service then does proportionally allocate the CPU and network bandwidth.
- AWS Lambda supports these languages Java, C#, Go, Python, Ruby, PowerShell, Node.js.
- AWS Lambda allows adding custom logic to other AWS services, such as S3 buckets, and the custom code is launched as a response to the underlying AWS service’s events.
- AWS can run your code in AWS locations on Edge to allow lower latency.
- For complex tasks, the best practice is to orchestrate multiple Lambda functions within AWS Step Functions which do not have the 15 minutes time limit.
Key Limitations of AWS Lambda
- When a Lambda function is launched for the first time or has not been used for the last 15 minutes, there may be a small amount of latency called “the cold start” which may be as high as 10 secs. There are workarounds for this problem.
- The maximum execution timeout for a function is 15 minutes. For code requiring more time than 15 minutes, use AWS App Runner or other services.
- The AWS Lambda does not support GPU so it has limited use for Machine Learning / AI. Nevertheless, there is the AWS SageMaker Serverless Inference serverless service more suitable for that use case.
- Further limitations can be found at Lambda quotas – AWS Lambda (amazon.com).
- If the load of a particular Lambda function significantly grows, it may be cost efficient to move it to an EC2 instance.
Ideal Use Cases
Self-contained tasks running only for a limited amount of time, such as:
- Backend code for Scalable APIs
- Event-based processing, such as responding to AWS resources’ events; e.g. run your code each time an item in DynamoDB is updated