For the complete documentation index, see llms.txt. This page is also available as Markdown.

Lambda

Learn how Rightsize finds savings on Lambda functions.

On AWS accounts, Rightsize identifies Lambda functions that cost more than they need to. It recommends a move from x86 to arm64, less provisioned concurrency, or a review of standing capacity that a function did not use. Rightsize starts from billing data, then uses CloudWatch metrics to confirm a provisioned concurrency trim.

What Rightsize Recommends

Rightsize makes three kinds of recommendation for a Lambda function:

  • Review unused standing capacity - the function is billed for provisioned concurrency or SnapStart cache, with zero billed requests and zero billed duration across at least 10 billed days. Rightsize reads this from billing data. The saving is the cost of that capacity. The finding state is Over provisioned, and Rightsize adds the reason Idle.

  • Lower provisioned concurrency - the function uses less provisioned concurrency than you pay for. Rightsize sets a target from the highest use observed across the function's qualifiers, plus Provisioned concurrency headroom. That headroom is a setting, 20% by default. See Lambda Settings, below. The provisioned concurrency configuration must be unchanged since the start of the lookback window.

  • Move to arm64 - the function ran only on x86 in the billed period, and the same work costs less on arm64. The finding state is Not optimized.

Rightsize records a function's memory use as evidence. It does not recommend a different memory size.

How Rightsize Checks a Function

Provisioned Concurrency

Rightsize reads the function's invocations, errors, throttles, provisioned concurrency utilization, and provisioned concurrency spillover invocations. It does not recommend a provisioned concurrency trim in these cases:

  • The error rate or the throttle rate is above 1%. Rightsize adds the reason Errors or throttling detected.

  • Any invocation spilled over the provisioned capacity. Rightsize adds the reason Provisioned concurrency spillover detected.

arm64 Savings

The arm64 saving is the function's x86 duration spend, multiplied by the price difference between the two architectures:

Rightsize uses your account's observed x86 and arm64 rates when the ratio between them is within 10% of the ratio between the published rates for the region. Otherwise, it uses the published rates. The panel shows which rates it used. Rightsize makes no arm64 recommendation in a region without published arm64 rates.

An arm64 saving is a price estimate, and a change of architecture can change how long a function runs.

Memory

Memory use comes from Lambda Insights. When no other recommendation applies, and the function has enough memory samples from a single memory allocation, Rightsize adds the reason Memory measured. The samples must cover at least Minimum observed days, a setting that is 7 days by default. See Lambda Settings, below.

Using the Lambda Tab

The summary metrics on the Lambda tab are Available Savings, Idle, Over provisioned, Optimized, Not Optimized, Tagged, and Untagged.

Click a row's AI Suggestion button to open the function's panel:

  • Current State - the function name, its billed architecture, billed requests, billed duration in GB-seconds, and the cost lines that apply to it. These include duration, requests, provisioned concurrency, SnapStart, and ephemeral storage costs.

  • Noros Recommendation - one of these:

    • Architecture set to arm64, with a note on which rates the estimate uses. The note ends with "Billing cannot verify runtime or dependency compatibility — review before migrating."

    • The current and recommended provisioned concurrency, for each qualifier.

    • Review unused standing capacity.

  • Monthly Savings - the estimated saving.

  • Findings - the reasons behind the recommendation, as chips.

When memory data is available, the panel shows a chart. Choose Memory used or Memory allocated to change the metric.

Lambda Settings

In Settings, open Per-service overrides and select Lambda. An empty field uses the account default.

  • Provisioned concurrency headroom - spare provisioned concurrency kept above the highest use seen, before a trim. The Balanced default is 20%.

  • Memory headroom - recorded with the function's memory evidence. It does not change a recommendation. The Balanced default is 20%.

  • Minimum observed days - the days that must contain memory samples before the peak counts as evidence. The Balanced default is 7.

These settings are separate from the account-wide CPU and memory headroom.

Lambda Finding Reasons

Rightsize lists the reasons behind each finding. Check these before you act on a recommendation, to understand what it is based on.

Reason
Meaning

Provisioned concurrency underused

The busiest observed period, with headroom, still leaves provisioned capacity unused.

Provisioned concurrency spillover detected

Invocations went past the provisioned capacity during the window, so Rightsize does not recommend a trim of that capacity.

Errors or throttling detected

The function showed errors or throttling during the window, so Rightsize does not size against that usage.

Arm64 migration candidate

A function ran only on x86 in the billed period, and the same work costs less on arm64.

Compatibility not verified

Billing records cannot confirm that a function's code and dependencies run on arm64, so the migration stays a review.

Review unused standing capacity

Rightsize recommends removing standing capacity that a function did not use.

No invocations this period

A function billed for capacity, with zero billed requests and zero billed duration across the observed period.

Memory measured

Rightsize recorded a function's observed memory use as evidence for its result.

Memory usage unavailable

Rightsize received no memory data for this function, so the recommendation does not use memory.

Memory evidence incomplete

Some memory data arrived for this function, but not enough to size against, so the recommendation does not use memory.

Idle

The function is billed for standing capacity with no invocations.

Was this helpful?