Understanding basic Lambda concepts

Because Lambda is a serverless, event-driven compute service, it uses a different programming paradigm to traditional web applications. If you’re new to Lambda or serverless development, the following sections describe some key foundational concepts that will help you get started on your learning path. As well as an explanation of each concept, the sections also contain links to tutorials, detailed documentation, and other resources you can use to broaden your understanding on each topic.

On this page, you'll learn about the following:

Lambda functions

In Lambda, functions are the fundamental building blocks you use to create applications. A Lambda function is a piece of code that runs in response to events, such as a user clicking a button on a website or a file being uploaded to an Amazon Simple Storage Service (Amazon S3) bucket. You can think of a function as a kind of self-contained program with the following properties.

When a function runs in response to an event, Lambda runs the function’s handler function. Data about the event that caused the function to run is passed directly to the handler. While the code in a Lambda function can contain more than one method or function, Lambda functions can only have one handler.

To create a Lambda function, you bundle your function code and its dependencies in a deployment package. Lambda supports two types of deployment package, .zip file archives and container images.

To get a better understanding of Lambda functions, we recommend you start by completing the Create your first Lambda function tutorial, if you haven’t done so already. This tutorial provides more detail about the handler function and how to pass data in and out of your function. It also provides an introduction to creating function logs.

Lambda execution environment and runtimes

Lambda functions run inside a secure, isolated execution environment which Lambda manages for you. This execution environment manages the processes and resources that are needed to run your function. When a function is first invoked, Lambda creates a new execution environment for the function to run in. After the function has finished running, Lambda doesn't stop the execution environment right away; if the function is invoked again, Lambda can re-use the existing execution environment.

The Lambda execution environment also contains a runtime, a language-specific environment that relays event information and responses between Lambda and your function. Lambda provides a number of managed runtimes for the most popular programming languages, or you can create your own.

For managed runtimes, Lambda automatically applies security updates and patches to functions using the runtime.

Triggers and event source mappings

Although you can invoke a Lambda function manually using the AWS Command Line Interface (AWS CLI) or by using the Lambda API, it's more usual in a production application for your function to be invoked by another AWS service in response to a particular event. For example, you might want a function to run whenever an item is added to an Amazon DynamoDB table.

To configure a function to run in response to a specific event, you add a trigger. When you create a trigger, other AWS services can invoke your function directly by pushing an event object to Lambda whenever a particular event occurs. A function can have multiple triggers, each of which invokes your function independently.

Some types of stream and queue service, such as Amazon Kinesis or Amazon Simple Queue Service (Amazon SQS), can't directly invoke Lambda using a trigger. For these services, you need to create an event source mapping instead. Event source mappings are a special type of Lambda resource that continuously polls a stream or queue to check for new events. For example, an event source mapping might poll an Amazon SQS queue to check whether new messages have been added. Lambda batches new messages into a single payload until a limit that you configure is reached, and then invokes your function with a single event object containing all the records in the batch.

The easiest way to create a trigger or event source mapping is by using the Lambda console. Although the underlying resources that Lambda creates and the way that your function is invoked are different, the process for creating a trigger or event source mapping in the console uses the same method.

To see an example of a trigger in action, start by carrying out the Using an Amazon S3 trigger to invoke a Lambda function tutorial, or for a general overview of using triggers and instructions on creating a trigger using the Lambda console, see Invoking Lambda with events from other AWS services.

The event object

Lambda is an event-driven compute service. This means that your code runs in response to events generated by external producers. Event data is passed to your function as a JSON-formatted document, which the runtime converts to an object for your code to process. For example, in Python, the runtime converts the JSON document to a Python dictionary or list and passes this to the function as the event input argument.

When the event is generated by another AWS service, the format of the event depends on the service that generates it. For example, an event Amazon S3 includes the name of the bucket that triggered your function and information about objects in that bucket. To learn more about the format of the events generated by different AWS services, refer to the relevant chapters in Invoking Lambda with events from other AWS services.

You can also invoke a Lambda function directly by using the Lambda console, AWS CLI, or one of the AWS Software Development Kits (SDKs). When you invoke a function directly, you determine the format and contents of the JSON event. For example, suppose you have a Lambda function that writes weather data to a database. You might define the following JSON format for your event. As with events generated by other AWS services, the Lambda runtime converts this JSON to an object before passing it to your function's handler.

{
  "Location": "SEA",
  "WeatherData":{
    "TemperaturesF":{
      "MinTempF": 22,
      "MaxTempF": 78
    },
    "PressuresHPa":{
      "MinPressureHPa": 1015,
      "MaxPressureHPa": 1027
    }
  }
}

Because the Lambda runtime converts the event to an object, you can easily assign values in the event to variables without having to deserialize the JSON. The following example code snippets show how to assign the minimum temperature value from the previous example event to a variable MinTemp using the Python and Node.js runtimes. In both cases, the event object is passed to your function's handler function as an argument named event.

MinTemp = event['WeatherData']['TemperaturesF']['MinTempF']

let MinTemp = event.WeatherData.TemperaturesF.MinTempF;

For an example of invoking a Lambda function with a custom event, see Create your first Lambda function.

Lambda permissions

For Lambda, there are two main types of permissions that you need to configure:

The following sections describe both of these permission types and discuss best practices for applying least-privilege permissions.

Permissions for functions to access other AWS resources

Lambda functions often need to access other AWS resources and perform actions on them. For example, a function might read items from a DynamoDB table, store an object in an S3 bucket, or write to an Amazon SQS queue. To give functions the permissions they need to perform these actions, you use an execution role.

A Lambda execution role is a special kind of AWS Identity and Access Management (IAM) role, an identity you create in your account that has specific permissions associated with it defined in a policy.

Every Lambda function must have an execution role, and a single role can be used by more than one function. When a function is invoked, Lambda assumes the function's execution role and is granted permission to take the actions defined in the role's policy.

When you create a function in the Lambda console, Lambda automatically creates an execution role for your function. The role's policy gives your function basic permissions to write log outputs to Amazon CloudWatch Logs. To give your function permission to perform actions on other AWS resources, you need to edit the role to add the extra permissions. The easiest way to add permissions is to use an AWS managed policy. Managed policies are created and administered by AWS and provide permissions for many common use cases. For example, if your function performs CRUD operations on a DynamoDB table, you can add the AmazonDynamoDBFullAccess policy to your role.

Permissions for other users and resources to access your function

To grant other AWS service permission to access your Lambda function, you use a resource-based policy. In IAM, resource-based policies are attached to a resource (in this case, your Lambda function) and define who can access the resource and what actions they are allowed to take.

For another AWS service to invoke your function through a trigger, your function's resource-based policy must grant that service permission to use the lambda:InvokeFunction action. If you create the trigger using the console, Lambda automatically adds this permission for you.

To grant permission to other AWS users to access your function, you can define this in your function's resource-based policy in exactly the same way as for another AWS service or resource. You can also use an identity-based policy that's associated with the user.

Best practices for Lambda permissions

When you set permissions using IAM policies, security best practice is to grant only the permissions required to perform a task. This is known as the principle of least privilege. To get started granting permissions for your function, you might choose to use an AWS managed policy. Managed policies can be the quickest and easiest way to grant permissions to perform a task, but they might also include other permissions you don't need. As you move from early development through test and production, we recommend you reduce permissions to only those needed by defining your own customer-managed policies.

The same principle applies when granting permissions to access your function using a resource-based policy. For example, if you want to give permission to Amazon S3 to invoke your function, best practice is to limit access to individual buckets, or buckets in particular AWS accounts, rather than giving blanket permissions to the S3 service.