lambda-timeout-budget-reference

Overview

AWS Lambda's wall-clock limit is 15 minutes (900 seconds) per invocation. Per docs.aws.amazon.com/lambda: "The default value for this setting is 3 seconds, but you can adjust this in increments of 1 second up to a maximum value of 900 seconds (15 minutes)."

When to use

• Designing the timeout for a new Lambda.
• Debugging "Lambda silently truncates output" reports.
• Sizing memory for compute-bound work.
• Auditing API Gateway → Lambda → downstream timeout cascade.

The 15-minute limit

Per AWS Lambda docs: 900 seconds (15 minutes) absolute maximum. For longer work, use:

• AWS Step Functions (orchestrate multiple Lambdas)
• AWS Batch (containers; up to 14 days)
• ECS Fargate (containers; no time limit)

Don't try to architect around the 15-minute limit; pick the right service.

Timeout vs deadline at runtime

Per docs.aws.amazon.com/lambda: the Lambda Context object exposes get_remaining_time_in_millis() (Python), getRemainingTimeInMillis() (Node/JVM). Use it to break out of work proactively:

def handler(event, context):
    while not_done:
        if context.get_remaining_time_in_millis() < 5000:
            # Save progress, return early
            save_checkpoint()
            return {"status": "partial", "checkpoint": ...}
        do_work_chunk()
    return {"status": "complete"}

The 5-second cushion lets the handler return cleanly. Without it, the Lambda is force-killed at timeout and the caller gets a 504-equivalent.

Billing semantics

Per docs.aws.amazon.com/lambda:

GB-second formula: memory_GB * duration_seconds.

A 512MB Lambda running 1000ms costs: 0.5 GB * 1.0 sec * $0.0000166667/GB-s = $0.00000833

Per million invocations at 1s, 512MB: $8.34 (+ $0.20 request) = $8.54.

Init duration billing was free as of 2023; this skill cites current docs.

Memory ↔ CPU relationship

Per docs.aws.amazon.com/lambda: "The amount of CPU available to a function is proportional to the memory you allocate to it. At 1,769 MB, a function has the equivalent of one vCPU."

Up to ~1769MB, you're paying for "memory" but getting "CPU." Compute-bound workloads should size memory by CPU need, not memory need.

A 256MB Lambda has ~14% of one vCPU. A 1.769GB Lambda has 1 full vCPU. A 3.5GB Lambda has 2 vCPUs.

The cost-vs-performance sweet spot is usually at the memory class where wall-clock time stops dropping (often 1024-2048MB for typical workloads).

Integration cascade

Lambda is rarely invoked directly; the integration's timeout is often the operational ceiling:

The API Gateway 29-second hard limit is the most-encountered surprise: a Lambda configured for 60s still times out at 29s because API Gateway gives up first.

Testable behaviours

Anti-patterns

Limitations

• Lambda is hard-killed at timeout. No SIGTERM grace; the process is frozen. Plan around this.
• Init phase rules can change. AWS has changed Init billing historically; check current pricing.
• Per-region pricing varies. Above examples are us-east-1; ap-northeast-1 / eu-* differ.
• Cold-start latency adds to budget. Per cold-start-budget-reference, cold start time is billed compute time as Init phase (currently free, but counted in Init Duration).
• Workers / Edge / Vercel have different timeout models. Cloudflare Workers: 10ms CPU time on free, 50ms on paid, 30s wall-clock total. Vercel Edge Functions: 30s wall-clock max.

References

• Lambda configuration limits: docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html.
• Lambda pricing: docs.aws.amazon.com/lambda/latest/dg/lambda-pricing.html.
• AWS Lambda Powertools: docs.powertools.aws.dev/lambda/.
• Companion catalog: cold-start-budget-reference.
• Consumed by: aws-sam-local-testing, lambda-test-tools-net, serverless-framework-test-plugin, serverless-integration-test-builder.