Lambda Rules

These rules identify Lambda functions with cost-impacting configurations: non-Graviton architecture, high error rates that waste invocation spend, excessive timeouts that inflate billed duration, over-provisioned memory, and unnecessary provisioned concurrency charges.

CLDBRN-AWS-LAMBDA-1

Lambda Function Not Using Cost-Optimal Architecture

Scan type: Discovery and IaC

What it checks

Flags Lambda functions not configured to run on the arm64 (Graviton2) architecture. Lambda on arm64 is approximately 20% cheaper per GB-second than the equivalent x86_64 configuration, and Graviton2 often executes functions faster, compounding the savings.

Why it matters

Lambda pricing is based on the number of requests and GB-seconds of compute. For functions that run frequently or with significant memory allocation, the 20% price reduction from arm64 adds up quickly. A function running 10 million invocations per month at 512 MB for 500ms costs roughly $8.35 on x86_64 vs $6.68 on arm64 — the saving grows proportionally with scale.

What triggers a finding

The function's architectures list does not include arm64.

How to remediate

Set the function architecture to arm64. Most Lambda runtimes support arm64 natively (Node.js, Python, Java, Go, .NET). Custom runtimes need to provide an arm64-compatible binary.

aws lambda update-function-configuration \
  --function-name my-function \
  --architectures arm64

After changing the architecture, test the function to confirm it behaves correctly. Graviton2 uses a different CPU architecture — if you have native binaries compiled for x86, you need to recompile them for arm64.

IaC resources checked

CLDBRN-AWS-LAMBDA-2

Lambda Function High Error Rate

Scan type: Discovery

What it checks

Flags Lambda functions whose error rate exceeds 10% over the past 7 days. A high error rate means you're paying for invocations that fail to produce useful results.

Why it matters

Every Lambda invocation costs money, whether it succeeds or not. A function with a 30% error rate is burning almost a third of its invocation budget on failures. Beyond the direct cost, high error rates often trigger retries (from SQS, API Gateway, or Step Functions), which compound the spend further.

What triggers a finding

Both conditions must be true:

• The function had at least one invocation in the past 7 days
• The error rate (totalErrorsLast7Days / totalInvocationsLast7Days) exceeds 10%

How to remediate

1. Check CloudWatch Logs for the function to identify the error pattern
2. Common causes: missing permissions, timeout too low for the actual work, downstream service failures, malformed input
3. Fix the root cause rather than suppressing errors. If errors are expected for a subset of invocations (e.g., input validation), handle them gracefully without throwing so they don't count as invocation failures

CLDBRN-AWS-LAMBDA-3

Lambda Function Excessive Timeout

Scan type: Discovery

What it checks

Flags Lambda functions whose configured timeout is at least 30 seconds and at least 5x their average observed duration over the past 7 days. An excessively high timeout relative to actual execution time means that when the function does hang, it burns through compute budget for far longer than necessary before failing.

Why it matters

Lambda bills by the millisecond. When a function hangs (cold start spike, downstream timeout, deadlock), it runs until the configured timeout. A function that averages 2 seconds but has a 900-second timeout will burn 450x its normal cost on a single hanging invocation. Right-sizing the timeout to a reasonable multiple of observed duration limits the blast radius of failures.

What triggers a finding

All three conditions must be true:

• The function's configured timeout is at least 30 seconds
• The function's average duration over the past 7 days is greater than 0
• The configured timeout is at least 5x the average duration

How to remediate

Lower the timeout to a value closer to actual execution time plus a reasonable buffer:

aws lambda update-function-configuration \
  --function-name my-function \
  --timeout 15

A good starting point is 3x the p99 duration. This gives room for occasional slowdowns while limiting the cost of genuine hangs. Monitor the function after the change to confirm no legitimate invocations are timing out.

CLDBRN-AWS-LAMBDA-4

Lambda Function Memory Overprovisioned

Scan type: Discovery

What it checks

Flags Lambda functions above 256 MB whose observed 7-day average duration uses less than 30% of the configured timeout, suggesting the function completes well before its timeout and may have more memory than needed.

Why it matters

Lambda charges per GB-second. A function configured with 1,024 MB that consistently finishes in 200ms of a 30-second timeout is paying for memory headroom it does not use. Right-sizing memory allocation reduces cost directly. Tools like AWS Lambda Power Tuning can identify the optimal memory setting.

What triggers a finding

All three conditions must be true:

• memorySizeMb is greater than 256
• totalInvocationsLast7Days is greater than 0
• averageDurationMsLast7Days is less than timeoutSeconds * 1000 * 0.3

How to remediate

Use AWS Lambda Power Tuning to find the optimal memory setting. Reduce memory allocation to match actual needs. Monitor invocation duration after the change to ensure the function still performs acceptably.

CLDBRN-AWS-LAMBDA-5

Lambda Provisioned Concurrency Configured

Scan type: IaC

What it checks

Flags Lambda functions with explicit provisioned concurrency configuration. Provisioned concurrency keeps function instances warm but incurs charges whether or not the instances handle requests.

Why it matters

Provisioned concurrency costs approximately $0.0000041667 per GB-second, charged continuously regardless of invocations. For a 512 MB function with 10 provisioned instances, that's roughly $55/month. Unless the function requires consistently low cold-start latency for a steady request stream, on-demand concurrency is more cost-effective.

What triggers a finding

provisionedConcurrentExecutions is not null AND is greater than 0.

How to remediate

Review whether the function's traffic pattern justifies provisioned concurrency. If cold starts are acceptable or traffic is bursty, remove the provisioned concurrency configuration. For functions behind API Gateway, consider using SnapStart (Java) or reducing the function package size to minimize cold-start duration instead.

IaC resources checked

See Also

• CLI discover command — scan live Lambda functions
• CLI scan command — scan IaC templates for Lambda issues
• SDK Reference — run scans programmatically