Why Doubling Lambda Memory Doesn't Double the Bill
AWS allocates CPU to a Lambda function roughly proportional to its configured memory, up to 1,769MB — the point where a function crosses from one vCPU to two. Below that threshold, this calculator models a CPU-bound function's execution time as scaling inversely with memory: scalingFactor = 128 / memoryMB, applied to your measured baseline runtime at 128MB minus a fixed 50ms of I/O wait that doesn't shrink with more CPU (network calls, cold dependency connections). So a function taking 1,000ms at 128MB is modeled at roughly 550ms at 256MB, not exactly half, because that 50ms floor stays constant regardless of memory tier.
The Cost Math Behind the Crossover
Billed cost is GB-seconds × memoryGB × pricePerGbSecond (modeled at $0.0000166667 per GB-second for x86, plus $0.20 per million requests) — and because doubling memory can roughly halve duration for CPU-bound work, the GB-seconds term can stay flat or even shrink as you move up a tier, meaning more memory sometimes costs the same or less while cutting latency. That relationship breaks down once a function is I/O-bound rather than CPU-bound: past the point where the fixed 50ms wait (or genuine network latency) dominates total runtime, extra memory keeps costing more per invocation without buying meaningfully faster responses — which is exactly why this tool plots the cheapest and fastest memory tier separately instead of assuming they're the same one.