1

I'm currently working on a serverless API using AWS Lambda functions with Spring Boot's native image feature powered by GraalVM. In my project, I have a common project that acts as a shared codebase and includes dependencies used by the lambda functions. This common project is imported as a Maven dependency with the "provided" scope.

To optimize the size of the lambda code base and enhance execution time, I'm exploring the option of utilizing lambda layers. However, I'm uncertain about the ideal packaging approach for the common project code within the lambda layer. Should it be packaged as a JAR file or as a GraalVM executable binary file?

Here's an example of one of my lambda function definitions in CloudFormation:

SampleFunction:
  Type: AWS::Serverless::Function
  Properties:
    VpcConfig:
      SecurityGroupIds:
        - !Ref LambdaSecGroup
      SubnetIds:
        - !Ref xx
        - !Ref yy
        - !Ref zz
    Handler: provided
    Runtime: provided.al2
    MemorySize: 1024
    CodeUri:
      Bucket: lambda-resource-us-east-1
      Key: native/target/lambdas-0.0.1-SNAPSHOT-native-zip.zip
    Role: !Ref LambdaRoleArn
    Tracing: Active

If any of you have experience with packaging a common project as a lambda layer in Spring Boot's native image projects, I would greatly appreciate your valuable insights and guidance. I'm particularly interested in understanding the best practices for structuring and packaging the common project code to fully leverage the benefits of lambda layers.

I attempted to add a lambda layer to my AWS Lambda function, which included a JAR file of my common project. However, the lambda failed to execute and threw a "class not found" exception. Here is the configuration I used:

LambdaLayer:
  Type: AWS::Lambda::LayerVersion
  Properties:
    LayerName: common-layer
    Description: common
    ContentUri:
      CodeUri: common-0.0.4-SNAPSHOT.jar
    CompatibleRuntimes:
      - provided.al2
user3786929
  • 11
  • 2

0 Answers0