
AWS Lambda Adds Amazon Simple Queue Service to Supported Event Sources - luhn
https://aws.amazon.com/blogs/aws/aws-lambda-adds-amazon-simple-queue-service-to-supported-event-sources/
======
ralusek
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?

~~~
leetbulb
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.

------
inka
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.

------
nikolay
Finally! Such a basic feature, which took so long to add!

