Model the Lambda memory-versus-speed trade-off: predict duration at a new memory size and see whether the cost moves up or down.
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.
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 = 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.
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.
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.
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.