Serverless pitfalls: issues with running a startup on AWS Lambda
- Functions with less RAM have slower CPU speed. Take both CPU and RAM into account (as well as the related costs: you save no money once execution time drops below 100ms) when allocating resources to Lambda functions.
- Hosting your backend behind an API gateway can result in latency issues. If you want <50ms response times, you need dedicated infrastructure.
- Lambdas in a VPC cannot connect to outside services like S3 unless you install a NAT gateway, with the associated charges. It’s best to run either completely inside or outside a VPC, even if it means less security and more latency and bandwidth costs.
- Due to their distributed queues, AWS can execute Lambdas more than once per request. So be aware of and work around their idempotency.
- You’ll find it hard to identify and debug functions that hang or get deadlocked because they automatically disappear over the limit. You’ll need to look to Cloudwatch for them.
- Executing a Lambda from another Lambda is slow. Either launch a task specifically to launch a large number of other tasks or use threads to launch multiple tasks simultaneously.
- To work around the dreaded cold start, you can move front-end requests facing the end user off Lambda and try to containerize.
Full post here, 10 mins read