Check Lambda memory before cutting it
On this page
Cutting memory can raise duration costs, so use REPORT logs to shortlist functions and test several memory settings before changing production. Compare allocated memory and runtime together: Lambda duration is billed in GB-seconds, and a smaller setting is not automatically cheaper.
What you need first
- Tool
- CloudWatch Logs Insights is AWS's tool for querying logs in the CloudWatch console. Start with one Lambda function's log group and a chosen review time range; run each query below separately.
- Access
- Ask an authorized AWS colleague to provide the read-only log results and Errors and Invocations metrics for the selected function and time range.
- If you do not use that tool
- Send the function name, AWS account, Region, log group and review window to your Lambda owner. Request both query results below and Errors divided by Invocations for that same scope.
Why this is worth a look
A memory cut can slow the function because Lambda allocates CPU power in proportion to configured memory. Longer execution can offset the lower allocation. Functions limited by CPU, network or memory may benefit from more memory, not less. Lambda also bills per request, so a memory comparison is not a full cost estimate.
Run this check
CHECKLISTRun these read-only queries separately in CloudWatch Logs Insights for one Lambda log group and a selected time range. Memory results are in MB; duration results are in milliseconds. They do not change resources or calculate charges.
Scope
- Ask an authorized AWS colleague to run these queries if you lack access.
- Select one function's Lambda log group and record the review time range.
- Use a window with one configured memory setting and representative workload variation.
- Paste only one query at a time into CloudWatch Logs Insights.
Query 1: observed memory
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
Query 2: runtime by five-minute interval
filter @type = "REPORT"
| stats avg(@duration), max(@duration), min(@duration) by bin(5m)
Review
- Record the memory gap in MB and runtime in milliseconds.
- Request CloudWatch Errors and Invocations for the same function and window.
- Calculate error rate as Errors divided by Invocations when Invocations is nonzero.
- Mark apparent spare memory as a test candidate, not a new memory target.How to confirm it
- 01
Choose a comparable window
Select one function and a review window that includes the workload variation your team needs to support. Keep the configured memory setting constant within that window so the memory gap is interpretable.
- 02
Identify a test candidate
Run both log queries, or request the results from your Lambda owner. Use the gap between allocated and observed maximum memory to decide whether to test another setting, not to choose the setting itself.
- 03
Record the performance baseline
Compare the five-minute runtime results with the function's Errors and Invocations for the same window. Record the error rate and your team's runtime limits before testing.
- 04
Test before approving a cut
Ask the function owner to test several memory allocations with comparable inputs. Compare allocated memory and execution time together, and reject settings that breach runtime or error limits. Keep the processor architecture unchanged for this comparison; an arm64 migration needs separate code, layer and extension compatibility checks.
Before making changes
Assume one function, one configured memory setting and a representative workload in the selected window. The memory query subtracts two maxima; mixing settings can make that gap misleading. Observed maximum use is not a safe future limit. Runtime results are not a bill calculation, and these queries do not estimate request or Provisioned Concurrency charges.