Challenges of using AWS Lambda chain
I am using lambda in response to objects appearing on S3 buckets.  For me in my particular use case, there are around 600 triggers a day.  I have written our lambda functions to use their stdout as their log file, writing all key events to standard out in a semi-structured textual sentence mixed with key/value pairs for data values, and then feed the cloudwatch logs into splunk.

Here is what I have found...


Lambdas will (occasionally) be triggered multiple times for the same object.
Lambdas will (sometimes) take noticeably longer to run than normal.
To see / diagnose issues caused by concurrent invocations that interfere with each other, the AWS Web Console doesn't do it. You need a tool like splunk.


However, does the value of this work provide enough revenue to cover the costs of using ECS(Elastic Container Service) for your process management?  If you are able to run an ECS container, you could trigger the lambda on S3 object creation to create a message on an SQS message queue. Your ECS container is listening to your queue and when a message arrives, processes it just like within your lambda.  Its output to trigger the next stage is to pop a message onto the SQS queue handling the next task.

This will solve a few problems for you, such as escaping the 5 minute maximum for Lambdas, and creating an easy way to retry failures.

However, it will create a few new issues too.


Creating and deploying docker images is more work than editing lambda on the AWS console.
Infrastructure costs are more fixed in nature, rather than proportional to workload.