AWS Lambda Introduction
Welcome to CloudAffaire and this is Debjeet.
In the last blog post, we have discussed IAM policy elements.
In this blog post, we are going to start with a new AWS service called Lambda.
AWS Lambda Introduction
AWS Lambda is a compute service that lets you run code without provisioning or managing servers. AWS Lambda executes your code only when needed and scales automatically, from a few requests per day to thousands per second. You pay only for the compute time you consume – there is no charge when your code is not running.
You can use AWS Lambda to run your code in response to events, such as changes to data in an Amazon S3 bucket or an Amazon DynamoDB table; to run your code in response to HTTP requests using Amazon API Gateway; or invoke your code using API calls made using AWS SDKs.
AWS Lambda Components:
A script or program that runs in AWS Lambda. Lambda passes invocation events to your function. The function processes an event and returns a response.
Lambda runtimes allow functions in different languages to run in the same base execution environment. You configure your function to use a runtime that matches your programming language. The runtime sits in-between the Lambda service and your function code, relaying invocation events, context information, and responses between the two. You can use runtimes provided by Lambda, or build your own.
Lambda layers are a distribution mechanism for libraries, custom runtimes, and other function dependencies. Layers let you manage your in-development function code independently from the unchanging code and resources that it uses. You can configure your function to use layers that you create, layers provided by AWS, or layers from other AWS customers.
An AWS service, such as Amazon SNS, or a custom service, that triggers your function and executes its logic.
An AWS service, such as DynamoDB tables or Amazon S3 buckets, that your Lambda function calls once it is triggered.
While Lambda automatically monitors your function invocations and reports metrics to CloudWatch, you can annotate your function code with custom logging statements that allow you to analyze the execution flow and performance of your Lambda function to ensure it’s working properly.
A model to define serverless applications. AWS SAM is natively supported by AWS CloudFormation and defines simplified syntax for expressing serverless resources.
AWS Lambda Limits:
AWS Lambda limits the amount of compute and storage resources that you can use to run and store functions. The following limits apply per-region and can be increased.
|Function and layer storage||75 GB|
The following limits apply to function configuration, deployments, and execution. They cannot be changed.
|Function memory allocation||128 MB to 3008 MB, in 64 MB increments.|
|Function timeout||900 seconds (15 minutes)|
|Function environment variables||4 KB|
|Function resource-based policy||20 KB|
|Function layers||5 layers|
|Invocation payload (request and response)||6 MB (synchronous)
256 KB (asynchronous)
|Deployment package size||50 MB (zipped, for direct upload)
250 MB (unzipped, including layers)
3 MB (console editor)
|Test events (console editor)||10|
|/tmp directory storage||512 MB|
Hope you have enjoyed this article. In the next blog post, we will discuss the Lambda function and will create our 1st lambda function.
To get more details on Lambda, please refer below AWS documentation.