My team is debating moving our REST API from traditional EC2 instances to AWS Lambda. We have high traffic during the day but almost zero at night. While the "pay only for what you use" model is attractive, I’ve heard horror stories about "concurrency limits" and "cold starts" affecting performance. Is there a tipping point where Lambda becomes more expensive than a well-tuned auto-scaling cluster?
3 answers
There is definitely a tipping point. If your API has a consistent, high baseline of traffic 24/7, Lambda can actually be significantly more expensive than Fargate or EC2 Spot Instances. However, for your use case—high day traffic and zero night traffic—Lambda is usually the winner because you aren't paying for idle CPU cycles at 3 AM. To solve the cold start issue, use "Provisioned Concurrency" for your busiest hours. It keeps a set number of functions warm. Just be careful, because if you over-provision, you lose the cost benefits of serverless. We found that for 1 million requests per day, Lambda was 30% cheaper for us.
How heavy are your application dependencies? If you're running a massive Java Spring Boot app, your cold starts will be seconds, not milliseconds. Have you looked into lighter runtimes like Node.js or Go?
For high-traffic APIs, also consider the cost of API Gateway. Often, the "hidden" cost isn't the Lambda execution, but the millions of requests hitting the gateway.
Brian is right. We switched to an Application Load Balancer (ALB) in front of our Lambdas instead of API Gateway for our high-volume routes. It saved us nearly 40% on our monthly AWS bill.
James, we actually did a benchmark on this. Moving from a bloated Python environment to a slimmed-down Go binary reduced our cold start from 1.2 seconds to about 200ms. It also allowed us to lower the memory allocation for our Lambda functions, which directly reduced our execution cost. It's not just about the runtime; it's about how you package your deployment artifacts to keep them small.