serverless-integration-test-builder

Overview

Per aws.amazon.com/blogs/compute on cold starts (opens in new window), Lambda's cold start has three phases:

1. Init - download deployment package, unzip, bootstrap the runtime (Node/Python/Java/etc.).
2. Init code - execute module-level imports + global setup.
3. Invoke - the actual handler call.

Phases 1 + 2 are the "cold" part. Phase 3 is what runs every invocation (cold or warm).

When to read this

• Designing a latency budget for a Lambda / Workers / Edge function.
• Investigating "p95 is fine but p99 is 5s."
• Choosing a runtime - Cloudflare's isolate model is qualitatively different from Lambda containers.
• Auditing provisioned-concurrency / SnapStart configurations.

How to use

1. Look up the runtime's typical range in the per-runtime budget table (e.g. Node.js 256MB is 200-700ms; Java 11 without SnapStart is 1.5-6s).
2. Set the latency budget as two lines: p50/p95 tracks warm performance, and a separate p99 line absorbs the cold-start tail.
3. Force a cold start (deploy, or wait past the idle-evict window) and record p95 first-invocation latency against the budget.
4. If cold starts breach budget, apply the matching mitigation from below: SnapStart (JVM/.NET), provisioned concurrency, package-size trimming, lazy imports, or a pre-compiled runtime (Go/Rust).
5. Add the build-step and monitoring assertions from Testable behaviours (zipped artifact < 50MB, init phase < 500ms, CloudWatch Init Duration).
6. Re-measure after each change and confirm the p99 tail moved, not just p50/p95.

Per-runtime cold-start budgets

Per AWS, Cloudflare, Vercel docs (typical ranges; bigger packages and bigger memory-class skew higher):

The "Workers / Edge" qualitative leap is the isolate model: each function is a V8 isolate, spun up in microseconds per developers.cloudflare.com (opens in new window) - no container, no OS startup.

Mitigations

Provisioned concurrency (AWS Lambda)

Per docs.aws.amazon.com/lambda (opens in new window): keeps N execution environments pre-initialised. Eliminates cold starts up to N concurrent requests; you pay for the keep-warm time.

Trade-off: cost. A constant N=10 provisioned concurrency for 30 days ≈ $30-300 depending on memory class.

Lambda SnapStart (Java / .NET)

Per docs.aws.amazon.com/lambda/latest/dg/snapstart.html (opens in new window): takes a snapshot of the initialised JVM and restores from it on each cold start. Reduces Java cold starts from 1.5-6s → 100-300ms.

Caveats:

• State snapshot includes connections, random seeds; can't have per-instance unique values frozen.
• Hooks beforeCheckpoint / afterRestore let you re-prime non-serializable state.

Package-size discipline

Lambda cold-start scales with deployment-package size. Per AWS: keep under 50MB (zipped) → cold start in the 200-800ms range. Larger packages → seconds.

Avoid heavy module-level imports

Init code runs once but on every cold start. Heavy imports (database connection pool init, large dependency trees) inflate init time.

# Bad: top-level
import heavy_lib            # 2s import time
def handler(event, ctx):
    return heavy_lib.do_thing(event)

# Better: lazy-import
def handler(event, ctx):
    import heavy_lib
    return heavy_lib.do_thing(event)

Lazy imports add per-warm-call latency but reduce cold-start spike.

Runtime choice

Pre-compiled runtimes (Go, Rust) have far lower cold starts than managed runtimes (Java, Python). For latency-critical paths, runtime choice is a primary lever.

Timeout budgets

Cold start is the front of the latency budget; the back is the timeout. Lambda's 15-minute hard limit, the getRemainingTimeInMillis early-return pattern, per-ms billing and the memory-CPU relationship, and the integration timeout cascade (API Gateway's hard 29s, SQS visibility timeouts, Lambda@Edge limits) are cataloged in timeout-budgets.md (opens in new window).

Testable behaviours

Worked example

A Java 11 Lambda (512MB) serves a low-traffic checkout callback. Users report occasional multi-second waits, though the dashboard p95 looks healthy.

1. The per-runtime table puts Java 11 without SnapStart at 1.5-6s cold start; p95 hides it because cold starts land in the p99 tail.
2. Enable SnapStart, which snapshot-restores the initialised JVM and drops the cold start to the 100-300ms range.
3. Re-prime non-serializable state in an afterRestore hook so a stale pooled DB connection is not frozen into the snapshot.
4. Force a cold start (wait past idle-evict) and compare Init Duration before and after; confirm the p99 line, not just p95, falls.

Result: the cold-start tail drops from ~5s to the 100-300ms range with no provisioned-concurrency spend.

Anti-patterns

Limitations

• Cold-start measurement is platform-side. CloudWatch Init Duration metric is canonical for Lambda; Workers / Edge expose their own.
• SnapStart caveats are subtle. State that survives the snapshot may be wrong (random seeds, connection state).
• Provisioned-concurrency is regional. Multi-region Lambdas need PC per region.
• Workers / Edge are not free of all variance. First request per (script, region) still has 5-30ms init.
• Doesn't address steady-state throughput. Cold start is one metric; concurrency-limit + duration are separate.

References

• AWS Lambda cold-start blog: aws.amazon.com/blogs/compute (opens in new window).
• Lambda SnapStart: docs.aws.amazon.com/lambda/latest/dg/snapstart.html (opens in new window).
• Cloudflare Workers isolate model: developers.cloudflare.com/workers/reference/how-workers-works (opens in new window).
• Vercel Edge Runtime: vercel.com/docs/functions/edge-runtime (opens in new window).
• Timeout + billing budgets: timeout-budgets.md (opens in new window).
• Used by: the main skill, aws-sam-local-testing, cloudflare-workers-miniflare, azure-functions-tests.

AWS Lambda's wall-clock limit is 15 minutes (900 seconds) per invocation. Per docs.aws.amazon.com/lambda configuration-timeout (opens in new window): "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)." For longer work use Step Functions, AWS Batch, or ECS Fargate - don't architect around the limit.

Timeout vs deadline at runtime

Per docs.aws.amazon.com/lambda python-context (opens in new window), the Context object exposes get_remaining_time_in_millis() (Python) / getRemainingTimeInMillis() (Node/JVM). Break out proactively:

def handler(event, context):
    while not_done:
        if context.get_remaining_time_in_millis() < 5000:
            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 (no SIGTERM grace) and the caller gets a 504-equivalent.

Billing semantics

Per docs.aws.amazon.com/lambda lambda-pricing (opens in new window):

GB-second formula: memory_GB * duration_seconds. A 512MB Lambda running 1000ms costs 0.5 * 1.0 * $0.0000166667 = $0.00000833; per million 1s invocations at 512MB: ~$8.54 including the request charge.

Memory ↔ CPU relationship

Per docs.aws.amazon.com/lambda configuration-memory (opens in new window): "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." Compute-bound workloads should size memory by CPU need; the sweet spot is usually the memory class where wall-clock time stops dropping (often 1024-2048MB).

Integration timeout cascade

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

Notes

• Per-region pricing varies; the figures above are us-east-1.
• Workers / Edge have different models: Cloudflare Workers 10ms CPU free / 50ms paid, 30s wall-clock; Vercel Edge Functions 30s wall-clock max.

References

• Lambda configuration limits: docs.aws.amazon.com/lambda/latest/dg/configuration-function-common.html (opens in new window)
• Lambda pricing: docs.aws.amazon.com/lambda/latest/dg/lambda-pricing.html (opens in new window)
• AWS Lambda Powertools: docs.powertools.aws.dev/lambda/ (opens in new window)