AWS Lambda Destinations Simplified

AWS Lambda Destinations

This feature sheds the light on function invocations and takes the results of execution to AWS services, making event-driven applications easier and reducing the complexity of every code.

Asynchronous Invocations and their Destinations

As a function gets invoked asynchronously these are the steps that occur:

– Lambda will start by sending the event to stay in an internal queue

– Another process will be reading events from this queue and will execute your function which was sent by Lambda

– As the event gets added to the queue, Lambda would have prior to this simply returned a 2xx status code for the sake of confirming that the queue has gotten this event

– Then no extra information was needed for the confirmation if the event got processed successfully or not

A commonly used event-driven pattern is that of using a queue or message bus for the sake of communication. This is of great help with scalability and resilience as well. The asynchronous invocations made by Lambda may place an event or message for being further processed on one of the following:

– Amazon Simple Notification Service (SNS)

– Amazon Simple Queue Service (SQS)

– Amazon EventBridge for further processing

Prior to this you would have been required to write the SQS/SNS/EventBridge handling code inside the Lambda function and then start managing all the retries and failures by yourself.

However, with Destinations, it has become possible to route asynchronous function results to a destination resource in the form of an execution record without the need to write any additional code. An execution record includes the following data:

– Details regarding the requests and responses in a JSON format

– Version

– Timestamp

– Request context

– Request payload

– Response context

– Response payload

For every single execution status like Success or Failure you have the chance to select one of the four following destinations:

– Another Lambda function

– SNS

– SQS

– EventBridge

Lambda may as well get configured for routing differing execution results to distinct destinations.

Success Status

If a function gets invoked in a successful manner, Lambda will then route the record to the destination resource as a successful invocation keeps on occurring. This may be utilized for the sake of monitoring the health of your serverless apps though the execution status or you can also build workflows according to the invocation result.

There won’t be any more need for chaining long-running Lambda functions together synchronously, where in previous cases you would have been required to get the whole workflow completed during the 15-minute function timeout of Lambda, then pay for the cost of idle time, and keep waiting for a response.

Destinations:

– Provide you with the ability to return back to the calling function a Success response and later on go ahead in handling the rest of the chaining functions asynchronously.

Failure Status

Destinations provide you with the capability to start handling the Failure of a functions’ invocations as well as their Success. In the case of a function invocation ending in failure, like when retries get exhausted or the event age gets exceeded as it hits the TTL, Destinations will route the record to the destination resource for all of the failed invocations to get them further investigated or processed.

Dead Letter Queues were available from the year 2016 and they have been a perfect way for handling all asynchronous failure situations. Destinations offer additional helpful capabilities through passing some extra function execution data, along with stack traces for code exception, to some other destination services.

Destinations and DLQs are capable of being utilized at once even though Destinations must have been considered as a better preferred solution.

In case of already having DLQs set up, the existing functionality shall not be changed and Destinations won’t replace existing DLQ configurations.

In case both Destinations and DLQ are utilized for the Failure notifications, then the function invoke errors will be sent to the DLQ targets as well as the Destinations targets.

How to configure Destinations

The process to add Destinations is a simple and straightforward process. The steps listed here will be using the Management Console but you get the chance to utilize CLI, SAM, CloudFormation, or some language-specific SDKs for Lambda.

1. Head to the Lambda console Functions page. Select an already existing Lambda function, or begin creating a new one. For this example, we’ll be creating a new Lambda function. Click on Create Function.

2. Fill in a Function name, choose Node.js 12.x for Runtime, and either head to Choose or start creating an execution role. Make sure that the Lambda function execution role has access to the destination resource.

 

3. Click Create function.

4. From the Function code pane, paste the following Lambda function code. The code will start generating a function execution result as being a Success or Failure according to a JSON input (“Success”: true or “Failure”: false).

// Lambda Destinations tester, Success will be returning a json blob, Failure will be throwing an error

 

exports.handler = function(event, context, callback) {

var event_received_at = new Date().toISOString();

console.log(‘Event received at: ‘ + event_received_at);

console.log(‘Received event:’, JSON.stringify(event, null, 2));

 

if (event.Success) {

console.log(“Success”);

context.callbackWaitsForEmptyEventLoop = false;

callback(null);

} else {

console.log(“Failure”);

context.callbackWaitsForEmptyEventLoop = false;

callback(new Error(“Failure from event, Success = false, I am failing!”), ‘Destination Function Error Thrown’);

}

};

5. Click on Save.

6. For configuring Destinations, in the Designer pane, select Add destination.

7. Choose the Source to be Asynchronous invocation. Choose the Condition to be On failure or On success, according to what your use case will be. For this example, let’s choose On Success.

8. Fill in the Amazon Resource Name – ARN for the Destination SQS queue, SNS topic, Lambda function, or EventBridge event bus.

9. Select Save. The Destination will get added to SNS as being On Success.

10. Start adding another Destination for Failure to Lambda. From the Designer pane, click on Add destination.

 

11. Choose the Source to be Asynchronous invocation, the Condition to be On failure and Fill in a Destination Lambda function ARN, then select Save.

12. At last the Destination gets added to Lambda as On Failure.

aws lambda triggers