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, and over-provisioned memory.
| Rule ID | Scan Type | Severity | Name |
|---|---|---|---|
| CLDBRN-AWS-LAMBDA-1 | Discovery and IaC | Medium | Lambda Function Not Using Cost-Optimal Architecture |
| CLDBRN-AWS-LAMBDA-2 | Discovery | Low | Lambda Function High Error Rate |
| CLDBRN-AWS-LAMBDA-3 | Discovery | Low | Lambda Function Excessive Timeout |
| CLDBRN-AWS-LAMBDA-4 | Discovery | Medium | Lambda Function Memory Overprovisioned |
CLDBRN-AWS-LAMBDA-4 is opt-in and excluded from the default aws-core preset, because it reads AWS Compute Optimizer recommendations and Compute Optimizer has to be opted into before it returns anything. See Enabling and Disabling Rules for how to opt in.
CLDBRN-AWS-LAMBDA-1
Lambda Function Not Using Cost-Optimal Architecture
Scan type: Discovery and IaC
Severity: Medium
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
| IaC Tool | Resource Type |
|---|---|
| Terraform | aws_lambda_function |
| CloudFormation | AWS::Lambda::Function |
CLDBRN-AWS-LAMBDA-2
Lambda Function High Error Rate
Scan type: Discovery
Severity: Low
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%
Coverage
A function whose 7-day invocation total or error total is missing is reported as unknown rather than as a pass. See Live Evaluation Coverage.
How to remediate
- Check CloudWatch Logs for the function to identify the error pattern
- Common causes: missing permissions, timeout too low for the actual work, downstream service failures, malformed input
- 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
Severity: Low
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
Coverage
A function with a timeout of 30 seconds or more whose 7-day average duration is missing is reported as unknown rather than as a pass. Functions with a timeout below 30 seconds are counted as assessed, since the timeout alone settles the result without needing a duration metric. See Live Evaluation Coverage.
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
Severity: Medium
What it checks
Flags Lambda functions that AWS Compute Optimizer identifies as memory-overprovisioned. The rule applies no duration or timeout heuristic of its own. It reads Compute Optimizer's memory finding for each function and reports only the functions Compute Optimizer actually classified as overprovisioned.
Because Compute Optimizer has to be opted into before it returns recommendations, this rule is excluded from the default aws-core preset. Add CLDBRN-AWS-LAMBDA-4 to enabled-rules to run it. See Enabling and Disabling Rules.
Why it matters
Lambda charges per GB-second. A function configured with 1,024 MB that never uses more than 200 MB pays for headroom it does not use on every invocation. Compute Optimizer bases its verdict on the memory each invocation actually consumed, which is evidence a configuration review cannot produce on its own, so a finding here is a measured right-sizing opportunity.
What triggers a finding
The function's Compute Optimizer assessment is memory_overprovisioned. Findings are keyed by function ARN and carry a resourceType of lambda:function and an actionType of Rightsize.
When this rule reports a function, it supersedes the equivalent Cost Optimization Hub rightsizing finding (CLDBRN-AWS-COSTOPTIMIZATIONHUB-4) for the same function and action. See Finding Precedence.
Coverage
A function is assessed only when Compute Optimizer returned a usable memory result for it. Functions absent from the recommendation dataset, and functions Compute Optimizer returned with an unavailable assessment (insufficient or inconclusive data), are reported as unknown rather than as correctly sized. Functions with no resolvable ARN are reported as unknown as well. See Live Evaluation Coverage.
How to remediate
Apply the memory value Compute Optimizer recommends, or use AWS Lambda Power Tuning to confirm the optimum for your own cost and latency tradeoff. Lambda scales CPU with memory, so cutting memory too far can raise duration enough to increase total cost:
aws lambda update-function-configuration \
--function-name my-function \
--memory-size 512
Monitor invocation duration after the change to confirm the function still performs acceptably.
See Also
- CLI discover command — scan live Lambda functions
- CLI scan command — scan IaC templates for Lambda issues
- SDK Reference — run scans programmatically