AWS Lambda SnapStart: Eliminating Cold Starts for Java Functions

AWS Lambda SnapStart: Zero Cold Starts for Java

AWS Lambda SnapStart is a game-changing feature that reduces Java function cold start times from 5-10 seconds to under 200 milliseconds. It works by taking a snapshot of the initialized function after the init phase completes, then restoring from that snapshot for subsequent invocations. Therefore, Java developers can finally use Lambda for latency-sensitive workloads without the cold start penalty that made serverless Java impractical.

Cold starts have been Java’s biggest weakness in serverless environments. The JVM initialization, class loading, and framework startup (especially Spring Boot) consume several seconds on first invocation. Moreover, this penalty recurs whenever Lambda scales up or recovers from idle timeout. Consequently, many teams avoided Java for Lambda functions despite Java’s superior performance after warmup. SnapStart changes this equation entirely.

AWS Lambda SnapStart: How It Works

SnapStart leverages the Firecracker microVM’s snapshot/restore capability. During deployment, Lambda runs your function’s init phase, takes a memory snapshot (CRaC — Coordinated Restore at Checkpoint), and stores it encrypted. Furthermore, when a new execution environment is needed, Lambda restores from the snapshot instead of running init from scratch. As a result, the entire JVM state — loaded classes, initialized beans, connection pools — is immediately available.

# AWS SAM template with SnapStart enabled
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  OrderFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: com.myapp.OrderHandler::handleRequest
      Runtime: java21
      MemorySize: 1024
      Timeout: 30
      SnapStart:
        ApplyOn: PublishedVersions  # Enable SnapStart
      AutoPublishAlias: live        # Required for SnapStart
      Environment:
        Variables:
          DB_ENDPOINT: !Ref DatabaseEndpoint
          CACHE_ENDPOINT: !Ref CacheEndpoint
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref OrdersTable

Lifecycle Hooks: beforeCheckpoint and afterRestore

Some resources cannot be safely snapshotted — network connections, random number generators, and temporary credentials expire between snapshot and restore. SnapStart provides lifecycle hooks through the CRaC API to handle these cases. Additionally, beforeCheckpoint lets you clean up resources before the snapshot, while afterRestore re-initializes them after restore.

import org.crac.Context;
import org.crac.Core;
import org.crac.Resource;

public class OrderHandler implements RequestHandler<APIGatewayProxyRequestEvent,
        APIGatewayProxyResponseEvent>, Resource {

    private DynamoDbClient dynamoDb;
    private ObjectMapper mapper;
    private HikariDataSource dataSource;

    public OrderHandler() {
        // Init phase — this gets snapshotted
        Core.getGlobalContext().register(this);
        this.mapper = new ObjectMapper();
        this.dynamoDb = DynamoDbClient.create();
        initializeConnectionPool();
    }

    @Override
    public void beforeCheckpoint(Context<? extends Resource> context) {
        // Clean up before snapshot
        if (dataSource != null) {
            dataSource.close(); // Close DB connections
        }
        dynamoDb.close(); // Close AWS SDK client
    }

    @Override
    public void afterRestore(Context<? extends Resource> context) {
        // Re-initialize after restore
        this.dynamoDb = DynamoDbClient.create();
        initializeConnectionPool();
        // Refresh any cached credentials
        refreshSecrets();
    }

    private void initializeConnectionPool() {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl(System.getenv("DB_ENDPOINT"));
        config.setMaximumPoolSize(5);
        config.setMinimumIdle(1);
        this.dataSource = new HikariDataSource(config);
    }

    @Override
    public APIGatewayProxyResponseEvent handleRequest(
            APIGatewayProxyRequestEvent event, Context context) {
        // Business logic — same as before
        Order order = mapper.readValue(event.getBody(), Order.class);
        orderRepository.save(order);
        return new APIGatewayProxyResponseEvent()
            .withStatusCode(200)
            .withBody(mapper.writeValueAsString(order));
    }
}

Performance Benchmarks

Real-world benchmarks show dramatic improvements with SnapStart. A Spring Boot 3 Lambda function that previously had 6-8 second cold starts now initializes in 150-200ms. Furthermore, the restore time is consistent regardless of function complexity — even functions with hundreds of Spring beans restore in under 200ms. This makes Java competitive with Go and Python for cold start performance.

// Cold Start Benchmarks (1024MB memory, Java 21)
// Without SnapStart:
//   Init duration: 6,200ms (Spring Boot 3.2)
//   Init duration: 3,800ms (Micronaut 4)
//   Init duration: 2,100ms (plain Java + SDK)

// With SnapStart:
//   Restore duration: 180ms (Spring Boot 3.2)
//   Restore duration: 150ms (Micronaut 4)
//   Restore duration: 120ms (plain Java + SDK)

// Warm invocation (both):
//   Duration: 15-50ms (depends on business logic)

AWS Lambda SnapStart: Common Pitfalls

Watch out for uniqueness assumptions — if your init phase generates UUIDs or random numbers, the same values will appear in every restored instance. Additionally, cached DNS resolutions and TLS sessions may be stale after restore. Therefore, always use the CRaC hooks to regenerate anything that must be unique or fresh per invocation.

• Replace Random with SecureRandom (re-seeded after restore)
• Don’t cache temporary STS credentials in init
• Close and reopen network connections in afterRestore
• Test with sam local invoke before deploying
• Monitor restore duration in CloudWatch Metrics

When to Use SnapStart

Use SnapStart for any Java Lambda function where cold start latency matters — API endpoints, synchronous event processors, and user-facing services. It’s less important for async processors (SQS, S3 events) where occasional delays are acceptable. See the AWS Lambda SnapStart documentation for configuration details and supported runtimes.

In conclusion, AWS Lambda SnapStart removes the last major barrier to running Java in serverless environments. With sub-200ms cold starts, Java functions match the startup performance of interpreted languages while delivering superior runtime throughput. Enable SnapStart, implement CRaC lifecycle hooks, and deploy Java Lambda functions with confidence.