DEV Community: Ranjith kumar Ramakrishnan

AWS Lambda with Spring Boot and SnapStart: Killing the JVM Cold Start

Ranjith kumar Ramakrishnan — Mon, 03 Aug 2026 19:43:34 +0000

Every Java developer who has tried to put a Spring Boot application on AWS Lambda has met the same wall: the cold start. The first request after a scale-up sits there for two, three, sometimes four seconds while the JVM boots, the classes load, and the Spring context wires itself together. For a batch job nobody notices. For an API a user is waiting on, it is the reason a lot of teams quietly concluded that "Java doesn't belong on Lambda" and either rewrote services in a faster-starting runtime or stayed on containers.

That conclusion is now out of date. Between AWS Lambda SnapStart and the CRaC (Coordinated Restore at Checkpoint) mechanism it builds on, you can run a real Spring Boot service on Lambda with cold starts in the low hundreds of milliseconds instead of multiple seconds — while keeping your existing Spring codebase, build, and team. This article walks through how it works, wires it up with working code, and covers the handful of gotchas that will bite you if you treat it as a magic switch.

The problem, precisely

A JVM cold start is three costs stacked on top of each other:

Runtime init — the JVM process starts.
Framework init — Spring Boot builds the application context: component scanning, bean creation, auto-configuration.
First-request cost — classes not touched during init get loaded and JIT-compiled on the first real request.

For a trivial handler, (1) dominates. For a Spring Boot service, (2) is usually the biggest single cost and the one that makes people give up. Building an application context is genuinely expensive work, and doing it on the critical path of a user request is the mistake.

The insight behind SnapStart is simple: do that expensive work once, snapshot the initialized process, and restore from the snapshot instead of redoing the work.

What SnapStart actually does

When you enable SnapStart on a Java function, AWS runs your initialization once, ahead of time, and takes a Firecracker microVM snapshot of the fully initialized process — JVM warmed up, Spring context built, beans created. Instead of cold-starting from zero on each new execution environment, Lambda restores that snapshot. The expensive framework init has already happened and is frozen into the snapshot, so it doesn't recur on the request path.

For a typical Spring Boot function this turns a multi-second cold start into a restore often in the 200–400 ms range — the difference between "unusable for interactive APIs" and "fine for the great majority of workloads."

Figure 1: API Gateway → SnapStart-enabled Spring Boot function → DynamoDB / EventBridge. Initialization (JVM + Spring context + priming) happens once and is snapshotted; execution environments restore from the snapshot, and CRaC hooks close stale state before checkpoint and refresh it after restore.

Enabling it

Enabling SnapStart is configuration, not a rewrite. In SAM it is a property on the function:

Resources:
  OrderApiFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: java21
      Handler: com.example.OrderApiHandler::handleRequest
      CodeUri: target/order-api.jar
      MemorySize: 1024
      Timeout: 30
      AutoPublishAlias: live          # SnapStart requires a version/alias
      SnapStart:
        ApplyOn: PublishedVersions    # valid values: PublishedVersions | None

Two things matter here. ApplyOn: PublishedVersions tells Lambda to snapshot the initialized environment when you publish a version. And SnapStart only applies to published versions and aliases that point to them — the $LATEST version does not use SnapStart at all. The AutoPublishAlias: live line ensures every deployment publishes a new version and moves the live alias to it, so you are always invoking a snapshotted version rather than $LATEST.

Activation is where the interesting part begins, because snapshotting a running process brings two Java-specific problems that you, not AWS, must solve.

Add the CRaC dependency

Everything below uses the CRaC API. Add its dependency to your build. Two coordinates are in common use and both expose the same org.crac interface:

<!-- Common in the Spring / Lambda ecosystem -->
<dependency>
  <groupId>io.github.crac</groupId>
  <artifactId>org-crac</artifactId>
  <version>0.1.3</version>
</dependency>

<!-- Alternatively, the coordinate used in AWS's own Lambda docs -->
<!--
<dependency>
  <groupId>org.crac</groupId>
  <artifactId>crac</artifactId>
  <version>1.4.0</version>
</dependency>
-->

Recent Spring Boot versions integrate with CRaC and will drive lifecycle callbacks for some managed resources automatically, so check what your Spring version already does before hand-rolling everything below. The pattern shown here is the explicit version, which works regardless.

Gotcha 1: state frozen into the snapshot goes stale

A snapshot captures your process as it was at checkpoint time — including things that must not be reused:

Open connections. A DB or HTTP connection open at checkpoint is dead by the time the snapshot is restored, possibly days later. Reusing it fails on the first request.
Uniqueness and randomness. A random seed, generated ID, or cached timestamp captured at checkpoint is identical across every restored environment, because they all restore from the same snapshot. Seed a Random at startup and every environment now shares the same sequence.

CRaC solves this with lifecycle hooks that run around the snapshot. beforeCheckpoint() fires just before the snapshot; afterRestore() fires just after each restore. You close what shouldn't be frozen and re-establish what must be fresh:

package com.example;

import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;
import org.crac.Context;
import org.crac.Core;
import org.crac.Resource;

import javax.sql.DataSource;
import java.security.SecureRandom;

/**
 * Owns anything unsafe to freeze into a snapshot: the connection pool
 * (closed before checkpoint, reopened after restore) and the RNG
 * (re-seeded after restore so every restored environment differs).
 * Priming of the request path also happens in beforeCheckpoint().
 */
public class SnapshotSafeResources implements Resource {

    private volatile HikariDataSource dataSource;
    private volatile SecureRandom random;
    private final OrderApiHandler handlerForPriming;

    public SnapshotSafeResources(OrderApiHandler handlerForPriming) {
        this.handlerForPriming = handlerForPriming;
        this.dataSource = buildPool();
        this.random = new SecureRandom();
        Core.getGlobalContext().register(this);   // hook into the CRaC lifecycle
    }

    @Override
    public void beforeCheckpoint(Context<? extends Resource> ctx) {
        // 1) Prime the hot path so its classes are loaded/JIT-warmed into
        //    the snapshot (see Gotcha 2). Best-effort; must not fail init.
        try {
            Priming.warm(handlerForPriming);
        } catch (RuntimeException ignored) { /* priming is an optimization */ }

        // 2) Close the pool so no dead connection is frozen into the snapshot.
        if (dataSource != null && !dataSource.isClosed()) {
            dataSource.close();
        }
    }

    @Override
    public void afterRestore(Context<? extends Resource> ctx) {
        // Every restored environment gets a live pool and a fresh RNG seed.
        this.dataSource = buildPool();
        this.random = new SecureRandom();          // do NOT reuse a frozen seed
    }

    public DataSource dataSource() { return dataSource; }
    public SecureRandom random()   { return random; }

    private HikariDataSource buildPool() {
        HikariConfig cfg = new HikariConfig();
        cfg.setJdbcUrl(System.getenv("JDBC_URL"));
        cfg.setUsername(System.getenv("DB_USER"));
        cfg.setPassword(System.getenv("DB_PASSWORD"));
        cfg.setMaximumPoolSize(5);
        return new HikariDataSource(cfg);
    }
}

One constraint to respect: beforeCheckpoint() counts toward the initialization time limit, and afterRestore() must finish within 10 seconds or Lambda throws a SnapStartTimeoutException. Keep the hooks lean — prime what matters, don't try to warm everything.

Gotcha 2: a cold snapshot is still a cold-ish start

SnapStart removes framework-init cost, but a class never loaded during init still loads and JIT-compiles the first time a real request touches it. A snapshot of a context that never served a request is "built but never exercised," and the first restored request pays the exercising cost.

The fix is priming: run a representative request during initialization, inside beforeCheckpoint() (as wired above), so the hot classes are loaded and warmed into the snapshot.

package com.example;

import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;

/**
 * Priming: exercise the real request path before the snapshot is taken so
 * its classes are loaded and JIT-warmed. Best-effort — a priming failure
 * must never fail initialization.
 */
public final class Priming {

    private Priming() {}

    static void warm(OrderApiHandler handler) {
        APIGatewayProxyRequestEvent sample = new APIGatewayProxyRequestEvent();
        sample.setHttpMethod("POST");
        sample.setPath("/orders");
        sample.setBody("{\"orderId\":\"PRIMING\",\"amount\":1}");
        handler.handleRequest(sample, null);   // run the hot path once
    }
}

Priming is the single highest-leverage thing you can do to get from "SnapStart works" to "SnapStart is fast." It is also the step most tutorials omit — which is why people sometimes report disappointing numbers. For Spring Boot specifically, driving a full application-context invocation this way (or via an ApplicationRunner at startup) is what warms the framework's request mapping, not just your own code.

Putting it together in the handler

The handler wires the pieces: build the CRaC-managed resources at init (which registers the checkpoint hooks and arranges priming), and keep the request method idempotent because SnapStart does nothing for delivery semantics (more on that next).

package com.example;

import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestHandler;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent;
import com.amazonaws.services.lambda.runtime.events.APIGatewayProxyResponseEvent;

public class OrderApiHandler
        implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

    // Static init runs ONCE, before the snapshot is taken. Constructing the
    // resources registers the CRaC hooks and sets up priming for checkpoint.
    private static final OrderApiHandler INSTANCE = new OrderApiHandler();
    private static final SnapshotSafeResources RESOURCES = new SnapshotSafeResources(INSTANCE);
    private static final OrderService ORDERS = new OrderService(RESOURCES);

    @Override
    public APIGatewayProxyResponseEvent handleRequest(
            APIGatewayProxyRequestEvent event, Context context) {

        Order order = OrderJson.parse(event.getBody());

        // Idempotent completion: safe to call twice for the same order.
        String confirmationId = ORDERS.complete(order.orderId(), order);

        return new APIGatewayProxyResponseEvent()
                .withStatusCode(200)
                .withBody("{\"confirmationId\":\"" + confirmationId + "\"}");
    }
}

What SnapStart does NOT fix

Being honest about the boundaries is what separates a usable mental model from a fragile one:

It is not exactly-once anything. SnapStart is about startup latency; it does nothing for the correctness of your side effects. If your handler is triggered by an at-least-once source (EventBridge, SQS) and does something with side effects, you still need idempotency — a separate concern. Here is the idempotent completion referenced above, using a conditional write so a duplicate delivery returns the original result instead of acting twice:

package com.example;

import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.*;

import java.util.Map;
import java.util.UUID;

public class OrderService {

    private final DynamoDbClient dynamo;
    private final String table = System.getenv("ORDER_TABLE");

    public OrderService(SnapshotSafeResources resources) {
        this.dynamo = DynamoDbClient.create();
    }

    /**
     * Complete an order exactly once. If the same orderId is completed twice
     * (a retry or duplicate delivery), the conditional write fails and we
     * return the ALREADY-stored confirmation rather than creating a new one.
     */
    public String complete(String orderId, Order order) {
        String confirmationId = "CONF-" + UUID.randomUUID();
        try {
            dynamo.updateItem(UpdateItemRequest.builder()
                .tableName(table)
                .key(Map.of("OrderId", AttributeValue.fromS(orderId)))
                .updateExpression("SET #s = :done, ConfirmationId = :cid")
                .conditionExpression("attribute_not_exists(ConfirmationId)")
                .expressionAttributeNames(Map.of("#s", "Status"))
                .expressionAttributeValues(Map.of(
                    ":done", AttributeValue.fromS("Completed"),
                    ":cid",  AttributeValue.fromS(confirmationId)))
                .build());
            return confirmationId;                       // first time
        } catch (ConditionalCheckFailedException already) {
            GetItemResponse existing = dynamo.getItem(GetItemRequest.builder()
                .tableName(table)
                .key(Map.of("OrderId", AttributeValue.fromS(orderId)))
                .projectionExpression("ConfirmationId")
                .build());
            return existing.item().get("ConfirmationId").s();  // replay: return stored
        }
    }
}

(For at-least-once sources where you would rather not add a dedicated table, I wrote about a lighter Parameter-Store approach to exactly-once processing in a previous article; SnapStart and idempotency solve orthogonal problems and you often need both.)

It does not shrink a genuinely heavy application. If your context builds forty seconds of work, the restore is fast but the checkpoint build still has to happen and counts against init limits. SnapStart rewards lean initialization.
It has restore cost that scales with snapshot size. Large snapshots restore more slowly; disciplined dependencies help.
It requires versioned invocation. You give up $LATEST for published versions/aliases — good practice anyway, but a change.

Benchmarks — measure your own

Numbers vary enormously with application size, memory, and priming quality, so measure your own. The honest comparison, on the same memory and payload, is three configurations:

cold start without SnapStart,
restore with SnapStart but no priming,
restore with SnapStart and priming.

In practice the third is where Spring Boot on Lambda becomes genuinely viable for interactive workloads — but the only number that matters for your decision is the one from your own function. Watch the Init Duration and first-request durations in the Lambda logs, run each configuration enough times to see the distribution rather than one lucky sample, and decide on data.

When to reach for something else

SnapStart makes Spring Boot on Lambda viable; it is not always the right answer:

For latency-critical, high-volume interactive services, provisioned concurrency or a container deployment may edge it out, at higher cost.
For greenfield functions, a natively-fast runtime (Quarkus/GraalVM native image) starts in tens of milliseconds without a snapshot, at the cost of a more constrained build.
For event-driven, latency-tolerant work — most background and integration workloads — SnapStart-enabled Spring Boot is often exactly right: you keep your framework, team, and governance perimeter, and pay almost nothing for the JVM's startup reputation.

Takeaways

SnapStart, with CRaC hooks and priming, retires the oldest objection to Java on Lambda. Hold the mental model precisely: snapshot the initialized process, restore instead of rebuild, close what goes stale, refresh what must be unique, and prime the request path so the snapshot is warm — and keep your side effects idempotent, because SnapStart never promised otherwise. Do that, and a Spring Boot service on Lambda starts fast enough for real users, inside the framework and governance perimeter your team already runs.

Written by Ranjith Kumar Ramakrishnan (ORCID: 0009-0007-4924-3264), an enterprise systems architect focused on AI-integrated, serverless architectures for public-safety-critical regulatory systems.

Exactly-Once Lambda Processing on At-Least-Once Event Sources — Without Adding a Table

Ranjith kumar Ramakrishnan — Tue, 28 Jul 2026 19:58:13 +0000

Every AWS engineer eventually meets this bug.

A Lambda function does something with a side effect — it transitions a record's status, sends a notification, posts a ledger entry, expires an authorization. It works perfectly in testing. Then one day, in production, it does that thing twice. A customer gets two emails. A record gets processed twice. A status flips, then flips again.

You didn't write a loop. You didn't deploy twice. So what happened?

At-least-once is the default, and it will find you

The event source delivered the same logical event more than once. This isn't a rare edge case or a misconfiguration — it's the documented contract of nearly every AWS event source:

EventBridge guarantees at-least-once delivery. Occasional duplicate deliveries are expected behavior.
SQS standard queues are explicitly at-least-once.
Scheduled rules can fire more than once around a boundary.
Automatic retries re-invoke your handler after a transient error — even if the first invocation actually succeeded but the response was lost.
Concurrent invocations can pick up the same event from two directions at once.

For a handler that's purely a read, none of this matters. For a handler with side effects, every one of these is a duplicate waiting to happen. And in regulated, financial, or safety-relevant systems, a duplicated side effect isn't a cosmetic glitch — it's a doubled notification, a double-processed expiration, a contradictory state change that someone downstream has to untangle.

The fix is idempotency: make sure the same logical event produces its side effect exactly once, no matter how many times it's delivered.

The usual answer, and a lighter one

The standard way to add idempotency on AWS is a DynamoDB table with a conditional write and a TTL. It works well and it's the right tool at high throughput. But it also means provisioning a table, managing its capacity, wiring up TTL, and adding a dependency — for what is often a very low-volume concern (lifecycle jobs, scheduled processors, moderate event streams).

There's a lighter primitive already sitting in every AWS account: SSM Parameter Store. It has strong per-parameter consistency, it needs nothing provisioned, and — crucially — PutParameter with Overwrite: false is atomic. That single property is enough to build an idempotency ledger: two racing invocations both try to create the same claim, exactly one wins, and the loser gets ParameterAlreadyExists.

I wrapped this into a tiny, dependency-light library: ssm-idempotency-guard.

npm install ssm-idempotency-guard

The whole thing in one call

import { createIdempotencyGuard, Outcome } from "ssm-idempotency-guard";

// Create once per container, reuse across invocations.
const guard = createIdempotencyGuard();

export async function handler(event) {
  // A STABLE, DETERMINISTIC key for the logical unit of work.
  // The same event must always produce the same key.
  const key = `${event["detail-type"]}:${event.detail.recordId}:${event.detail.effectiveDate}`;

  const { outcome, result } = await guard.runExactlyOnce(key, async () => {
    // ---- your side-effecting work ----
    await expireRegistration(event.detail.recordId);
    await notify(event.detail.recordId);
    return { expired: event.detail.recordId };
  });

  if (outcome === Outcome.SKIPPED_COMPLETED) {
    console.log("duplicate delivery ignored:", key);
  }
  return result;
}

Retries, duplicate deliveries, and concurrent invocations for the same key will not run your work twice. That's the entire idea.

How it actually works

Under the hood, runExactlyOnce does three things:

Claim the key. It writes a small ledger entry to Parameter Store under a name derived from your key, using Overwrite: false so the creation is atomic. If the key is already there and marked completed, it returns SKIPPED_COMPLETED and your work never runs. If another invocation holds a fresh in-flight claim, it returns SKIPPED_IN_FLIGHT.
Run your work — but only if the claim was won.
Complete or release. On success it marks the key completed so later duplicates are suppressed. On failure it releases the claim, so a legitimate retry can re-process rather than being silently blocked.

Two design choices worth calling out, because they're the difference between a toy and something you can put in production:

Crash recovery. If an invocation claims a key and then dies before completing, that claim would block the event forever. So claims carry a timestamp and an in-flight TTL (default 15 minutes). After that window, a stale claim can be taken over. Set the TTL comfortably above your worst-case handler duration.

Failure semantics. runExactlyOnce biases toward exactly-once on success and at-least-once on failure — it releases the claim if your work throws. If your side effect isn't naturally retry-safe, you can use the lower-level claim / complete / release primitives and mark completion only after the side effect is durably committed.

Choosing a good key

The idempotency key is the whole contract, and it has exactly one rule: it must be deterministic — derivable purely from the event, identical every time the same logical event arrives.

"RegistrationExpiry:REG-4821:2026-03-01"
"InvoicePosted:INV-99123"
"CylinderRequal:RIN-2049:2026-06-15"

Combine the event type, the target record, and whatever discriminator makes each logical occurrence unique. Avoid anything that varies per delivery — a receipt timestamp, a message ID — because then every duplicate looks brand new and deduplication does nothing.

The IAM you'll need

Scoped to your prefix:

{
  "Effect": "Allow",
  "Action": ["ssm:GetParameter", "ssm:PutParameter", "ssm:DeleteParameter"],
  "Resource": "arn:aws:ssm:*:*:parameter/idempotency/*"
}

When to reach for something else

Be honest about the boundaries:

Very high throughput (thousands of writes/sec against one key space) — Parameter Store has account-level throughput limits; DynamoDB with conditional writes and TTL is the better fit.
Already all-in on DynamoDB — the same conditional-write pattern applies there; this library exists for the common case where you'd rather not add a table.

For lifecycle automation, scheduled processors, and moderate event-driven workloads — which is a huge share of real serverless systems — the zero-infrastructure version is often exactly right.

Try it

The package is MIT-licensed and open source:

npm: ssm-idempotency-guard
GitHub: github.com/ranjith-ramakrishnan/ssm-idempotency-guard

The repo includes a runnable Lambda example and a scheduled cleanup sweeper, plus a test suite that proves exactly-once under duplicate delivery and one-executes-one-skips under concurrency — using an in-memory fake, so it runs with no AWS account.

If you've fought the duplicate-side-effect bug, I'd genuinely like to hear how you handled it — drop a comment.

Written by Ranjith Kumar Ramakrishnan (ORCID: 0009-0007-4924-3264), an enterprise systems architect focused on AI-integrated, serverless architectures for public-safety-critical regulatory systems.