> For the complete documentation index, see [llms.txt](https://docs.north.cloud/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.north.cloud/docs/features/rightsize/lambda.md).

# 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](/docs/features/rightsize/lambda.md#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:

```
arm64 saving = x86 duration spend × (1 − arm64 rate ÷ x86 rate)
```

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](/docs/features/rightsize/lambda.md#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.                                                          |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.north.cloud/docs/features/rightsize/lambda.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
