aws-fis-templates-cdk VS failure-lambda

Enables support for putting configuration in parameter store to enable AWS Lambda faults via libraries. https://github.com/adhorn/aws-fis-templates-cdk/blob/main/lib/fis-upload-ssm-docs/documents/ssma-put-config-parameterstore.yml

failure-lambda is a small Node module for injecting failure into AWS Lambda. It offers a simple failure injection wrapper for your Lambda handler where you then can choose to inject failure by setting the failureMode to latency, exception, denylist, diskspace or statuscode. https://github.com/gunnargrosch/failure-lambda

In one of our last projects, I started using Failure-Lambda module from Gunnar Grosch to be able to inject failure in our system. Not yet in production, but it helped a lot during the test and staging phase to detect and handle possible errors that we overlooked. (If you want to know more about Chaos Engineering and Failure Lambda check out this post) So I was very eager to see his speech about Chaos Engineering at the Hamburg Serverless Days.

A common approach is to implement a circuit breaker inside your function and use DynamoDB to store the circuit breaker state (like Gunnar Grosch’s failure lambda node.js implementation and Jeremy Daly outlines in his AWS Reference Architecture Pattern). The Lambda function will fail before calling the Third-Party API when a failure threshold has been exceeded. This protects the downstream service, but it will not stop AWS Lambda polling the upstream queue and invoking your function. You also have to make changes to lambda function code, specific to the particular Lambda runtime and programming language. The approach introduces a number of DynamoDB requests which could significantly increase costs.