AWS SNS > SQS > Lambda Trigger. Is this async or sync invocation? - amazon-web-services

I am using
Client > SNS > SQS > Lambda Trigger
As per my understanding, SNS > Lamda will be an asynchronous invocation
However, SNS > SQS > Lambda supposed to be synchronous.
Is my understanding correct?
I have configured DLQ on the SQS source but doesn’t store failed message into DLQ. Also saw 2x retried attempt on Lambda cloudwatch.
If SNS > SQS > Lambda is synchronous, I think this should not happen am I right?

#jellycsc already answered your question in the comment section, but i would like to expand it. Shortly it is poll based which uses synchronous invocation for it.
There are three type of invocation models for AWS Lambda
Synchronous
Elastic Load Balancing
Alexa
Cognito
API Gateway (there is an async version of it too)
Asynchronous
S3
SNS
Cloudwatch/Eventbridge events
Poll-based
Kinesis
SQS
DynamoDB streams
According to the this blogpost
AWS will manage the poller on your behalf and perform Synchronous invokes of your function with this type of integration. The retry behavior for this model is based on data expiration in the data source. For example, Kinesis Data streams store records for 24 hours by default (up to 168 hours).

Related

What is an alternative in AWS for sending message from SNS to SQS FIFO?

I have this situation where I am using Amazon SNS + SQS in order to handle domain events.
Basically on domain event I publish a message to SNS and two SQS queues are subscribed to SNS. Since i noticed SQS supports FIFO, but SNS doesn't support FIFO, I am trying to find a resolution on how to simultaneously deliver message A to multiple SQS FIFO queues?
What I had so far
Publish Message A to SNS
Distribute Message A to SQS 1 and SQS 2
All I can think of now is
Publish message A to SQS A
Use code to pull message A from SQS and publish it to SQS 1 and SQS 2
Not really an atomic process I was looking for...
Is there an alternative to this approach?
Today, we launched Amazon SNS FIFO topics, which can fan out messages to multiple Amazon SQS FIFO queues!
https://aws.amazon.com/about-aws/whats-new/2020/10/amazon-sns-introduces-fifo-topics-with-strict-ordering-and-deduplication-of-messages/
You can think about using the AWS Kinesis Data stream. One feature of it is an ordering.
From faq: https://aws.amazon.com/kinesis/data-streams/faqs/
When should I use Amazon Kinesis Data Streams, and when should I use Amazon SQS?
Ordering of records. For example, you want to transfer log data from the application host to the processing/archival host while maintaining the order of log statements.
You can process events from Kinesis to SQSs.
If your goal is to have a message be pushed to two Amazon SQS FIFO queues, I'd recommend:
Have Amazon SNS trigger an AWS Lambda function
The Lambda function can send the same message to both Amazon SQS queues
It is effectively doing the fan-out via Lambda rather than SNS.
The Lambda function might also be able to extract a Message Group ID that it can provide with the SQS message, which will enable parallel processing of messages while maintaining FIFO within the message group. For example, all messages coming from a particular source will be FIFO, but can be processed in parallel with messages from other sources. It's a very powerful capability that would not be available just by having Amazon SNS forward the message.

S3 Event -> Lambda vs S3->SNS->Lambda

I'm trying to understand the behavior of S3 Event Notification trigger. I have s3 events to trigger lambda. Lambda captures the event and file metadata to dynamodb. There would be around 50k event triggers in short burst across the day. If I had to add SNS in the workflow and have SNS trigger lambda, what are the advantages with sns vs s3 directly invoking lambda?
There is no gained advantage. Both S3 and SNS events are asynchronous event sources and behave the same way. See: Lambda supported event sources And: Lambda Retry on Errors (Asynchronous invocation part), which highlights nicely the lambda behavior with specific types of event sources.
Simply doing S3 -> Lambda is sufficient.
The advantage is flexibility for the future. If you use SNS in the middle, you can easily send (fan-out) the notifications to multiple destinations with more SNS topic subscriptions -- another Lambda function, an SQS Queue, an HTTPS endpoint, or even email, which can be very useful for non-intrusive observation, testing, troubleshooting, and developing new capabilities that need the same notification.

AWS Lambda Triggered by SQS increases SQS request count

I have a AWS Lambda function which is triggered by SQS. This function is triggered approximately 100 times daily, but request count to the SQS queue is approximately 20.000 times daily. I don't understand why the number of requests made to the SQS is too high. My expectation is that the number of requests made to the SQS should be same with the Lambda invocation.
I have only one Lambda function and one SQS queue in my account.
Can be related with polling of SQS queue? I tried to change the polling interval of SQS from the queue configuration but nothing changed. Another possibility is to change polling interval from Lambda function configuration. However, I cannot find any related parameter.
Briefy, I want to reduce number of SQS request, how can i do that while invoking Lmabda function with SQS?
When using SQS as an event source for AWS Lambda, AWS Lambda regularly polls the configured SQS queue to fetch new messages. While the official documentation isn't clear really about that, the blog post announcing that feature goes into the details:
When an SQS event source mapping is initially created and enabled, or when messages first appear after a period with no traffic, then the Lambda service will begin polling the SQS queue using five parallel long-polling connections.
According to the AWS documentation, the default duration for a long poll from AWS Lambda to SQS is 20 seconds.
That results in five requests to SQS every 20 seconds for AWS Lambda functions without significant load, which sums up to the ~21600 per day, which is close to the 20000 you're experiencing.
While increasing the long poll duration seems like an easy way to decrease the number of requests, that's not possible, as the 20 seconds AWS Lambda is using by default is already the maximum possible duration for an SQS queue. I'm afraid there is no easy way to decrease the requests to SQS, when using it as event source for AWS Lambda. Instead depending it could be worth evaluating if another event source, like SNS, would fit your use case as well.
Here is how we originally implemented when there is no SQS trigger.
Create a SNS trigger with the SQS Cloudwatch Metric
ApproximateNumberOfMessagesVisible > 0
Trigger a Lambda from SNS, Read Messages from SQS and deliver it to whichever the lambda needs the message.
Alternatively, you can use Kinesis to deliver it to Lambda.
SQS --> Cloudwatch (Trigger Lambda) --> Lambda(Reads Messages) -->
Kinesis (Set Batch Size) --> Lambda (Handle Actual Message)
You can also use Kinesis directly but there is no delayed delivery.
Hope it helps.

How to pool AWS SQS with AWS Lambda

At the moment I'm are pooling AWS SQS from our back-end and doing business logic once payload is received.
I would like to move this to AWS Lambda and start automating business logic via SQS/SNS.
As I can not subscribe to AWS SQS events, what is the best practice in implementing SQS pooling with Lambda (node.js)?
SQS doesn't really work well with Lambda since you cannot automatically trigger Lambda functions from SQS queues messages.
I would rather remove the SQS/SNS logic and go for a DynamoDB Streams based solution that would cover the queueing, archiving & Lambda triggering tasks natively: your producer puts messages in a DynamoDB table while your Lambda is triggered for any new entry with Streams (it's an AWS native mechanism)
Of course a Kinesis based solution may be considered as well.
It is possible to even simplify the whole polling process by using the built-in SQS event source for lambda.
Lambda will automatically scale out horizontally consume the messages
in my queue. Lambda will try to consume the queue as quickly and
effeciently as possible by maximizing concurrency within the bounds of
each service. As the queue traffic fluctuates the Lambda service will
scale the polling operations up and down based on the number of
inflight messages.
see AWS Blog
As I can not subscribe to AWS SQS events,
Why?
Lambda can be triggered on SQS messages. Lambda internally handles the scaling, batching and retries for you. Check this AWS documentation on how to use Lambda with SQS.

AWS Lambda integration with SQS

Does AWS lambda provide support for listening to SQS queue? I found some examples which says one can do that but I am not sure if AWS lambda explicity provide support for that. When I create the lambda function, then I found one blueprint for SQS. So,
I linked to it in your other thread - these are the supported event sources. Notice that cloudwatch events are one of the possible event types. You could set up a Lambda to, for example, run every minute and poll an SQS queue. You cannot directly trigger a Lambda off of an SQS queue.
Good news, this feature was released yesterday!
28 JUN 2018: AWS Lambda Adds Amazon Simple Queue Service to Supported Event Sources
Read the announcement blog post here: https://aws.amazon.com/blogs/aws/aws-lambda-adds-amazon-simple-queue-service-to-supported-event-sources/
AWS Serverless Model supports a new event source as following:
Type: SQS
PropertiesProperties:
QueueQueue: arn:aws:sqs:us-west-2:012345678901:my-queue arn:aws:sqs:us-west-2:0123456789 # NOTE: FIFO SQS Queues are not yet supported
BatchSize: 10
And this is how it can be configured from the AWS Console UI:
You can make your lambda function poll the queue using the SQS API. You could use SNS to trigger the Lambda function.
Update: AWS Lambda can now be triggered from Amazon SQS queues.
Old answer:
Rather than having AWS Lambda poll an Amazon SQS queue, the application that sends the message to SQS queue should instead directly invoke the Lambda function. This could be done in several ways:
Direct invocation via an AWS API call
Sending a message to an Amazon SNS topic, with the Lambda function subscribed to the topic
Calling a function via AWS API Gateway, which can then trigger a Lambda function
The extra step of putting a message into an SQS queue is not necessary.