AWS Lambda cold starts: causes and fixes

#aws #serverless #devops #lambda

AWS Lambda cold starts: causes and how to fix them

What happens on a cold start

Cold: Download image → Start runtime → Init code → Execute handler
Warm: Execute handler only

Cold starts only happen when there's no warm container available.

Cold start times by runtime

Go:         50-200ms
Node.js:    100-300ms
Python:     100-400ms
Java (JVM): 1000-4000ms  ← painful outlier

Fixes ranked by ROI

1. Slim the container image (biggest ROI)

FROM node:18 AS builder
WORKDIR /app; COPY package*.json ./; RUN npm ci --production

FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .; CMD ["node", "handler.js"]

Large image (~1GB) → 3-8s cold start. Slimmed (~100MB) → 0.5-2s.

2. Move heavy init outside the handler

# Good: runs once per container lifetime
db = create_connection_pool()

def handler(event, context):
    return process(event, db)  # db already exists

3. Java SnapStart (reduces 2-4s to 100-200ms)

resource "aws_lambda_function" "api" {
  runtime = "java21"
  snap_start { apply_on = "PublishedVersions" }
}

4. Provisioned concurrency (last resort)

resource "aws_lambda_provisioned_concurrency_config" "api" {
  function_name = aws_lambda_function.api.function_name
  qualifier     = aws_lambda_alias.live.name
  provisioned_concurrent_executions = 2  # ~$11/month
}