Congratulations Joy!

Yes. This is just a preliminary step to protect yourself in basic manual audits :) Spring vault - https://spring.io/projects/spring-vault - is a better idea

You can check your IAM role - if it has the required permissions. If it is good, you can try to remove the exception suppression in the lambda code. That will show you exact line where the error occurs - so that you can fix it.

Aman, thanks for your comment. But I would suggest that you read the full blog before concluding. It does talk about recognizing faces based on similarly - using the face_recognition librery

Thanks for sharing!

Thanks for your inputs. https://docs.aws.amazon.com/lambda/latest/dg/runtimes-walkthrough.html 500 Mb (512 to be precise) is the net allowed - including the runtime itself - that is if you take up the a custom runtime. Of course, things have changed with the container in Lambda. But that has impact on the pricing as well. The serverless framework itself brings in so much to the deployment - it ends up blowing up the deployment size. I had not tried the webpack before. Tried it after your comment. But I saw it had problems with non js code in the node_modules. It was wonderful with pure js code. Any way to overcome that?

Thanks for the insight. What I showed above is just a reminder to delete the node_modules that is already collected in the previous step. Ofcourse, in real live, we don't have to install, delete and install once again. A simple npm install --production is enougn. Perhaps I need to elaborate on that point. Thanks for pointing out

That's a good idea. Will push this as a public API. API Gateway caching can be disabled. I have not tested this under Very High load - But it worked pretty well in 100 hits per second