AWS cost · Lambda

Lambda memory over-provisioning and the CPU trap

Lambda bills memory multiplied by time, and you choose the memory. Set it to 1024 MB because that was in the example you copied, and every invocation for the next three years is priced at 1024 MB - even if the function never touches 200.

A function at 1024 MB running 200 ms, ten million times a month, costs about $33.33 in us-east-1. Halving the memory halves that - unless it doubles the duration, which is what a CPU-bound function does.

The arithmetic, and where it stops working

The last two rows are the same change with two outcomes. Which one you get depends on what the function spends its time doing.

Memory is also the CPU dial

Lambda does not let you choose processing power separately. CPU scales with the memory setting, so the number labelled memory is really the size of the machine.

That splits functions into two kinds. One waits on a database, an API or S3. Its duration barely moves when the CPU shrinks, so cutting memory is close to a pure saving. The other computes, and cutting memory stretches it out until the GB-seconds are unchanged and the only thing that moved is your latency.

The same logic runs the other way. Raising memory on a CPU-bound function can make it cheaper, because it finishes far enough ahead to pay for the bigger machine.

Why nobody fixes this

Because the number you would need is not where you would look for it. CloudWatch publishes invocations, duration, errors and throttles for every function by default - and not memory. There is no metric to graph and no alarm to set on memory you are not using.

The figure does exist. Every invocation writes a REPORT line into the function log carrying max memory used. The evidence is in CloudWatch Logs rather than CloudWatch Metrics. Lambda Insights turns it into a proper metric, but it is opt-in per function and costs extra. On most accounts, most functions have never been measured.

How to check

# every function and the memory it is configured for
aws lambda list-functions \
  --query 'Functions[].{Name:FunctionName,MB:MemorySize,Timeout:Timeout,Runtime:Runtime}' \
  --output table

# what one actually used - the REPORT line carries max memory used
aws logs filter-log-events --log-group-name /aws/lambda/my-function \
  --filter-pattern "REPORT" --limit 20 \
  --query 'events[].message' --output text

Start with the functions that run most, not the ones whose setting looks most wrong. The waste is per invocation, so a badly sized function nobody calls is not worth recovering.

What the fix costs

Changing memory changes CPU, so the duration you were counting on is no longer the duration you have. Re-measure after every change, and compare GB-seconds rather than milliseconds - a function that got faster and more expensive is easy to ship by accident.

Leave headroom above the observed maximum. Exceeding the memory limit does not slow the function down, it kills the invocation. This is one of the few cost changes with a hard failure mode.

# MUTATING - changes CPU as well as memory; re-measure duration after
aws lambda update-function-configuration \
  --function-name my-function --memory-size 512

For where the rest of a Lambda bill goes - requests, duration, and the things that dwarf both at scale - see is Lambda expensive.

Frequently asked questions

More AWS cost breakdowns