Find oversized Lambda memory and execution time

Why this is worth a look

Lambda function pricing is based on requests and execution duration measured in GB-seconds, and duration cost depends on allocated memory. Lambda also allocates CPU power in proportion to configured memory, so a lower setting can change duration and performance. REPORT logs provide configured and maximum-used memory fields, while CloudWatch metrics provide duration and errors. Review those measurements together before selecting a setting.

Run this read-only CloudWatch Logs Insights procedure against the selected Lambda log group. It reports observed memory values in MB; use the CloudWatch time range as the review window.

Execution surface
- CloudWatch Logs Insights, using the Lambda log group selected for this review.
- Read-only filter and stats aggregation. It does not change Lambda or CloudWatch resources.
- Use a time range and function scope chosen by your team. Results describe only REPORT events in that window.

Query
filter @type = "REPORT"
| stats max(@memorySize / 1000 / 1000) as provisionedMemoryMB,
    min(@maxMemoryUsed / 1000 / 1000) as smallestMemoryRequestMB,
    avg(@maxMemoryUsed / 1000 / 1000) as avgMemoryUsedMB,
    max(@maxMemoryUsed / 1000 / 1000) as maxMemoryUsedMB,
    provisionedMemoryMB - maxMemoryUsedMB as overProvisionedMB

Review
- Treat a gap as a candidate for testing, not as a safe new setting.
- Separately review the documented Duration and Errors metrics.
- Test alternative memory values before changing the function.

How to confirm it

1. 01

   Select the review scope

   In CloudWatch Logs Insights, select the Lambda log group for the function and set the time range and function scope for your review. Treat the result as evidence from that window only. As a sampling practice, include the workload variation your team considers representative.

2. 02

   Run the memory query

   Run the command in the selected log group. It filters REPORT events and reports provisioned memory, minimum, average and maximum observed memory use, plus the difference in MB. A large gap is a test candidate, not a target.

3. 03

   Review duration and errors

   Review CloudWatch Duration and Errors separately for the same scope. Duration is measured in milliseconds and excludes cold-start time. Do not choose a new memory setting from average memory use alone.

4. 04

   Test before changing

   Test several memory allocations with production-like inputs, then compare measured duration, errors and latency. If you also evaluate arm64, check compatible code, layers and extensions, and compare its performance with x86_64 separately.

Primary sources