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.
About Lambda Memory Calculator
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.
Worked example
With the default values below, Lambda Memory Calculator returns Predicted Duration at Candidate Memory of 510. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Current memoryaccepts 128–10,240 MB
- 128 MB
- Current durationaccepts 1–900,000 ms
- 2,400 ms
- Candidate memoryaccepts 128–10,240 MB
- 1,024 MB
- Share of the work that is CPU boundaccepts 0–100 %
- 90 %
- Invocations per monthminimum 0 requests
- 2,000,000 requests
- Price per GB-secondminimum 0 USD
- 0.000017 USD
Results
- 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
Step by step
- 1Values used
- 2Lambda Memory
- 3Cost direction
- 4Predicted Duration at Candidate Memory= 510 ms
- 5Speed-up Factor= 4.71 x
- 6vCPU at Candidate Memory= 0.58 vCPU
- 7Monthly Compute at Candidate= 17.00
- 8Monthly Compute at Baseline= 10.00
- 9Recommendation= About 4.7x faster for 70% more compute spend
Assumptions and limits
- The result is derived only from the 6 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.