At first, **YES, you're right**, you should think about your lambda function as "single request = single thread-safe stateless lambda". Such paradigm of thinking force us, engineers, to detach compute from data (state), scale each of it independently, avoid shared state, side effects, and at the end – reach high level of parallelism avoiding hard-to-debug pitfals of parallel programming. Regarding the second half of your question: the real beauty of the AWS Lambda is that it allows to move away from thinking about low-level concepts as CPUs utilization and IO-waiting time, and focus only only on the "business logic" and what exactly you want to achieve with your code. (and of course ,internally, AWS Lambda doing quite extensive under-the-hood optimization to avoid wasting of resources) So technically you can, run own event loop inside single lambda call and handle multiple request within each lambda call. However I would call it an anti-pattern and a maybe sign, that you might not need Lambda here at all. I would recommend simply to give it a try, and don't think too much about underneath resources optimization. Also, if I am not mistaken, the default lambda reserved concurrency is 1000, so should be enough to experiment with high traffic.

By default you have a concurrency limit of 1000 across all lambdas in a region, per account. https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html# This isn’t a hard quota, you can ask to increase it. As for your use case, seems that it matches what you have seen so far on your metrics. Just curious, Is there any reason why you set a reserved concurrency of 2000 for lambdas that are consuming an sqs queue ?