Lambda Cost & Memory Tuning Calculator
Price Lambda invocations and duration across every memory setting, including the free tier and Arm. Because CPU is allocated in proportion to memory, the cheapest configuration and the fastest affordable one are rarely the same number.
Cost across memory settings
Other levers
What this model assumes
- Cost is flat where the work scales, and rises where it does not. Doubling memory doubles the per-GB-second rate and halves the CPU-bound part of the runtime, so those cancel. The part that does not scale — waiting on I/O — gets billed at the higher rate with no speed-up, which is why the cheapest setting is usually the smallest one. You will read elsewhere that more memory is normally cheaper; under linear scaling it is not, it is faster for the same money, which is the more useful fact.
- The duration model is explicit, not assumed. Only the CPU-bound share of your runtime responds to more memory; the rest is held constant. That is why the tool asks how CPU-bound the function is instead of quietly picking a scaling law for you.
- Extra cores past the first get half weight. One full vCPU arrives at 1,769 MB. Beyond that, extra cores only help work that can use them, and most handlers are single-threaded — so the model discounts the benefit rather than promising linear speed-up to 10 GB.
- Duration bills in 1 ms increments, rounded up. For very short functions the rounding, not the memory, dominates.
- Provisioned concurrency and ephemeral storage are not modelled. Both are real charges, both are configuration-specific, and including them with invented defaults would obscure the one comparison this tool exists to make.
- First-tier rates only. Lambda duration is tiered downward at very high monthly volume; above roughly 6 billion GB-seconds your effective rate is lower than shown.
- Lambda duration, requests and storage — source, read 4 Aug 2026
US East (N. Virginia) list prices, excluding any negotiated or committed-use discount. Your effective rate is lower if you have one.
Frequently asked questions
Does giving Lambda more memory make it cheaper?
Usually not cheaper — usually faster for the same money, which is the more useful result. Lambda allocates CPU in proportion to memory, so doubling memory doubles the per-GB-second rate and roughly halves the CPU-bound part of the runtime. Those cancel. What does not cancel is the part of the runtime spent waiting on I/O, which gets billed at the higher rate with no speed-up — so the strictly cheapest setting is usually the smallest one, and slow. This calculator reports both: the cheapest setting, and the fastest setting that costs no more than a rounding error above it.
How much does AWS Lambda cost?
$0.0000166667 per GB-second on x86 and $0.20 per million requests in US East (N. Virginia), after a perpetual monthly free tier of one million requests and 400,000 GB-seconds. A function at 512 MB running 800 ms, called 50 million times a month, costs roughly $343 in duration plus $9.80 in requests.
Is Lambda on Graviton (arm64) cheaper?
Yes — $0.0000133334 per GB-second against $0.0000166667 on x86, about 20% less for the same memory and duration. The catch is native dependencies: anything compiled for x86 has to be rebuilt. For pure Python, Node or Go it is usually a one-line change to the architecture setting.
How much memory should I give a Lambda function?
Enough to reach the fastest setting that costs the same as the cheapest one — for most CPU-bound functions that is at or near 1,769 MB, where one full vCPU is allocated. Below that a function runs on a fraction of a core, so it is slower at no saving. For functions that mostly wait on a network call, memory changes little and the smallest setting that fits the workload is right.
Is Lambda cheaper than running EC2?
It depends entirely on duty cycle. Lambda charges only while code runs, so for spiky or low-volume workloads it is dramatically cheaper. For something that runs continuously, a reserved EC2 instance or a container is usually less expensive — the crossover is typically somewhere around a sustained few requests per second, and it moves with memory size.
Tuning one function is a spreadsheet. Tuning four hundred is not.
Finitizer reads real duration and memory metrics per function, finds the ones where the cheapest setting is not the current one, and tracks the functions whose duration has drifted since the last tuning pass.