Amazon SQS and DynamoDB

pair well with Lambda

Lambda users have a vast array of technology choices when it comes to connecting their functions to infrastructure and application components. Once a function is triggered, it often sends the data it produces to a message queue, which routes the data onward to other Lambda functions, server-based applications, or cloud services. Message queues help organizations embrace the “pay only for what you use” model of serverless. Instead of a function calling another function and waiting idly for a response (and racking up billable invocation time), serverless functions can make calls asynchronously via a message queue. And because functions are ephemeral and stateless, they often read from or write to a separate, persistent data store.

Among the services that are called or queried in the same request as a Lambda function, Amazon DynamoDB comes out on top. The key-value and document store is a natural fit for Lambda functions, given that it is a hosted, auto-scaling data store that promises low latency. The next most popular choices for data stores in Lambda use cases are SQL databases (whether Amazon RDS instances or self-managed databases) and Amazon S3, respectively. Amazon SQS (Simple Queue Service) is the top choice for a message queue in Lambda requests, followed by Amazon Kinesis and Amazon SNS (Simple Notification Service). SQS is a logical fit for serverless architectures: it is simple to set up and scale, relatively inexpensive, and offers tight integration with Lambda.