Lambda pricing is simple to state and easy to misjudge in practice: you pay for memory allocated multiplied by execution duration, rounded up to the nearest millisecond. Most teams set memory once — often by copying a number from a tutorial or bumping it during an incident — and never revisit it once the function is stable.
Memory and CPU are the same dial
Lambda allocates CPU proportionally to memory. That means the instinct to leave memory high "to be safe" isn't free insurance — it's a direct multiplier on cost per invocation, whether or not the function ever approaches that ceiling. A function that peaks at a few hundred megabytes but is configured for far more is paying for capacity it structurally cannot use.
Allocated memory (full bar) vs. what the function actually peaked at (filled portion) across three CloudWatch Insights profiles.
The inverse mistake shows up too, just less often: a function configured too low that spends more wall-clock time per invocation because it has less CPU, which can end up costing more overall than a higher memory setting that finishes faster. Right-sizing runs in both directions — the only way to find the actual minimum is to measure it.
Finding the right number
- CloudWatch Insights'
REPORTlines showMax Memory Usedper invocation — pull the p99 across a representative window, not a single cold-start run. - AWS Lambda Power Tuning (the open-source Step Functions state machine) runs a function at several memory settings and plots cost vs. duration, which is the fastest way to find the actual knee in the curve rather than guessing.
- Set memory a reasonable margin above the measured peak, not the configured ceiling — leave room for legitimate data-size variance, not for "just in case."
Two related charges worth checking at the same time
Timeout set far above actual duration. Timeout doesn't cost anything by itself, but it's often a signal that memory and duration were never tuned together — a function with a 30-second timeout that finishes in 400ms was configured for a worst case that may not reflect reality anymore.
Provisioned concurrency left on outside business hours. Provisioned concurrency bills for the concurrency reserved whether or not it's invoked. If it was turned on for a launch or a load test and never revisited, it's billing 24/7 for capacity that may only be needed during a narrow traffic window — Application Auto Scaling can schedule it down instead of leaving a static number in place.