How to trigger AWS Lambda from SQS, API GW or S3? With code examples.

In the last article, we went through the concept of Lambda Triggers and Destinations. You can find this article here. As I promised, this is the second part of that article, we will dive into the technical part of triggering Lambda with SQS, API Gateway and S3 notifications.

At the end of this article, you’ll find a GitHub link that you can clone and run the same processes I will describe in this article. Shall we begin?

SQS:

As we all know, SQS is a queueing system that AWS offers and it’s highly available and resilient.

How does it work with Lambda? Is it useful? Please check the following draw.

As you can see, this is what is happening when you trigger Lambda by SQS. This draw was generated by X-Ray service. Btw, I highly recommend you guys to check it out.

What happened?

I as a client inserted a new message into the queue. Queue sends this message to Lambda because I configured that this queue destination is associated with a Lambda. Of course, it depends on SQS configs that when it sends it, but the point is that the message arrived in Lambda. Also, the client in this draw means any service that can send messages to the queue.

I love giving examples and this is what I’m going to do now.

Imagine you have a cool website that sells mugs. I launched a new collection for Star Wars fans. You faced an issue that your Lambda concurrent reached the max and most of the functions got affected. How to solve this issue? SQS!!.

Let’s dream and said you have 13k orders each hour. You need to process them asap but you don’t have the needed resources. Your lambdas are under pressure and ProceessOrder function is exhausting most of the computing power. Simply, limit the concurrent requests to a comfortable limit and use SQS to ingest these requests. If something went wrong, don’t worry because it has a retry mechanism that will try a few times if your computing unit is unreachable at that specific moment.

How to test it?

1- Open the console, and click on SQS.

2- Select the queue you want to test, click on Queue Actions, Send a message.

3- Enter the message, in JSON format.

4- Done! Function got triggered.

4- To validate that the message has been sent, click on monitoring.

5- To check if the function worked, you can check Lambda CloudWatch.

API Gateway:

API calls are the most favorite way, at least for me, to trigger Lambda. It has different ways like PUT, GET or POST. All of these APIs methods can trigger Lambda. Let’s see the draw, shall we?

Lambda gets triggered when a client, which could be an application, triggers an API endpoint. API Gateway passes the data that is received and transform it from either the body and link parameters to a JSON. As you probably know at this stage, it gets passed to lambda, and specifically, to event variable.

You have a mobile application, and this mobile has the functionality to subscribe this caller to a newsletter group. The user entered his email and clicked on the subscribe button. The client which is the mobile application will send this parameter to a defined endpoint (API Gateway link), and Lambda will receive this email within the event variable to store it at a defined location. Lambda will return success status and this status will be passed to API Gateway to return it to the application. Simple right?

How to test it?

You have two ways for that, the short way and the long way. Let’s test in the short way.

1- Open lambda console, and select the function.

2- Click on API Gateway in the designer section.

3- Copy the link and paste it in a new tab. Done!

4- To validate the function got triggered, check the monitoring part in lambda.

S3:

S3 is a fancy storage service that can amaze you with what it can do. Let’s do the same and show you what X-Ray saw from this type of invocation.

It is the same as SQS correct? Yes and no. Yes, it is because we exposed Lambda to X-Ray and no. After all, the client in this situation is S3.

Why do we need this invocation way and why it’s important?

Imagine with me that your application is storing users’ media. You want to store files that they’re bigger than 10mb, which is btw the API GW Payload limit. How are you going to take it from the user to transfer it into your S3 bucket? S3!!

You want to upload user transactions in March. The file size is 55mb. You will ask S3 for a pre-signed link that is pointed to a specific location in your S3. There is an email of confirmation that is needed to be sent whenever this file is stored in S3. S3 will send a notification to Lambda with the file information. Lambda will receive these data appended to event variable and boom, the job is done.

How to test it?

Well, this is an exiting way to execute Lambda, let me tell you why.

In this current scenario, we’re telling S3 to have the power to call Lambda. Lambda itself is not aware of what is calling it, it only has the permission to listen to S3 orders. Do you want to know how to verify that S3 actually will call the function? Let’s trigger it first.

1- Open S3 console.

2- Navigate to the bucket you want. Drag and drop the file you want.

3- Just wait till the file gets uploaded. Done.

4- To validate the function got triggered, check Lambda CloudWatch.

5- To check that the triggers are set, open the bucket, click on properties, and navigate to the bottom, click on Events.

Code:

As I promised in the title, there will be code examples. It is an AWS SAM template that has a configuration for three lambdas and configuration of these three mentioned services. You can download, clone or fork this repo. Use it as an example to start or if you have other scenarios to build above it, its all yours.

Repo link:

https://github.com/imohd23/LambdaTriggers-Article

Summary:

Lambda is one of the greatest services you can use in AWS. It has this rich ecosystem that has a lot of integrations that make working with is something really fun. You can trigger it based on your use-case. But, can it be triggred via SMS?…