Lambda functions whose peak memory use stays under half of configured memory
What does ZopNight detect here?
ZopNight reads each Lambda function's `Max Memory Used` from its invocation REPORT log lines over 30 days and flags functions peaking below 50% of configured memory. It recommends the next 128 MB step above peak plus 64 MB, and prices the saving on the duration part of the bill only, since request charges do not change with memory.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-050 |
| Category | rightsizing |
| Severity | low |
| Metric | Max Memory Used |
| Threshold | peak < 50% of configured memory |
| Evaluation window | 30d |
| Source | ZopNight |
| Permissions used | lambda:ListFunctions · logs:StartQuery · logs:GetQueryResults |
Where it applies
Lambda charges for memory by the millisecond
Lambda pricing has two parts: requests, and duration measured in GB-seconds, the configured memory times the run time. The price data for US East (N. Virginia) on x86 lists $0.0000166667 per GB-second and $0.20 per million requests. Memory is set between 128 MB and 10,240 MB in 1 MB steps, and a function configured at 2,048 MB pays four times the duration rate of one at 512 MB for the same run time.
Memory also sets CPU: Lambda allocates CPU in proportion to memory, with 1,769 MB equal to one vCPU. That is why lowering memory is not always a saving. A function that is short of CPU runs longer on less memory.
Reading peak memory from the REPORT lines
Every invocation ends with a REPORT line that includes Memory Size and Max Memory Used. Logs
Insights can summarise them:
aws logs start-query --log-group-name /aws/lambda/my-fn \ --start-time 1756166400 --end-time 1758758400 \ --query-string 'filter @type = "REPORT" | stats max(@maxMemoryUsed / 1000 / 1000) as peakMB, max(@memorySize / 1000 / 1000) as configuredMB'
aws logs get-query-results --query-id QUERY_IDWhen a function is flagged
- ZopNight has a 30-day peak for
Max Memory Usedand the configured memory for the function. - The peak is under 50% of configured memory.
- The duration (GB-second) part of the function’s cost is known and above zero.
- A smaller memory setting exists: the peak plus 64 MB of headroom, rounded up to the next 128 MB step, must be below the current setting.
Functions the rule passes over
Functions with no REPORT-line data, functions using half or more of their memory, and functions with no measured duration cost are skipped. A function that is never invoked is a different problem, covered by Idle Lambda Function. ZopNight does not apply this change for you: because CPU scales with memory, the new duration cannot be predicted from memory alone.
Scaling only the duration charge
new memory = peak MB + 64 MB, rounded up to the next 128 MB stepsaving = monthly GB-second cost x (1 - new memory / current memory)capped at the function's total monthly costA function peaking at 300 MB on a 1,024 MB setting would move to 384 MB, cutting the duration charge by 62.5% if run time holds. Request charges are left out, since they do not change.
Lowering a function’s memory
- Test the new setting on a copy or alias under realistic load. The open-source AWS Lambda Power Tuning tool runs a function at several memory sizes and reports cost and speed.
- Apply it:
aws lambda update-function-configuration --function-name my-fn --memory-size 384 - Compare duration and errors for a few days; raise memory again if duration climbs.