There is a third approach besides "lambdalith" and "one lambda per route", it's making one lambda for a group of routes, for example you could group them by fir

There is a third approach besides "lambdalith" and "one lambda per route", it's making one lambda for a group of routes, for example you could group them by first segment of their path (all routes starting with /users/* in one lambda, all /orders/* in another, etc). Then, inside the lambda handler, you can use a routing library to select the right method. This worked for us because it mitigated the shortcomings of the other two approaches for example: - lambdalith: very long build times and long deploy times (due to the high number of lambdas) - one lambda per route: lack of permission granularity (as opposed to creating different IAM roles for different lambdas); lack of granularity for memory/cores configuration means you are missing out on cost optimisation; also, as the API grows, it soon becomes necessary to adopt some framework like Express or Fastify to keep things tidy. EDIT: reworded last paragraph for clarity.