Lambda Memory Calculator
Model the Lambda memory-versus-speed trade-off: predict duration at a new memory size and see whether the cost moves up or down.
Inputs
Waiting on a database or HTTP call does not speed up with more vCPU.
Predicted Duration at Candidate Memory
510ms
Speed-up Factor
4.71x
vCPU at Candidate Memory
0.58vCPU
Monthly Compute at Candidate
$17.00
Monthly Compute at Baseline
$10.00
Recommendation
About 4.7x faster for 70% more compute spend
Step by step
Values used
Current memory = 128 MB; Current duration = 2,400 ms; Candidate memory = 1,024 MB; Share of the work that is CPU bound = 90 %; Invocations per month = 2,000,000 requests; Price per GB-second = 0.0000 USD
Lambda Memory
predicted duration = current duration × ((1 − CPU-bound share) + CPU-bound share ÷ memory ratio), where the memory ratio is candidate MB ÷ current MB.
Cost direction
cost ratio = (candidate MB × predicted ms) ÷ (current MB × current ms) — cost is flat only when the work is 100% CPU bound.
Predicted Duration at Candidate Memory
= 510 ms
Speed-up Factor
= 4.71 x
vCPU at Candidate Memory
= 0.58 vCPU
Monthly Compute at Candidate
= 17.00
Monthly Compute at Baseline
= 10.00
Recommendation
= About 4.7x faster for 70% more compute spend
How it works
Lambda allocates CPU in proportion to memory, reaching one full vCPU at 1769 MB and about six vCPUs at 10,240 MB, so doubling memory can nearly halve a CPU-bound duration. That makes the compute cost roughly flat for perfectly parallel work and strictly higher for anything that spends its time waiting on a network call. Verify the GB-second rate for your region, and validate the prediction with AWS Lambda Power Tuning against the real function. Teams routinely leave functions at 128 MB believing it is the cheap option, when raising memory can cut latency several-fold for the same or slightly higher spend — and the reverse mistake, over-provisioning an I/O-bound function, quietly multiplies the bill.
Formulas
Lambda Memory
predicted duration = current duration × ((1 − CPU-bound share) + CPU-bound share ÷ memory ratio), where the memory ratio is candidate MB ÷ current MB.
- memory ratio
- How much more CPU the candidate size gets (CPU scales with memory)
- CPU-bound share
- Fraction of the duration that is compute rather than waiting on I/O
- vCPU
- Memory MB ÷ 1769, the point where Lambda grants one full vCPU
Cost direction
cost ratio = (candidate MB × predicted ms) ÷ (current MB × current ms) — cost is flat only when the work is 100% CPU bound.
Frequently Asked Questions
How is Lambda Memory calculated?
predicted duration = current duration × ((1 − CPU-bound share) + CPU-bound share ÷ memory ratio), where the memory ratio is candidate MB ÷ current MB. Lambda allocates CPU in proportion to memory, reaching one full vCPU at 1769 MB and about six vCPUs at 10,240 MB, so doubling memory can nearly halve a CPU-bound duration. That makes the compute cost roughly flat for perfectly parallel work and strictly higher for anything that spends its time waiting on a network call. Verify the GB-second rate for your region, and validate the prediction with AWS Lambda Power Tuning against the real function.
Why does Lambda Memory matter?
Teams routinely leave functions at 128 MB believing it is the cheap option, when raising memory can cut latency several-fold for the same or slightly higher spend — and the reverse mistake, over-provisioning an I/O-bound function, quietly multiplies the bill.
What values do I need to enter?
This calculator takes 6 inputs: Current memory, Current duration, Candidate memory, Share of the work that is CPU bound, Invocations per month, Price per GB-second. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Is more memory ever genuinely cheaper?
Yes, when the duration falls faster than the memory rises. That happens with compute-heavy work below 1769 MB, where the function is starved of a full vCPU, and with runtimes whose garbage collector thrashes at small heap sizes. Above roughly 3 GB most single-threaded code stops improving and the cost curve turns upward.