- Newest
- Most votes
- Most comments
There are multiple things at play here. Off the top of my head (so there are probably others):
You're invoking another Lambda function in each thread. This means interacting with the Lambda control plane (which is a shared service); launching another Lambda function (which has scaling implications as well as other control-plane actions such as rate limiting); and there are underlying things like TCP/TLS setup to the Lambda control plane API and authentication too. All of these things take time.
Adding to this is that the Lambda function you're calling could be a function that is being reused - or not. Depends highly on timing which will be non-deterministic.
Side question: I see your other post - why all the interest in threads? What are you trying to achieve here?
Edit: Probably not helpful to this specific question but perhaps of assistance in general, here's a good article to read (or watch) about the underlying Lambda service architecture: https://www.infoq.com/presentations/aws-lambda-arch/
Relevant content
- AWS OFFICIALUpdated 4 months ago
- AWS OFFICIALUpdated 4 years ago
- AWS OFFICIALUpdated 8 months ago

I did additional experimentation and observed that the last invocation of the child Lambda is delayed for almost a second after the nine other invocations of the child Lambda have returned their responses. There are no other Lambda function instances running, but it looks like I am hitting some hard limit. What could that limit be? My goal for parallelization is to read 10,000 items of 40 KB each from AWS DynamoDB in under one second. (I don't want to use step functions) Please see the update section in the question.
I think it's worth looking at the article linked above.