patternjavascriptModerate
Lambda cold starts spike latency for infrequently invoked functions
Viewed 0 times
cold startlambda latencyprovisioned concurrencywarm startexecution environmentinitializationarm64 graviton
aws-lambda
Problem
Lambda functions invoked infrequently experience cold start latency (100ms-2s+) as AWS must bootstrap a new execution environment, initialize the runtime, and load the function code. This is user-visible as intermittent slow responses.
Solution
Move initialization code outside the handler. Use Provisioned Concurrency for latency-sensitive functions. Minimize package size and use arm64 (Graviton) which has lower cold start times. For Node.js, avoid heavy framework imports at cold start.
```javascript
// BAD: initialized inside handler
exports.handler = async (event) => {
const db = new DynamoDBClient(); // cold start every time if env recycles
};
// GOOD: initialized outside handler (reused across warm invocations)
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
const db = new DynamoDBClient({ region: process.env.AWS_REGION });
export const handler = async (event) => {
// db is already initialized
};
```javascript
// BAD: initialized inside handler
exports.handler = async (event) => {
const db = new DynamoDBClient(); // cold start every time if env recycles
};
// GOOD: initialized outside handler (reused across warm invocations)
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
const db = new DynamoDBClient({ region: process.env.AWS_REGION });
export const handler = async (event) => {
// db is already initialized
};
Why
Code outside the handler runs once per execution environment initialization (cold start) and is reused across warm invocations. Keeping connections and clients outside the handler amortizes their cost across many requests.
Gotchas
- Provisioned Concurrency costs money even when idle — use Application Auto Scaling to schedule it only during peak hours
- Lambda SnapStart (Java) takes a snapshot after initialization — not available for Node.js/Python natively
- Bundling with esbuild/webpack reduces cold start by shrinking package size — avoid node_modules being zipped wholesale
- arm64 (Graviton2) has ~34% price/performance improvement over x86 and typically faster cold starts
- VPC-attached Lambdas no longer have longer cold starts since AWS ENI pre-provisioning was introduced (2019)
Code Snippets
Client initialization outside handler for warm reuse
// Initialize clients outside handler — reused across warm invocations
import { DynamoDBDocumentClient } from '@aws-sdk/lib-dynamodb';
import { DynamoDBClient } from '@aws-sdk/client-dynamodb';
const dynamo = DynamoDBDocumentClient.from(
new DynamoDBClient({ region: process.env.AWS_REGION })
);
export const handler = async (event) => {
// dynamo is warm on subsequent calls
};Context
Building latency-sensitive APIs on AWS Lambda
Revisions (0)
No revisions yet.