AWS Lambda Cold Start Optimization in 2026: SnapStart, Graviton, and Provisioned Concurrency

A Lambda cold start is the latency penalty when AWS initializes a new execution environment: downloading your deployment package, starting the runtime, and running your initialization code. For Node.js it's typically 200–800ms. For Java with Spring Boot it can be 5–15 seconds. That's a multi-second delay on the first request after any quiet period—unacceptable for user-facing APIs.

In 2026, you have better tools than before: SnapStart for Java eliminates cold starts almost entirely, Graviton3 processors give Node.js 15–20% faster cold starts at lower cost, and proper bundling can cut package initialization time in half. This post covers every optimization tier.

---

Measuring Cold Starts

Before optimizing, measure. Lambda logs initDuration for cold starts:

// Lambda handler — measure your own init time
const INIT_TIME = Date.now();
let isWarmStart = false;

// Module-level initialization (runs on cold start)
const db = initDatabase();
const secrets = await loadSecrets();
console.log(JSON.stringify({
  type: "lambda_init",
  initDurationMs: Date.now() - INIT_TIME,
}));

export const handler = async (event: any) => {
  const requestStart = Date.now();

  if (!isWarmStart) {
    isWarmStart = true;
    // First invocation on this container — measure from init
    console.log(JSON.stringify({
      type: "cold_start",
      totalMs: Date.now() - INIT_TIME,
    }));
  }

  // Handle request...
};

# CloudWatch Insights query — p99 cold start duration
filter @type = "REPORT" and @initDuration > 0
| stats
    count() as coldStarts,
    avg(@initDuration) as avgInitMs,
    pct(@initDuration, 95) as p95InitMs,
    pct(@initDuration, 99) as p99InitMs,
    max(@initDuration) as maxInitMs
| sort p99InitMs desc

---

Tier 1: Bundling Optimization (Free, Do This First)

The single biggest cold start factor for Node.js is package size. Smaller bundle = faster download + faster Node.js module parsing.

Use esbuild for tree-shaking

// scripts/build-lambda.ts
import { build } from "esbuild";
import { readdirSync } from "fs";

const handlers = readdirSync("./src/handlers").filter((f) => f.endsWith(".ts"));

await build({
  entryPoints: handlers.map((h) => `./src/handlers/${h}`),
  bundle: true,
  platform: "node",
  target: "node22",
  format: "esm",
  outdir: "./dist",
  
  // Tree-shake — only bundle code that's actually used
  treeShaking: true,
  
  // Mark AWS SDK as external (provided by Lambda runtime)
  external: ["@aws-sdk/*"],
  
  // Minify for smaller bundle
  minify: process.env.NODE_ENV === "production",
  
  // Source maps for debugging
  sourcemap: "linked",
  
  // Split chunks for shared code
  splitting: true,
});

Bundle size impact:

Exclude heavy packages:

// ❌ These add megabytes to your bundle — avoid in Lambda
import moment from "moment";    // 67KB — use Intl instead
import lodash from "lodash";    // 70KB — use native or specific imports
import puppeteer from "puppeteer"; // 300MB — use Lambda Layer or separate function

// ✅ Use runtime-provided or lighter alternatives
const formatted = new Intl.DateTimeFormat("en-US").format(date);

---

Tier 2: Graviton3 Processors

Switching from x86_64 to arm64 (Graviton3) gives:

• 15–20% faster cold starts for Node.js and Python
• 20% lower cost (arm64 is cheaper per GB-second)
• Same code — no changes required for Node.js/Python

# Terraform — switch to arm64
resource "aws_lambda_function" "api" {
  function_name = "${var.name}-${var.environment}-api"
  runtime       = "nodejs22.x"
  handler       = "dist/handler.handler"
  
  # Graviton3 — faster cold starts, lower cost
  architectures = ["arm64"]
  
  memory_size = 1024  # More memory = more CPU allocation = faster init
  timeout     = 30
  
  # ... rest of config
}

Memory sizing for cold start performance:

For most APIs: 1024MB arm64 is the sweet spot — fast enough, reasonable cost.

---

Tier 3: Lambda SnapStart (Java Only)

SnapStart is transformative for Java Lambdas. It takes a snapshot of the initialized execution environment and restores it on invocation—eliminating the JVM startup cost entirely.

resource "aws_lambda_function" "java_api" {
  function_name = "${var.name}-java-api"
  runtime       = "java21"
  handler       = "com.viprasol.Handler::handleRequest"
  architectures = ["arm64"]
  memory_size   = 1024

  snap_start {
    apply_on = "PublishedVersions"  # SnapStart requires versioning
  }
}

# SnapStart requires publishing a version
resource "aws_lambda_alias" "live" {
  name             = "live"
  function_name    = aws_lambda_function.java_api.function_name
  function_version = aws_lambda_function.java_api.version
}

Java cold start comparison:

SnapStart caveats:

• Only works on published versions (not $LATEST)
• Unique ID generation (UUID.randomUUID()) must be called inside the handler, not in the snapshot phase
• Network connections established during init are restored but may be stale — reconnect on first use

// Restore hooks: handle stale state after snapshot restore
@RegisterReflectionForBinding
public class Handler implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent>,
    CRaC.Resource {

  private DatabaseConnection db;

  public Handler() {
    // This runs at snapshot time
    Core.getGlobalContext().register(this);
    this.db = connectToDatabase();
  }

  @Override
  public void beforeCheckpoint(CRaC.Context<? extends CRaC.Resource> context) {
    // Close resources before snapshot
    db.close();
  }

  @Override
  public void afterRestore(CRaC.Context<? extends CRaC.Resource> context) {
    // Reconnect after restore from snapshot
    this.db = connectToDatabase();
  }
}

---

Tier 4: Provisioned Concurrency

Provisioned concurrency keeps N Lambda instances initialized and warm at all times—zero cold starts for those instances. Use for P99 SLA requirements.

# Auto-scaling provisioned concurrency — scales with traffic
resource "aws_appautoscaling_target" "lambda" {
  max_capacity       = 50
  min_capacity       = 2
  resource_id        = "function:${aws_lambda_function.api.function_name}:${aws_lambda_alias.live.name}"
  scalable_dimension = "lambda:function:ProvisionedConcurrency"
  service_namespace  = "lambda"
}

resource "aws_appautoscaling_policy" "lambda_scale" {
  name               = "${var.name}-lambda-concurrency"
  policy_type        = "TargetTrackingScaling"
  resource_id        = aws_appautoscaling_target.lambda.resource_id
  scalable_dimension = aws_appautoscaling_target.lambda.scalable_dimension
  service_namespace  = aws_appautoscaling_target.lambda.service_namespace

  target_tracking_scaling_policy_configuration {
    target_value = 0.6  # Scale when 60% of provisioned concurrency is used
    predefined_metric_specification {
      predefined_metric_type = "LambdaProvisionedConcurrencyUtilization"
    }
    scale_in_cooldown  = 300
    scale_out_cooldown = 60
  }
}

Scheduled scaling for predictable traffic (cheaper than always-on):

# Scale up before business hours, down after
resource "aws_appautoscaling_scheduled_action" "scale_up" {
  name               = "${var.name}-scale-up"
  service_namespace  = aws_appautoscaling_target.lambda.service_namespace
  resource_id        = aws_appautoscaling_target.lambda.resource_id
  scalable_dimension = aws_appautoscaling_target.lambda.scalable_dimension
  schedule           = "cron(0 8 * * MON-FRI *)"  # 8 AM UTC weekdays
  timezone           = "America/New_York"

  scalable_target_action {
    min_capacity = 10
    max_capacity = 50
  }
}

resource "aws_appautoscaling_scheduled_action" "scale_down" {
  name               = "${var.name}-scale-down"
  service_namespace  = aws_appautoscaling_target.lambda.service_namespace
  resource_id        = aws_appautoscaling_target.lambda.resource_id
  scalable_dimension = aws_appautoscaling_target.lambda.scalable_dimension
  schedule           = "cron(0 20 * * MON-FRI *)"  # 8 PM UTC weekdays

  scalable_target_action {
    min_capacity = 2
    max_capacity = 10
  }
}

---

Tier 5: Initialization Best Practices

Optimize what runs outside the handler (initialization code runs on cold start):

// handler.ts

// ─── COLD START: runs once per container ─────────────────────────────────────

// ✅ Initialize SDK clients at module level (reused across invocations)
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { SecretsManagerClient } from "@aws-sdk/client-secretsmanager";

const dynamodb = new DynamoDBClient({ region: process.env.AWS_REGION });
const secretsManager = new SecretsManagerClient({ region: process.env.AWS_REGION });

// ✅ Load secrets once and cache them
let cachedSecrets: Record<string, string> | null = null;
async function getSecrets() {
  if (cachedSecrets) return cachedSecrets;
  
  const { SecretString } = await secretsManager.send(
    new GetSecretValueCommand({ SecretId: process.env.SECRET_ARN })
  );
  cachedSecrets = JSON.parse(SecretString!);
  return cachedSecrets!;
}

// ✅ Database connection pool (reused if container is warm)
let pool: Pool | null = null;
async function getPool() {
  if (pool) return pool;
  const secrets = await getSecrets();
  pool = new Pool({ connectionString: secrets.DATABASE_URL, max: 2 });
  return pool;
}

// ─── HANDLER: runs on every invocation ───────────────────────────────────────
export const handler = async (event: APIGatewayProxyEvent) => {
  // getPool() is fast on warm starts (returns cached pool)
  const db = await getPool();
  
  // Handle the request
  const result = await processRequest(event, db);
  return result;
};

Avoid these initialization anti-patterns:

// ❌ Sync file system reads in init (slow)
const config = JSON.parse(fs.readFileSync("./config.json", "utf-8"));

// ✅ Bundle config at build time
const config = { timeout: 30, retries: 3 } as const;

// ❌ Heavy computation in module scope
const lookup = buildLookupTable(largeDataset); // Runs on every cold start

// ✅ Lazy-init with cache
let lookup: Map<string, string> | null = null;
function getLookup() {
  if (!lookup) lookup = buildLookupTable(largeDataset);
  return lookup;
}

---

Lambda Layers for Shared Dependencies

Move large shared dependencies (like aws-sdk v2, or a custom runtime) to a Layer:

resource "aws_lambda_layer_version" "shared_deps" {
  filename            = "layers/shared-deps.zip"
  layer_name          = "${var.name}-shared-deps"
  compatible_runtimes = ["nodejs22.x"]
  compatible_architectures = ["arm64"]
  source_code_hash    = filebase64sha256("layers/shared-deps.zip")
}

resource "aws_lambda_function" "api" {
  # ...
  layers = [aws_lambda_layer_version.shared_deps.arn]
}

Note: Layers reduce deployment package size, but don't inherently improve cold starts—Node.js still parses the layer code. The benefit is faster deploys and code sharing, not cold start time.

---

Cold Start Benchmarks (2026, Node.js 22, arm64)

---

Cost and Timeline Estimates

---

See Also

• AWS Lambda Layers — Packaging shared dependencies
• AWS SQS Worker Pattern — Async processing that tolerates cold starts
• AWS CloudWatch Observability — Measuring cold start duration
• AWS ECS Fargate Production — When to choose ECS over Lambda

---

Working With Viprasol

We optimize AWS Lambda functions for production workloads—from bundling audits through SnapStart migration for Java services. Our cloud team has reduced Lambda cold starts by 70–95% for client APIs serving millions of requests per month.

What we deliver:

• Bundle size audit and esbuild migration
• Graviton3 architecture migration
• Provisioned concurrency auto-scaling configuration
• SnapStart implementation for Java workloads
• Cold start monitoring with CloudWatch dashboards

See our cloud infrastructure services or contact us to eliminate Lambda cold starts.