Roel van den Brand

Overall, I would think, if the data fits in AWS DynamoDB with being able to Query (not scan) that would be a bit more cost effective. But it all depends on the size and changes in the data.

On relatively stale data Athena could be cheaper on big loads when the data is processed via Glue, Lambda costs are quite small. DynamoDB could become expensive under big loads of (reads and/or writes)

We picked Node.js over Python for simple AWS Lambda functions. The team had experience in javascript, it is easy to read and inline editable. It appears to be a bit more similiar to C#.

We write complex AWS Lambda functions in C# with our own packages and lots of logic. This is for small 1-page scripts to run simple forwarding or administrative tasks in which we can directly see what the code is and does.

If it is only log ingress, other tools might be a better fit. Open Search or an ELK stack or just S3 with AWS Athena. Otherwise it really depends on on how you want to search in yourdata.

Use case for ingressing a lot of data and post-process the data and forward it to multiple endpoints.

Kinesis can ingress a lot of data easier without have to manage scaling in DynamoDB (ondemand would be too expensive) We looked at DynamoDB Streams to hook up with Lambda, but Kinesis provides the same, and a backup incoming data to S3 with Firehose instead of using the TTL in DynamoDB.

It depends for whom the documentation is. API docs or developer documentation seem okay in readme.io (no experience) but we use Confluence for documentation for designers, analists, developers, kb and internal customers. It integrates very well with diagrams.net (draw.io), Trello and many other tools.

Maybe you can do it with storing on S3, and query via Amazon Athena en AWS Glue. Don't know about the performance though. Fuzzy search could otherwise be done with storing a soundex value of the fields you want to search on in a MongoDB. In DynamoDB you would need indexes on every searchable field if you want it to be efficient.