When Should I Use Async or Threading in AWS Lambda with FastAPI?

If your Lambda function is triggered by an API Gateway request, it's usually a sequential process where each step depends on the last one. In such cases, async programming or threading may not be beneficial. However, I have worked on a Lambda that needed to do several tasks, including calling multiple DynamoDB tables and making several API calls back to the Gateway. By using async constructs like NodeJS Promises and async/await, I managed to run many calls simultaneously, greatly reducing latency and costs.

In situations where your Lambda is processing a lot of files at once, threading can really help since you can handle multiple files simultaneously. It just makes sense to thread rather than processing them one after another.

Remember that while Lambda can execute many instances of your function at once, each execution is isolated. There’s no sharing of requests within a single instance. So, if you're stuck waiting for an I/O operation, threading only makes sense if there's additional work you can do while waiting. If your tasks are dependent on one another, threading won't provide any real benefits.

We utilize threading in our Lambdas for high concurrency levels. Our setup sometimes handles hundreds of Lambda functions launched via SQS, with each function potentially operating with 10 to 50 threads. It requires careful tuning because there's a limit on how much your Lambda can scale before processing times are negatively impacted.

Using FastAPI within Lambda means you’re actually limited to one request at a time per instance. You lose many advantages of async programming here. Also, remember that Lambda ties CPU performance to memory allocation. If your endpoint is mainly waiting for I/O, the actual CPU time used will likely be minimal.