Serverless Java: Spring Boot on AWS Lambda with GraalVM

Introduction

Java on AWS Lambda has a reputation problem: cold starts of 3–10 seconds make it unusable for latency-sensitive APIs. GraalVM native image changes that — a Spring Boot app compiled ahead of time starts in under 200ms and uses a fraction of the memory.

This tutorial walks through building, deploying and benchmarking a Spring Boot Lambda with GraalVM.

Serverless architecture concepts

client ──► API Gateway ──► Lambda (Spring Boot native) ──► DynamoDB / RDS

You pay only for invocations and execution time. Scaling is automatic — Lambda spins up new containers on demand and tears them down when idle.

The cold start problem

A Lambda "cold start" is the time from invocation to your handler returning. For JVM Spring Boot:

| Stage | JVM Spring Boot | Native (GraalVM) | | ------------------ | --------------- | ---------------- | | Init (class load) | ~3000 ms | ~80 ms | | First invocation | ~500 ms | ~30 ms | | Memory used | 512–1024 MB | 128–256 MB |

The JVM cold start hurts every time Lambda scales up — exactly when you need speed.

Step 1 — Spring Boot project with Lambda adapter

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-function-adapter-aws</artifactId>
</dependency>
<dependency>
  <groupId>com.amazonaws</groupId>
  <artifactId>aws-lambda-java-events</artifactId>
  <version>3.11.4</version>
</dependency>

```java
@SpringBootApplication
public class OrdersApp {
  public static void main(String[] args) { SpringApplication.run(OrdersApp.class, args); }

@Bean public Function<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> getOrder(OrderService svc) { return event -> { String id = event.getPathParameters().get("id"); Order o = svc.find(id); return new APIGatewayProxyResponseEvent() .withStatusCode(200) .withBody(toJson(o)); }; } } ```

Step 2 — GraalVM native build

<plugin>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
  <groupId>org.graalvm.buildtools</groupId>
  <artifactId>native-maven-plugin</artifactId>
  <configuration>
    <buildArgs>
      <arg>--no-fallback</arg>
      <arg>-H:+ReportExceptionStackTraces</arg>
    </buildArgs>
  </configuration>
</plugin>

Build inside the official Amazon Linux 2023 + GraalVM container so the binary is compatible with the Lambda runtime:

```dockerfile
FROM ghcr.io/graalvm/native-image-community:21 AS build
WORKDIR /src
COPY . .
RUN ./mvnw -B -Pnative native:compile

FROM public.ecr.aws/lambda/provided:al2023 COPY --from=build /src/target/orders /var/runtime/bootstrap RUN chmod +x /var/runtime/bootstrap CMD ["orders.OrdersApp"] ```

Step 3 — Deploy with AWS SAM

# template.yaml
Transform: AWS::Serverless-2016-10-31
Resources:
  OrdersFn:
    Type: AWS::Serverless::Function
    Properties:
      PackageType: Image
      MemorySize: 256
      Timeout: 10
      Architectures: [arm64]
      Events:
        Api:
          Type: HttpApi
          Properties: { Path: /orders/{id}, Method: GET }
    Metadata:
      Dockerfile: Dockerfile
      DockerContext: .

sam build && sam deploy --guided

Step 4 — Cold start benchmarks

Measured on arm64 with 256 MB memory:

| Variant | p50 cold | p99 cold | p50 warm | | ------------------------ | -------- | -------- | -------- | | Spring Boot JVM (Java 21)| 3200 ms | 6100 ms | 12 ms | | Spring Boot Native | 180 ms | 320 ms | 8 ms | | Plain Java handler | 350 ms | 720 ms | 5 ms |

Native is 17–19× faster on cold start than the JVM build.

Step 5 — Cost comparison vs containers

Take a low-traffic API: 1M requests/month, 100ms avg, 256MB.

| Platform | Monthly cost | | ----------------------------------- | ------------ | | Lambda native (arm64, 256MB) | ~$2.30 | | ECS Fargate (0.25 vCPU, 0.5GB, 24/7)| ~$10.80 | | EKS (smallest node, shared) | ~$73 + share |

Lambda wins at low/spiky volume; containers win once steady-state CPU goes above ~30%.

Optimization tips

• Build with --initialize-at-build-time for stable libraries — moves more work out of cold start.
• Use SnapStart (JVM) if you can't migrate to native — also cuts cold starts to ~200ms.
• Keep dependencies small: every JAR is more reflection metadata GraalVM has to track.
• Reuse SDK clients in static fields — Lambda freezes them between invocations.

API Gateway integration

For HTTP APIs, use the payload v2.0 format — smaller and faster than the REST API v1 format. Map path/query/body in your handler:

@Bean
public Function<APIGatewayV2HTTPEvent, APIGatewayV2HTTPResponse> handler(...) { ... }

Real-world use cases

• Public REST APIs with low or unpredictable traffic.
• Webhook receivers (Stripe, GitHub, Slack).
• Event processors triggered by SQS, S3, EventBridge.
• GraphQL resolvers behind AppSync.
• Scheduled jobs (EventBridge cron) replacing cron-on-EC2.

Caveats

• Reflection-heavy libraries (Hibernate, some serializers) need native hints — supply via @RegisterReflectionForBinding.
• Native build is slow — 3–6 minutes. Cache aggressively in CI.
• Debugging differs — no live JIT introspection; rely on logs and AWS X-Ray.

Related tutorials

• Scaling Java Microservices on AWS EKS
• Multi-Region Load Balancing with Ribbon and Eureka
• Distributed Locking with Spring Boot and Redis