CODEWITHSUNDEEP
aws-lambdaamazon-sqsamazon-snsaws-lambda-edge
micah
micah

Reputation: 8096

SNS to SQS vs Direct SQS Put in Lambda@Edge Applications

I'm looking into using Lambda@Edge to place events generated from external sources into an internal SQS queue. The lambda simply needs to transform it when necessary, do the hand off, and leave. I'd like this to be as fast as possible, so my question is, is there a benefit to using SNS in addition to SQS, or should I just use SQS?

In other words, given these two configurations, would one be more performant for the end user?

A) Request comes into Lambda@Edge, the lambda transforms the request and sends the event to SNS, SNS puts the event to SQS.

B) Request comes into Lambds@Edge, the lambda transforms the request and puts the event to SQS directly.

Edit:

I am talking cross region.

Upvotes: 5

Views: 2043

Answers (1)

Michael - sqlbot
Michael - sqlbot

Reputation: 178956

Cross-region, SNS-to-SQS will be significantly faster, if configured as described here.

The optimal configuration will be to create an identically-named SNS topic in every AWS region, and subscribe your SQS queue (which is presumably just one queue, in one single region) to all of those topics.

When an Lambda@Edge trigger is running, that code runs in the region nearest to the viewer, and process.env.AWS_REGION will tell you what region that is, for each invocation.

Use this information to initialize the SNS client, and send the message to the SNS topic in that region. SNS will immediately accept the message but will deliver it asynchronously (from your perspective), cross-region, to the SQS queue -- so it won't block your function from finishing. Making any cross-region request directly from the Lambda trigger function, whether to SQS or SNS will increase your latency.

Upvotes: 7

Related Questions