Lambda cost is the product of invocations, allocated memory, and duration, so the bill falls when you right size memory to the cheapest total cost per invocation and cut the time each invocation runs, not when you simply lower the memory slider. Counterintuitively, raising memory often lowers cost for CPU bound functions because it adds proportional CPU and shortens duration, so the right memory setting is the one with the lowest measured GB seconds, found through power tuning rather than guesswork. A steady Lambda baseline is also covered by Compute Savings Plans at roughly up to 17 percent off, and very high volume continuous functions can be cheaper rearchitected onto a container, so the practical playbook is tune memory, cut duration, cover the baseline, and know when to leave serverless.
Here is how Lambda billing actually works, the levers that move it, and a worked tuning example.
What are you actually paying for on Lambda?
Two meters drive the bill. The first is requests, a flat charge per million invocations. The second, and usually the larger, is GB seconds: the memory you allocate to a function multiplied by how long each invocation runs, summed across all invocations. Allocating 1024 MB to a function that runs 200 milliseconds a million times is far more GB seconds than 512 MB at 120 milliseconds. The subtle part is that the memory slider also sets CPU, network, and disk proportionally, so memory is not just a cost knob, it is a performance knob. That coupling is why blindly lowering memory can raise cost: a starved function runs longer, and the extra duration can outweigh the lower per millisecond rate.
Which levers actually move the Lambda bill?
| Lever | What it does | Typical impact |
|---|---|---|
| Power tuning memory | Finds the memory setting with the lowest cost per invocation | Often 30 percent or more on CPU bound functions |
| Cutting duration | Faster code, lighter dependencies, connection reuse, caching | Direct, linear cut to GB seconds |
| Arm based Graviton | Switching the function architecture to arm64 | Roughly up to 20 percent better price performance |
| Compute Savings Plans | Discounts the steady Lambda baseline | Roughly up to 17 percent on covered spend |
| Right sized timeouts and retries | Stops runaway invocations and retry storms | Removes silent waste from failures |
Discount and price performance figures are indicative; verify against current AWS Lambda pricing.
How do you tune memory without guessing?
Run a power tuning pass: execute the function across a range of memory settings with representative input, record cost and duration at each, and pick the setting at the cost minimum rather than the fastest or the cheapest per millisecond. For CPU bound work the curve is U shaped, and the bottom often sits well above the default, so under provisioning is a common and expensive mistake. For functions that mostly wait on a downstream call, extra memory cannot shorten the wait, so the cheapest setting is low. Pair the memory pass with duration work that pays back every invocation forever: trim cold start by shrinking the deployment package, reuse database and HTTP connections across invocations, and cache values that do not change per call. Then move the function to arm64 Graviton where the runtime supports it for a further price performance gain.
A worked example
A European SaaS company ran an image processing function at 512 MB to keep the per millisecond rate low, and it was their largest Lambda line. Power tuning showed the function was CPU bound: at 1536 MB it finished in roughly a third of the time, so even at the higher per millisecond rate the total GB seconds, and the cost, fell by about 35 percent. Moving the runtime to arm64 Graviton took off another slice, and the steady baseline of the whole Lambda estate was folded into an existing Compute Savings Plan. The combined effect turned the most expensive function into a routine line item, part of a program that left the company materially lighter on cloud spend. Figures are verified against billing data and anonymised.
Frequently asked questions
How is AWS Lambda priced?
Does more Lambda memory cost more or less?
When should Lambda move to Savings Plans or containers?
Put your Lambda spend on a diet
We tune serverless estates for cost and decide when serverless or a container is cheaper, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the AWS Savings Plan kit, read the deeper AWS cost optimization guide, and compare compute models in Fargate versus EC2 on cost.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.