AWS Architecture Blog

Developing on AWS Lambda (Part 2): Understanding AWS event sources

George Mao
Feb 24 · 3 min read

In Part 1 we talked about the basics of programming with AWS Lambda. Now, lets review the different ways Lambda functions are invoked. There are two broad ways you can invoke Lambda functions. Let’s take a look at them:

  1. Programmatically via the AWS SDK, CLI, or API
  2. Automatically via a built-in AWS event source. There are well over 100 services within the AWS Cloud and most of them can invoke Lambda functions

Programmatically

Lambda functions are invoked through the API Action: Invoke. There are a few required parameters such as FunctionName and InvocationType. You can call this API directly by constructing the correct HTTP POST payload (and provide a valid AWS Sigv4 signature), however, it’s much easier to use the CLI or SDK. Both of these issue calls against the Invoke action. With the CLI, you can do the following:

Notice, we didn’t specify the InvocationType — this is because the CLI defaults to RequestResponse, which is a Synchronous invocation. You can change an invoke to Asynchronous by specifying the value Event.

If you’re building an application and need to invoke a Lambda function, use the AWS SDK for the programming language you’re working with. For example, with NodeJS you can use the Node SDK and call the Invoke method.

The key point to remember about programatic invokes is that you control both the InvocationType AND the payload you want to emit into the Lambda invoke.

Automatically

This is where it gets interesting: AWS services such as API Gateway, S3, SNS, SQS, Kinesis, EventBridge, Cognito, DynamoDB, and even Lambda can automatically emit an event that Invokes a Lambda function.

The payload that each event delivers to Lambda will be different, but they all deliver a well formatted JSON message. Make sure to read this AWS document — it outlines how each service delivers payloads to Lambda.

I highly recommend installing the Serverless Application Model (SAM) and the SAM CLI. It lets you work with Lambda functions locally but also has a very useful feature that generates sample events for most of the services. That command is as follows:

For example, if you wanted to see what kind of payload S3 will deliver to Lambda, you can run this command:

Sample S3 Put event

The last item to be aware of is the InvocationType. Remember, with the Programatic invocation option you specify if you want Sync invokes (RequestResponse) or Async invokes (Event). With AWS event sources, the service triggering your Lambda function controls the InvocationType and you cannot change the type. Reference the AWS docs here to check the service details.

The key point to remember about automatic invokes is that the service that invokes your function controls both the InvocationType AND the payload that is emitted into the Lambda function.

In part 3 we’ll cover a Node example of how to consume an event emitted from an AWS service and pass it to another downstream AWS service.

George Mao

Written by

AWS Serverless Specialist. I’ll post short, high value tips & tricks for all things Serverless. Ping me if you want to talk about anything :)

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade