We are considering moving our API layer to a serverless model using AWS Lambda and API Gateway. While the "pay-as-you-go" model sounds great on paper for low-traffic sites, I’m worried about the costs spiraling out of control once we hit high concurrency. At what point does the cost of Lambda exceed the cost of running a dedicated EC2 cluster or an EKS environment?
3 answers
The "Serverless vs. Provisioned" debate usually hinges on your traffic patterns rather than just volume. If your traffic is consistent 24/7, a reserved EC2 instance or an EKS cluster with Fargate will almost always be cheaper because you aren't paying the "convenience premium" of Lambda. However, for "bursty" traffic—where you might go from 100 to 10,000 requests in seconds—serverless is unbeatable. You also need to factor in "Total Cost of Ownership." With Lambda, you save hundreds of engineering hours on patching, OS management, and scaling logic.
Are you concerned about the "cold start" latency issues that often plague serverless functions, especially with languages like Java or C# in a high-concurrency environment?
Serverless is usually cheaper up to a few million requests per day. Beyond that, the cost of API Gateway alone can often become more expensive than the actual compute power.
Karen hit the nail on the head. People often forget that the supporting services like API Gateway or CloudWatch logs are what really drive up the serverless bill at high scale.
Christopher, that is a valid concern. Provisioned Concurrency in AWS can solve the cold start problem, but it brings back a fixed cost, which sort of defeats the pure "pay-as-you-go" serverless philosophy. If latency is the #1 priority for a high-traffic app, a warmed-up container on EKS is usually the safer bet for performance consistency, even if the management overhead is slightly higher.