A "spectrum_enable_enhanced_vpc_routing" parameter has appeared in Redshift.

Redshift Spectrum finally supports Enhanced VPC routing

What seems like an age ago, I spotted a setting on one of our Redshift clusters that suggested Enhanced VPC routing support for Redshift Spectrum might be on the way.  After waiting a while, and waiting some more, and then waiting some more, it seems that Amazon have finally released this into the wild, and Redshift Spectrum now works with clusters that have Enhanced VPC routing available!

As of Build 1.0.4349 or Build 1.0.4515, this functionality will be available in Redshift.  It hasn’t made it into the official announcements yet, but it has popped up on the Redshift forums here: https://forums.aws.amazon.com/ann.jspa?annID=6197 Continue reading “Redshift Spectrum finally supports Enhanced VPC routing” »

AWS Lambda function with SQS as an event trigger

AWS Lambda can now be invoked directly from SQS

While quietly perusing Twitter this evening, I happened to notice one from the official AWS account with a link to a blog post from Amazon tech hero Randall Hunt describing the newly available capability for AWS Lambda: SQS as an event source!

This is functionality that I, personally, have been wanting for a while now.  While Simple Notification Service (SNS) is absolutely brilliant for a fan-out architecture, and provides immense flexibility with a wide range of supported subscriber types, controlled, serverless polling of SQS wasn’t really a viable option.  While you *could* run a Lambda for a few minutes doing long-polling on SQS, and then terminate before exhausting the 5-minute execution duration cap, it really felt a bit dirty.  To properly implement a queue-polling architecture, you really had to deploy an application on EC2, which meant managing servers etc.  Not that there’s anything wrong with that of course, it just seemed like there was a big glaring hole in the Serverless model.

Native SQS to Lambda event integration though really patches this omission and then some.  Randall’s blog post explains it in full, but it seems like Amazon have implemented some really nice intelligent scaling mechanisms to adjust Lambda concurrency (up to a defined limit) in response to queue depth.  This should really help constrain costs and ensure consistent throughput regardless of spiky traffic.

I’ve not yet had a chance to observe this in the wild though, so best tested for your workload before betting the farm on it, but this looks like yet another long-awaited piece of functionality that Amazon have knocked out the park.  Have you explored SQS as an event source for Lambda yet?  Any observations or gotchas so far?  Let me know in the comments below!

SQS vs SNS for Lambda Dead Letter Queues

Serverless computing and event-driven functions are what it’s all about at the moment.  But what happens when the event trigger fires, and your process then encounters an error?  How do you recover from this given the event has since passed and may never happen again?  This is a common question in AWS when working with their serverless, event-driven Lambda Functions.

Fortunately, AWS lets you define Dead Letter Queues for this very scenario.  This option allows you to designate either an SQS queue or SNS topic as a DLQ, meaning that when your Lambda function fails it will push the incoming event message (and some additional context) onto the specified resource.  If it’s SNS you can send out alerts or trigger other services (maybe even a retry of the same function – although watch out for infinite loops), or any combination of the above, given its fanout nature.  If it’s SQS you can persist the message and process it with another service.

So let’s look at both options in a little more detail. Continue reading “SQS vs SNS for Lambda Dead Letter Queues” »