AWS Lambda is a serverless compute service that allows us to run code without provisioning or managing servers. It falls under the Function-as-a-Service (FaaS) service model, where the user provides the code, and the underlying infrastructure is managed by the cloud.

Press + to interact

In a serverless architecture, the Lambda function adds business logic and acts as a glue between multiple managed services, charging the user for the execution time.

How Lambda functions work

Each lambda function consists of three essential components:

  • Invocation event: It comprises data, typically in the form of a JSON packet, and its contents vary depending on the service. For instance, API Gateway events provide details such as path, HTTP method, query string parameters, headers, cookies, and more. DynamoDB events may include data related to updated or deleted records, while S3 events contain information like the bucket name and object key.

  • Function handler: A method within your function code processes the incoming event. This handler, a standard function in your chosen programming language, executes tasks and produces a resulting event. The code snippet below shows the default function handler in Python.

Press + to interact
def lambda_handler(event, context):
# Your function logic goes here
return {
'statusCode': 200,
'body': 'Hello from Lambda!'
}

This function receives two arguments: event and context and returns a JSON body with a 200 status code and a message.

  • Context: It is passed to the function handler and carries information about the execution environment, invocation, and function.

The Lambda function is invoked by a trigger, which can be any AWS service or configuration, for example, adding a file to an S3 bucket. The entry point of a Lambda function is a function handler, which contains the code for the task to be executed. After the function is invoked, it launches a container runtime, copies the code, executes it, and returns the result.

Press + to interact
How Lambda works
How Lambda works

Once the handler completes processing the initial event, the runtime sends it additional events in succession. This cycle continues, allowing each instance of your function to handle potentially thousands of requests.

Cold starts in Lambda function

After the Lambda function shuts down, it maintains the execution environment for a non-deterministic time to reuse it if the function is re-invoked. Thus, the next time, the function does not need to start the environment and only executes the code called Warm Start.

If the function is invoked for the first time or after an extended period of time, it needs time to set up the execution environment. This is called the Cold Start and typically lasts from 100 ms to 1 second. We are not charged for the time taken to set up the environment, but it does add a time latency to the overall execution of the Lambda function.

Developers use open-source tools to Warm Up the function to avoid cold starts. The warming up of a function involves a pinging mechanism through scheduled EventBridge rules. However, this is not a reliable method to eliminate cold starts.

Lambda event sources

The core of a serverless architecture is events that seamlessly integrate multiple services together. Lambda event sources are AWS services or resources that trigger the execution of an AWS. There are multiple ways to configure event sources for a Lambda function.

Press + to interact

Direct triggers

Some services, such as S3, DynamoDB, and more, can directly add triggers to a Lambda function. For example, we can add a trigger to invoke a Lambda function when a file is added to the S3 bucket.

Event source mapping

Some services can not directly invoke a Lambda function and thus utilize event source mapping. It creates a Lambda resource that specifically looks for the events and invokes the function as soon as the event occurs.

An event source mapping utilizes permissions within the function’s execution role to read and manage items in the event source. The permissions, event structure, settings, and polling behavior may differ based on the specific event source.

An example use case for event source mapping is in the context of processing records from an Amazon DynamoDB stream with AWS Lambda. Whenever there are changes to the DynamoDB table, for example, new items, updates, or deletions, the DynamoDB stream triggers the Lambda function through the event source mapping.

Function URLs

Another way to invoke a Lambda function is a Function URL, an HTTP(s) endpoint. We can configure the function URL through the AWS management console or AWS CLI, which is a distinct URL associated with the function and remains constant. The typical structure of the function URL is given below:

https://<url-id>.lambda-url.<region>.on.aws

Deployment packages

We have learned that Lambda supports various commonly used runtimes for the functions. However, developers might require some newly released frameworks, runtimes, packages, or libraries that are not provided by Lambda.

To solve this problem, Lambda allows deployment packages to package and deploy a function code along with its dependencies. Additionally, we can build container images of our application and deploy them directly on the Lambda function.

Press + to interact

Lambda supports two types of deployment packages: container images and .zip files. To build a container image for Lambda, you can use the base images provided by AWS itself. These base images come in pre-loaded with runtimes and essential components required to run docker images on Lambda functions.

Layers

Lambda layers allow us to centrally manage and share code, libraries, and dependencies across multiple Lambda functions. Instead of including all dependencies within the deployment package of each function, Lambda layers enable us to package common components separately in a .zip file, making it easier to maintain, update, and reuse code.

Press + to interact
Lambda layers
Lambda layers

When we add a layer to a Lambda function, it copies it's content into the execution environment, which can be used within the function code. A Lambda function can contain up to five layers.

A typical example of effective utilization of Lambda layers is Shared Authentication Middleware. Imagine you have multiple serverless functions within your application that require authentication. Instead of duplicating the authentication code in each function, you can create a Lambda layer containing the shared authentication middleware.

Lambda limits to remember

The Lambda function has certain limitations as compared to other computing services. Given below are some of the important limitations from the exam's point of view. Remembering them can help solve questions and narrow down options.

  • The Lambda function's maximum execution time can be increased to 900 seconds (15 minutes). We would have to switch to other computing options for workloads with execution time of more than 15 minutes.

  • The maximum size of the compressed deployment package for the Lambda function is 50 MB. On the other hand size of uncompressed deployments, including code and dependencies, can exceed to 250 MB.

  • The disk capacity in the function container ranges from 512 MB to 10 GB.

  • By default, Lambda supports 1000 concurrent executions in an account. However, this number can be increased.

  • The maximum size of environment variables of a function is 4 KB.

Get hands-on with 1300+ tech skills courses.