We've recently migrated our microservices to a serverless architecture, but our monthly bill is skyrocketing due to high invocation counts. We are trying to leverage modern cloud technology to stay agile, but the "pay-as-you-go" model is hurting us at scale. Are there specific patterns for memory allocation or provisioned concurrency that can help bring these costs down without sacrificing our 200ms latency targets?
3 answers
Scaling serverless effectively requires a shift in how you view resource allocation. Many developers think lowering memory saves money, but it actually increases execution time, which can lead to higher costs in the 1ms billing tier. I recommend using the AWS Lambda Power Tuning tool to find the "sweet spot" where execution speed and cost intersect. In 2024, we’ve also seen success by shifting synchronous API calls to asynchronous patterns using SQS, which prevents Lambda functions from "waiting" on downstream services while the billing clock is ticking.
Have you considered if a portion of your workload would be better suited for Fargate instead of Lambda? If you have a constant baseline of traffic, wouldn't containers provide a more predictable cost structure than per-invocation billing?
You should definitely look into Saving Plans for Compute. They apply to Lambda as well and can offer up to a 17% discount if you commit to a certain amount of hourly usage.
Ryan is right. We implemented Compute Savings Plans last quarter and it was the easiest way to see an immediate drop in our bill without changing a single line of code.
Kevin, Fargate is definitely a contender for baseline loads, but we love the zero-maintenance aspect of Lambda. To answer your question, we are looking at a hybrid approach where we use Lambda for bursts and Fargate for the heavy lifting. The main challenge there is the deployment complexity of managing two different compute environments for the same application logic. We'd need to ensure our CI/CD pipeline is sophisticated enough to handle both.