Right-size Lambda memory guide: the setting that sets your bill

Quick answer

Lambda bills per GB-second, so cost equals allocated memory times execution duration, and memory also determines how much CPU the function gets. Because more memory means more CPU and faster execution, raising memory can shorten duration enough to lower the total cost per invocation, up to a point. Right-sizing means finding the memory setting that minimizes cost per invocation for your function, not just the lowest memory. The lowest setting is often not the cheapest: the sweet spot balances memory against the faster execution it buys.

Lambda has one deceptively important knob: memory. It looks like a simple resource setting, but because Lambda bills per GB-second and memory also scales the CPU your function gets, the memory setting directly determines both the price and the speed of every invocation. Getting it right is a genuine optimization, and the intuitive choice, the lowest memory, is often not the cheapest.

How memory drives Lambda cost

Setting change	Effect
More memory	Higher per-GB-second rate, but more CPU and faster execution
Less memory	Lower per-GB-second rate, but slower execution
Cost per invocation	Memory times duration, so both matter

Cost per invocation is allocated memory multiplied by execution duration. Raising memory increases the per-unit rate but also gives the function more CPU, which can make it finish faster. If the speedup is large enough, the shorter duration more than offsets the higher memory rate, and total cost per invocation drops. That is why the cheapest setting is a balance, not the minimum.

Why the lowest setting is not always cheapest

For CPU-bound functions, doubling memory can nearly halve execution time, so the cost per invocation stays flat or even falls while latency improves, a rare win-win. For simple, fast, I/O-bound functions, extra memory buys little speedup and just raises cost, so low memory is cheapest. The right setting depends on whether the function is compute-bound or waiting on I/O, which is why you tune rather than guess.

Finding the sweet spot

Test the function at several memory settings and measure both duration and cost per invocation, then pick the setting with the lowest cost per invocation (or the best cost-latency tradeoff if latency matters). Tooling like the open-source Lambda power tuning approach automates this sweep. Do this per function, since the optimum differs by workload. Faster execution from more memory can also reduce cold-start impact, relevant to the provisioned concurrency decision.

Fitting into the bigger picture

Memory right-sizing is the core Lambda cost lever, the serverless analog of EC2 right-sizing, and it should inform whether Lambda or a container platform is cheaper for your workload, as the Lambda versus Fargate comparison covers. Re-tune when the function's code or workload changes. Price your Lambda configuration against the resource catalog so the memory setting is a measured choice, not a default.

FAQ

How does Lambda memory affect cost?

Lambda bills per GB-second, so cost per invocation is allocated memory multiplied by execution duration. Memory also determines how much CPU the function gets, so more memory means faster execution. Raising memory increases the per-unit rate but can shorten duration, so the total cost per invocation depends on both, and the cheapest setting balances memory against the speed it buys.

Is the lowest Lambda memory setting the cheapest?

Not always. For CPU-bound functions, more memory means more CPU and faster execution, so a higher memory setting can finish quickly enough that total cost per invocation stays flat or falls. For simple I/O-bound functions, extra memory buys little speedup and just raises cost, so low memory is cheapest. The optimal setting depends on whether the function is compute-bound or waiting on I/O.

How do I find the optimal Lambda memory setting?

Test the function at several memory settings and measure both duration and cost per invocation, then pick the setting with the lowest cost per invocation, or the best cost-latency tradeoff if latency matters. Tools like the open-source Lambda power tuning approach automate this sweep. Do it per function, since the optimum differs by workload, and re-tune when the code or workload changes.

Why does more memory sometimes make Lambda cheaper?

Because memory scales the CPU allocated to the function, so for CPU-bound work, more memory can nearly halve execution time. Since cost is memory times duration, a large enough speedup offsets the higher per-unit rate, keeping cost flat or lowering it while improving latency, a win-win. This only holds for compute-bound functions; I/O-bound ones see little speedup from extra memory.

Does Lambda memory affect cold starts?

Yes. More allocated memory means more CPU, which speeds up the initialization phase, so higher memory can reduce cold-start duration. That makes memory right-sizing relevant to the cold-start problem and can be a cheaper alternative to provisioned concurrency for some functions, since you pay only when the function runs rather than keeping environments warm around the clock.

How does C3X help right-size Lambda memory?

C3X prices your Lambda configuration, including the memory setting, from Terraform before you deploy, so the cost implications of a memory choice are visible in the pull request. That complements runtime power-tuning by making the cost of a Lambda function's configuration clear at design time, helping you set memory deliberately rather than leaving it at a default that may not be the cheapest.

What to do next

Price your Lambda configuration before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.