If you are using DynamoDB in your application, chances are that you are also utilizing DynamoDB stream to process any changes in the records. Here I'll just explain how you can handle the error while processing the DynamoDB stream with minimum/no code. I'm using cloud formation template to deploy all the changes to aws stack
if you are already processing stream, you must have created an EventSourceMapping for lambda and stream. If not, here is an example of how it looks like
Now , we want to send all the failures to an SQS. For that we need to create an SQS and update our EventSourceMapping to include that.
You also need to assign the SendMessage permission to the role under which lambda is running. You can assign this policy to the role .
SQSPolicy: Type: AWS::IAM::ManagedPolicy Properties: PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - sqs:SendMessage* Resource: - !GetAtt FailedRecordsQueue.Arn
The DestinationConfig provides the SQS as destination for failure. Here I have kept MaximumRetryAttempts as 0 so that lambda does not retry and send it to the SQS immediately. That's all you need to do to achieve this.
While testing this, if you have been using lambda, you may create a test event from the aws console to trigger lambda causing error and see if it writes to queue. That will not work. Since this is specially handling failure while processing DynamoDB stream, you need to change data in DynamoDB table to generate a stream which causes a failure within lambda and then it writes to SQS. You can go to created queue and check, it will have not the record which caused failure but enough information to fetch data from shards.