Very nice. The previously recommended implementation, IIRC, involved having a lambda basically polling SQS and invoking other lambdas to handle the messages. Very clunky. It's weird, because SQS as an event source is probably the first service you would have expected this behavior out of. Not that I'm complaining, better late than never.
On an unrelated note, does anybody else think that there is a very large/poorly defined behavioral umbrella shared by SQS, Kinesis, and Amazon MQ?
SQS is just a simple message queue: messages queue up and once consumed, they're gone. Kinesis is more like Kafka, being durable and replayable. Amazon MQ is just hosted ActiveMQ. All three have different use cases.
This "solution" essentially hides away long polling of the queue behind the scenes and triggers the Lambda when message shows up - and scales the poll sizes as number of messages increase and decrease.
It's what you had to previously do yourself with, for example, another Lambda, but handled by AWS and hidden from you. It's not a real event-driven model, like for example triggering Lambda by SNS.
The biggest thing to notice: because your queue gets polled behind the scenes, you will still be charged for the polling requests! Even if your queue is empty most of the time, you will pay for the requests that "check" for new messages.
In other words: by simply creating a Lambda and adding SQS queue as a trigger to it, you're adding a minimal spend to your AWS bill, that it will generate whether you're using it or not.
And because the polling is hidden from you and happens "automagically", you don't have control over how often it happens and how big the polling is, so you don't have control over the bill it will generate.
4 comments
[ 3.7 ms ] story [ 22.5 ms ] threadOn an unrelated note, does anybody else think that there is a very large/poorly defined behavioral umbrella shared by SQS, Kinesis, and Amazon MQ?
The biggest thing to notice: because your queue gets polled behind the scenes, you will still be charged for the polling requests! Even if your queue is empty most of the time, you will pay for the requests that "check" for new messages.
In other words: by simply creating a Lambda and adding SQS queue as a trigger to it, you're adding a minimal spend to your AWS bill, that it will generate whether you're using it or not.
And because the polling is hidden from you and happens "automagically", you don't have control over how often it happens and how big the polling is, so you don't have control over the bill it will generate.