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.