Sometimes the development teams fall into a belief that it may be difficult to have many small Lambda functions in terms of creating and managing the functions. That worry may cause them to hesitate from creating and deploying modular Lambda functions and instead opt-for bigger functions do different things depending on the event parameters, request type or other variables. In this post, I will provide my arguments on why these worries are usually unnecessary and it is a good to keep your Lambda functions small and modular.
Another recent development that increases the effect of small functions is the change to the granularity of execution time. Around the start of 2021, AWS reduced the billing granularity for Lambda functions from 100ms down to 1ms. So, prior to this, a function that took 30ms was billed as if it took 100ms since it is the minimum granularity. Now, a function that takes 30ms to run is 70% cheaper than a function that takes 100ms so you get the benefit of every millisecond performance improvement as a cut in the costs.
Deploying functions that abide by the principle of single-responsibility means that you will have your CloudWatch logs available for every function in your application and whenever something goes wrong in that function, you will know that the error is related to one particular responsibility your function has. With the functions that do many things, it is not that easy to say what went wrong. Since the logic of all the branches in your if statements will be connected to a single CloudWatch log, you would probably need to either have log statements in each of your branches to see which one of them crashed or you would be obligated to debug the whole function to find the source.