How AWS Lambda Triggers with different Invocation Types
In this article, we are going to see how triggered our Lambda functions, that means we will see AWS Lambda Invocation Types.
After that we will map these Lambda Invocation Types when developing real-world Serverless applications. So AWS Lambda Invocation Types will be our Serverless Journey when developing our Serverless applications.
I have just published a new course — AWS Lambda & Serverless — Developer Guide with Hands-on Labs.
AWS Lambda Invocation Types
AWS Lambda functions is using everywhere for various use cases. Sometimes we want to invoke Lambda functions over HTTP and other times trigger a function based on different events. It is extremely useful to understand the different ways that we can invoke Lambda functions.
Here are 3 different ways we can invoke AWS Lambda function:
AWS Lambda has 3 Invocation Types;
- Lambda Synchronous Invocation
- Lambda Asynchronous Invocation
- Lambda Event Source Mapping with Polling Invocation
You can all invocation types in one image.
- Synchronous invocation is trigger by push model and execute immediately and wait response. we can say RequestResponse model.
- Asynchronous invocation is trigger by event model and executes asynchronous don’t wait immediate response.
- Event Source Mapping invocation is triggered by poll-based. That means lambda function receives multiple items.
Lets see one by one and explain these invocation types.
AWS Lambda Synchronous Invocation
This is one of the simple lambda invocation model. In this communication type, lambda functions execute immediately when you perform the Lambda Invoke by API call.
So when we perform a Lambda invoke an API call, we wait for the function to process the function and return back to response. The response data includes the function response and additional data which can be retrieved from DynamoDB or some other resources.
A common scenario for synchronous invocation is the API Gateway + Lambda integration:
You can see in the image of API Gateway — Lambda — DynamoDB that we can perform CRUD operations for a particular DynamoDB table with exposing APIs from API Gateway.
The important thing; The Invocation-type flag should be “RequestResponse”. This instructs AWS to execute our Lambda function and wait for the response of function to complete.
When we perform a synchronous invocation, we are responsible for inspecting the response and determining if there was an error like time out exceptions and decide to retry the invocation.
We can perform Synchronous RequestResponse invocation using the AWS CLI, SDKs and many other options.
Example of synchronous invocation using the AWS CLI:
aws lambda invoke — function-name MyLambdaFunction — invocation-type RequestResponse — payload ‘{ “key”: “value” }’As you can see that when we specify the Invocation-type flag is RequestResponse. That means AWS execute our function and wait for the function to complete. The important part is we are responsible for checking the response and determining whether it is an error and we should retry the invoke.
There are many AWS services that can trigger lambda function synchronously.
Here are some of them:
- ELB (Application Load Balancer)
- Amazon Cognito
- Amazon Lex
- Amazon Alexa
- Amazon API Gateway
- Amazon CloudFront (Lambda@Edge)
- Amazon Kinesis Data Firehose
AWS Lambda Asynchronous Invocation
In this communication type, Lambda functions works with events and invoke by events and not respond immediately.
Basically we can invoke a lambda function asynchronously, after that Lambda sends the event to a internal queue and returns a success response without any additional information. After that a separate process reads events from the queue and runs our lambda function.
S3 + Lambda + DynamoDB
A common scenario for Asynchronous invocation is the S3 / SNS + Lambda + DynamoDB. You can see in the image of S3 / SNS + Lambda + DynamoDB.
In the diagram, Amazon S3 will call the lambda asynchronous when a new object is written into the bucket. In order to invoke a function asynchronously, we should set the invocation type parameter to Event.
Example of an asynchronous invokes using the CLI:
aws lambda invoke — function-name MyLambdaFunction — invocation-type Event — payload ‘{ “key”: “value” }’When we specify the Invocation-type parameter value as Event if the function failed AWS will automatically retry the invoke twice.
By default AWS Lambda sets a retry policy for asynchronous invocation, your function will be invoked twice if there is an error.
In order to avoid event losses when using asynchronous lambda, always attach a dead-letter queue on the function in order to save events that weren’t successfully processed.
Here is a list of services that invoke Lambda functions asynchronously:
- S3
- EventBridge
- SNS
- SES
- CloudFormation
- CloudWatch Logs
- CloudWatch Events
- CodeCommit
- Pool Based Invokes
AWS Lambda Event Source Mapping with Polling Invocation
Pool-Based invocation model allows us to integrate with AWS Stream and Queue based services. These services don’t invoke Lambda function directly. Lambda will poll from the AWS SQS or Kinesis streams, retrieve records, and invoke functions.
AWS Lambda Event Source Mapping manages the poller and performs Synchronous invokes of our function.
Data stream or queue are read in batches, the function receives multiple items when execute function. Batch sizes can configure according to service types and after that the event source mapping will send data according to batch size. If the batch size is too large to send in one event, it has to be split up, resulting in events with smaller numbers of items than the batch size.
SQS + Lambda
A common scenario for Event Source Mapping with Polling Invocation is the SQS + Lambda. You can see in the image of SQS + Lambda
In the diagram, Amazon SQS has some queue records, this queue record can be added from other AWS Services like EventBridge, SNS and so on.
After that a lambda function poll events from AWS SQS and receive queue records with Event Source Mapping invocations. Lambda function retrieve queue records according to Batch Size property of polling configurations.
Another common scenario for Event Source Mapping with Polling Invocation is stream based processing. These are Kinesis and DynamoDB Streams that Lambda can poll stream records with Event Source Mapping invocations.
Here is a list of services that invoke Lambda functions as event source mapping:
- Amazon Kinesis
- Amazon DynamoDB
- Amazon Simple Queue Service
As you can see we have we have seen AWS Lambda Invocation Types.
Serverless E-Commerce Microservices with Lambda Invocation Types
If we map these Lambda Invocation Types with our microservices architecture when developing serverless e-commerce application, you can see the diagram below;
So AWS Lambda Invocation Types will be our Serverless Journey when developing our serverless e-commerce application.
AWS Serverless Microservices for Ecommerce Application Architecture
Here, you can find the main overall Serverless Architecture for our application that we will follow these steps and build tihs Serverless E-Commerce Microservices Architecture. This is the big picture of what we are going to develop together for AWS Serverless Event-driven E commerce Microservices application.
We have followed the reference architecture above which is a real-world serverless e-commerce application and it includes;
- REST API and CRUD endpoints with using AWS Lambda, API Gateway
- Data persistence with using AWS DynamoDB
- Decouple microservices with events using AWS EventBridge
- Message Queues for cross-service communication using AWS SQS
- Cloud stack development with IaC using AWS CloudFormation CDK
- Decouple microservices with events using AWS EventBridge
- Message Queues for cross-service communication using AWS SQS
- Cloud stack development with IaC using AWS CloudFormation CDK
Step by Step Design AWS Architectures w/ Course
I have just published a new course — AWS Lambda & Serverless — Developer Guide with Hands-on Labs.
In this course, we will learn almost all the AWS Serverless Services with all aspects. We are going to build serverless applications with using AWS Lambda, Amazon API Gateway, Amazon DynamoDB, Amazon Cognito, Amazon S3, Amazon SNS, Amazon SQS, Amazon EventBridge, AWS Step Functions, DynamoDB and Kinesis Streams. This course will be 100% hands-on, and you will be developing a real-world application with hands-on labs together and step by step.
Source Code
Get the Source Code from Serverless Microservices GitHub — Clone or fork this repository, if you like don’t forget the star. If you find or ask anything you can directly open issue on repository.
