How to Use CloudWatch Metrics to Lower AWS Lambda Costs

CloudWatch can show which AWS Lambda functions run often, take longer than expected, or use provisioned capacity unevenly. Those signals help you find candidates for cost review, but standard Lambda metrics are not a bill: memory use and billed duration for individual invocations come from logs, while actual charges should be checked in AWS billing data.

Start by comparing invocation volume and duration, inspect per-invocation logs for billed duration and memory, then test one change against representative traffic. Use cost data to confirm the bill changed and performance data to make sure the service still meets its needs.

Which Lambda signals help explain cost?

Lambda publishes its standard function metrics in the AWS/Lambda namespace. These are aggregated time series emitted at one-minute intervals. The Lambda metrics overview and metric reference describe their timing, definitions, and statistics.

Signal	Useful view	What it can tell you
Invocations	Sum	How many times Lambda ran your function code. Throttled requests are counted separately and are not included in Invocations.
Errors and Throttles	Sum	Whether function errors or capacity limits are affecting work. Retries depend on the invocation source and its configuration.
Duration	Average plus a percentile such as p95	How long the function code takes to process events. It excludes cold-start initialization, so it is not the same as billed duration.
ConcurrentExecutions	Maximum	How many invocations were active at once. This helps explain capacity and bursts; by itself, it does not show cost or prove that concurrency should be reduced.

For metric definitions, dimensions, and trigger-specific signals, see our guide to AWS Lambda metrics. Check the function, version, alias, or event-source mapping dimension that matches your question; a function-name graph can combine multiple versions. Also allow for publication delay: long invocations can appear in CloudWatch several minutes after they started.

Keep metric, log, and Insights data separate

MemoryUsed and InitDuration are not standard AWS/Lambda metrics. Lambda's REPORT log records fields such as Billed Duration, Memory Size, Max Memory Used, and, when applicable, Init Duration. In CloudWatch Logs Insights, those fields are available as @billedDuration, @memorySize, @maxMemoryUsed, and @duration; see AWS's guide to viewing Lambda logs and REPORT fields.

Duration measures handler processing and excludes initialization. AWS standardized billing for initialization across Lambda configurations effective August 1, 2025; for on-demand functions using managed runtimes and ZIP packages, the change made initialization part of billed duration. See the AWS announcement about INIT billing. Lambda duration is rounded up to the nearest millisecond for billing. Use Billed Duration from the log when investigating billable time, and check current Lambda pricing for the function's Region and configuration. Provisioned concurrency also has a separate capacity charge while enabled.

Memory and initialization can also be inspected with CloudWatch Lambda Insights. It is an additional extension that publishes telemetry in the separate LambdaInsights namespace; it must be enabled, and its logs and metrics add CloudWatch usage. Our Lambda Insights guide covers its metrics, setup, and cost considerations. The standard AWS/Lambda metrics remain useful without Insights.

Build a dashboard for investigation

A focused dashboard helps you see changes in demand and function behavior together. In CloudWatch, open Metrics, choose AWS/Lambda, then select metrics for the function or version you want to inspect:

1. Graph Invocations, Errors, and Throttles with Sum over the same period.
2. Graph Duration as an average and a latency percentile, such as p95. Use a period that gives enough observations to make the percentile useful.
3. Add ConcurrentExecutions with Maximum to see bursts. If provisioned concurrency is configured, add its utilization and spillover metrics and compare them with traffic and the latency objective.
4. Use the same time range and dimensions when comparing a deployment or configuration change. Keep the version or alias visible so that a change in traffic mix does not look like a code improvement.

This view helps answer questions such as “Did invocation volume or execution time rise?” It cannot show memory used for each invocation or calculate the function's bill. Use logs and billing data for those checks.

Inspect billed duration and memory in logs

Open the function's CloudWatch log group and run a Logs Insights query over the period you are investigating. This example assumes standard text REPORT records with Lambda's discovered @ fields. If your function uses structured JSON system logs, query the platform.report event and its record.metrics fields instead; AWS documents that event shape in the Lambda Logs API guide.

filter @type = "REPORT"
| fields @timestamp, @requestId, @duration, @billedDuration,
         @memorySize, @maxMemoryUsed
| sort @timestamp desc
| limit 100

Compare @duration with @billedDuration to find invocations where billing time is higher than handler time, including cold-start initialization where reported. Compare @maxMemoryUsed with @memorySize to identify functions that may be worth testing at another memory setting. Treat a maximum as a screening signal, not proof that a lower setting will work; for example, AWS notes that Node.js can report the maximum across invocations that share an execution environment in its Node.js logging reference. Logs Insights charges can depend on data scanned, so choose the smallest useful time range and log group; check CloudWatch pricing before adding ongoing queries.

Turn a metric change into a cost test

Test memory settings with representative work

Lambda charges for requests and execution duration, with duration cost affected by the memory configured for the function. Memory also controls CPU power: increasing it can shorten work for CPU-bound functions, while lowering it can extend execution time or cause memory pressure. AWS explains this relationship in its memory configuration guide.

Use Max Memory Used to spot candidates, then test a small set of memory settings with representative payloads and traffic. Compare billed duration, request count, error rate, and latency percentiles for each setting. A smaller allocation does not guarantee a lower bill: if it makes the function run longer, the added duration can offset the lower per-millisecond rate. Keep the setting that meets the workload's performance needs at an acceptable measured cost.

Investigate volume, errors, and retries

A rise in Invocations can explain higher request and execution charges, but it does not show whether each invocation was needed. Check the event source, application logs, batch settings, filtering rules, and retry behavior before changing the design. A failed invocation still consumes resources, and a source may retry it; the retry rules differ for asynchronous invocation, queues, and stream mappings.

Use Errors to find failed function executions and Throttles to find rejected requests. Follow the relevant source's retry and redrive configuration before responding to either metric. Reducing a concurrency limit to lower cost can turn work into throttles, backlog, or retries, so check the effect on completed work and end-to-end latency as well.

Review provisioned capacity separately

Concurrency is a measure of simultaneous work, not a direct measure of spend. Reserved concurrency sets aside capacity and caps a function's concurrency; it does not pre-initialize environments. Provisioned concurrency keeps environments initialized for a configured version or alias and adds capacity charges, along with request and execution charges when the function runs. Compare ProvisionedConcurrencyUtilization and ProvisionedConcurrencySpilloverInvocations with traffic and latency objectives before changing an allocation. AWS documents the metrics in its Lambda concurrency guide.

Confirm the result in billing data

Metrics and logs help explain why usage changed; AWS billing data shows what was charged. Compare equivalent periods in Cost Explorer or a Cost and Usage Report, grouping Lambda usage as needed. Keep Region, architecture, request volume, provisioned capacity, and the AWS pricing model in view. Costs can also include CloudWatch log ingestion, retention, queries, or Lambda Insights telemetry.

When costs are shared across functions or teams, define how the bill should be attributed before drawing conclusions from a dashboard. Our guide to allocating serverless costs explains what tags can identify and where shared charges need a separate allocation rule. Verify any optimization against the actual billing period; an operational metric is evidence of a possible cost driver, not proof of savings.

A practical Lambda cost workflow

1. Use AWS/Lambda metrics to identify changes in invocation volume, duration, errors, throttles, and concurrency.
2. Use REPORT logs for billed duration, and logs or Lambda Insights for memory and initialization details.
3. Test one code or configuration change under representative conditions while tracking errors and latency.
4. Check Cost Explorer or cost and usage data to confirm the bill changed, and include monitoring charges in the comparison.

Keep a change only when the billing data supports the cost improvement and the function still meets its performance and reliability requirements.