MCP Server Lambda SnapStart — JVM cold start elimination for Java MCP servers

How SnapStart works

The standard Lambda lifecycle has three phases: init (load the runtime, load the handler class, run static initializers and the handler constructor), invoke (call the handler for each request), and shutdown. Cold starts are expensive because of the init phase — for a Java MCP server loading Spring, the MCP SDK, JDBC drivers, and schema validation, init can take 5–12 seconds.

SnapStart intercepts after init completes: it fires a beforeCheckpoint event, takes a memory snapshot of the execution environment (JVM heap, class data, file descriptors), and stores it encrypted in a cache. On the next cold start (scaling event or idle timeout recovery), Lambda restores from the snapshot in ~250ms instead of re-running the entire init phase, then fires afterRestore before the first invocation.

Enabling SnapStart with CDK

SnapStart is supported on Java 21+ runtimes. Enable it in CDK with snapStart on the function construct. The function must be published as a version — SnapStart does not activate on $LATEST.

import * as lambda from "aws-cdk-lib/aws-lambda";
import { Duration } from "aws-cdk-lib";

const mcpFn = new lambda.Function(this, "McpJavaFunction", {
  runtime: lambda.Runtime.JAVA_21,
  handler: "com.example.McpHandler::handleRequest",
  code: lambda.Code.fromAsset("target/mcp-server.jar"),
  timeout: Duration.minutes(5),
  memorySize: 1024,    // more memory = faster class loading even without SnapStart
  snapStart: lambda.SnapStartConf.ON_PUBLISHED_VERSIONS,  // enable SnapStart
});

// Publish a version (required for SnapStart to activate)
const version = new lambda.Version(this, "McpVersion", {
  lambda: mcpFn,
  description: `SnapStart version ${Date.now()}`,
});

// Create alias for Function URL
const alias = new lambda.Alias(this, "McpAlias", {
  aliasName: "live",
  version,
});

Implementing CRaC hooks for MCP servers

The Coordinated Restore at Checkpoint (CRaC) API lets you register resources that are notified before snapshot (beforeCheckpoint) and after restore (afterRestore). For a Java MCP server, the resources that need CRaC hooks are: database connections, HTTP clients, and any time-seeded state like SecureRandom.

// build.gradle.kts: add CRaC dependency
dependencies {
    implementation("io.github.crac:org-crac:0.1.3")
    implementation("software.amazon.awssdk:lambda:2.21.0")
    implementation("io.modelcontextprotocol:kotlin-sdk:1.0.0")
}

// McpHandler.java
package com.example;

import org.crac.Context;
import org.crac.Core;
import org.crac.Resource;
import software.amazon.awssdk.services.secretsmanager.SecretsManagerClient;
import java.security.SecureRandom;

public class McpHandler implements Resource {
    private SecretsManagerClient secretsClient;
    private DatabaseConnectionPool dbPool;
    private SecureRandom secureRandom;

    public McpHandler() {
        // Init phase: set up all resources
        this.secretsClient = SecretsManagerClient.create();
        this.dbPool = DatabaseConnectionPool.create(loadDbUrl());
        this.secureRandom = new SecureRandom();

        // Register this instance for CRaC lifecycle events
        Core.getGlobalContext().register(this);
    }

    @Override
    public void beforeCheckpoint(Context context) throws Exception {
        // Close all network connections before snapshot is taken
        // (connections are invalid after restore — stale TCP state)
        dbPool.closeAll();
        secretsClient.close();
        // Note: do NOT reseed secureRandom here — do it in afterRestore
    }

    @Override
    public void afterRestore(Context context) throws Exception {
        // Re-establish connections after snapshot restore
        secretsClient = SecretsManagerClient.create();
        String dbUrl = loadDbUrl();   // re-fetch from Secrets Manager with fresh client
        dbPool = DatabaseConnectionPool.create(dbUrl);

        // Reseed SecureRandom — critical: snapshot captured seed state is shared
        // across all restored instances if not reseeded
        secureRandom = new SecureRandom();
        secureRandom.nextBytes(new byte[32]);  // force entropy seeding

        // Refresh any TTL counters or timestamps that were set during init
        initTimestamp = System.currentTimeMillis();
    }

    public String handleRequest(Map<String, Object> event, Context context) {
        // Standard MCP request handling
        return mcpDispatch(event);
    }
}

What you must always do in afterRestore:

• Re-open all network connections (DB pool, HTTP client, gRPC channels)
• Re-fetch short-lived credentials (IAM temporary credentials from instance metadata, Secrets Manager values with rotation TTL shorter than your Lambda idle timeout)
• Reseed SecureRandom or any PRNG initialized during init
• Reset any monotonic counters or timestamps used for TTL or rate limiting

SnapStart limitations for MCP servers

SnapStart is not a complete substitute for Provisioned Concurrency. The restore still takes 200–400ms — if your SLA requires sub-100ms first-response latency, combine SnapStart with Provisioned Concurrency (SnapStart reduces the cost of provisioned instances by making the pre-initialization cheaper at deploy time).

Common failure modes