How to choose an AWS Lambda memory size to cut cost

Lambda bills memory × billed duration. Most teams set memory once, copy it to the next function, and never look again. The setting is usually wrong in one of two directions, and both cost money.

Memory also buys CPU

Lambda allocates CPU in proportion to memory, reaching about one vCPU at 1,769 MB. A CPU-bound function at 512 MB gets a third of a core; at 1,769 MB it gets a whole one and can finish in a third of the time. Cost is memory times time, so the faster size can cost the same or less. An I/O-bound function waiting on a database does not speed up with CPU, so every extra MB is waste.

Read the REPORT lines

Every invocation ends with a line like this in CloudWatch Logs:

REPORT RequestId: 7f3a... Duration: 864.12 ms Billed Duration: 865 ms Memory Size: 1024 MB Max Memory Used: 138 MB

Max Memory Used against Memory Size tells you whether you are paying for memory you never touch. Duration percentiles tell you what a size change would do to latency. Init Duration appears only on cold starts.

Two bad settings

Far too much memory: peak use is 14% of the configured size and the function is I/O-bound. Dropping to the smallest size with headroom cuts compute cost by the same factor.
Too little: peak use is above 90% of the limit, so one larger payload ends in an out-of-memory failure, or a CPU-bound function runs three times slower than it needs to.

Model, then measure

You cannot read another size's duration from a log. The analyzer models it from the share of your duration that scales with CPU and shows the answer at 0%, your guess and 100%. If the three agree the choice is safe; if they differ, the real answer is in your code, and AWS Lambda Power Tuning will measure it by running the function at several sizes.

aws logs tail /aws/lambda/my-fn --since 1d | node cli.mjs analyze - --invocations 5000000

What this cannot see

A sample is not your traffic: the heaviest requests may be absent. List prices ignore your free tier, discounts, volume tiers, provisioned concurrency and region. Memory is also a latency and out-of-memory decision, not only a cost one.

Common questions

Does more Lambda memory always cost more?

No. You pay for memory times billed time. For CPU-bound code, doubling memory roughly halves duration, so the bill barely moves and requests finish sooner; past one vCPU (about 1,769 MB) a single-threaded function stops getting faster and the extra memory is pure cost.

How do I find my function's peak memory?

Every invocation writes a REPORT line with Max Memory Used. Take the maximum over a representative sample, including your heaviest requests, and leave headroom; the analyzer does this and warns when peak use is above 90% of the configured size.

Is arm64 really cheaper?

Lambda lists arm64 at about 20% less per GB-second than x86_64, and many functions run at similar speed, but native dependencies and some runtimes differ. Measure duration on arm64 before assuming the saving.