AWS Lambda and Spring Boot: A Java Developer’s Journey

Dec 2, 2025 | Insights

AWS Lambda and Spring Boot: A Java Developer’s Journey

Author: Paul Clinton


Introduction:

As a Java developer, I embarked on a transformative journey with AWS Lambda and Spring Boot, supported by my team. Although I was new to these technologies, the team provided me with a template and had already conducted a POC (Proof Of Concept) for the migration. In this blog, I’ll share my experiences, the challenges that I faced, and how the team’s support, along with the provided template and POC, accelerated our success in migrating Java applications from AWS EC2 instances to AWS Lambda using the Spring Boot framework.

 

The Team’s Template: A Solid Starting Point

Having a template created by the team served as an excellent foundation for our migration project. It provided a structured approach, outlining the necessary configurations, dependencies, and project setup specific to AWS Lambda and Spring Boot. This template allowed me to quickly grasp the overall structure and flow of the migration process, saving time and effort.

When talking about the template, here is what the template contained : 

  1. Parameters:
    • DeployEnv: This parameter specifies the deployment environment, such as ‘dev’, ‘stg’, or ‘prod’.
    • S3Bucket: You’ll need to provide the name of an S3 bucket to store deployment artifacts.
    • S3ObjectKey: This parameter represents the file path of the JAR file within the S3 bucket.
    • SubnetID: You’ll need to provide the ID of a Subnet to be used by the Lambda function.
    • SecurityGroupID: Provide the Security Group ID associated with the desired VPC.
    • DomainName: This parameter defines the domain name you wish to use for the API.
    • CertificateArn: You’ll need to provide the ARN (Amazon Resource Name) of the environment-specific SSL/TLS certificate.
  2. Resources:
    • Route53RecordSetGroup: This resource creates a Route53 record set for your API’s domain name.
    • Domain: Configures the API Gateway domain name.
    • BasePathMapping: Maps the base path of the API to the custom domain.
    • ServlessAPI: This resource defines the AWS Serverless API.
    • Function: Configures the AWS Serverless Function resource for the Lambda function.
    • Group: Creates a CloudWatch Log Group for the Lambda function.
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Deploying a Spring Boot REST API with AWS Lambda

Parameters:
  DeployEnv:
    Type: String
    Default: dev
    Description: Indicates the deployment environment.
    AllowedValues:
      - dev
      - stg
      - prod
  S3Bucket:
    Type: String
    Default: <s3-bucket>
    Description: Indicates the S3 bucket for each environment.
  S3ObjectKey:
    Type: String
    Default: <location_of_jar_file>
    Description: Indicates the S3 bucket deployment artifact file path for each environment.
  SubnetID:
    Type: String
    Default: <subnet-id>
    Description: Indicates which Subnet Id to be used.
  SecurityGroupID:
    Type: String
    Default: <security-group-id>
    Description: Indicates the Security Group of VPC belongs to.
  DomainName:
    Type: String
    Default: <domain-name>
    Description: Indicates the domain name per environment.
  CertificateArn:
    Type: String
    Default: <ARN>
    Description: Indicates the env-specific certificate ARNs.

Resources:
  Route53RecordSetGroup:
    Type: AWS::Route53::RecordSetGroup
    Properties:
      HostedZoneName: <hosted-zone>
      RecordSets:
        - Name:  !Ref DomainName
          Type: A
          AliasTarget:
            HostedZoneId: Z2FDTNDATAQYW2
            DNSName: !GetAtt Domain.DistributionDomainName

  Domain:
    Type: AWS::ApiGateway::DomainName
    Properties: 
      CertificateArn: !Ref CertificateArn
      DomainName: !Ref DomainName

  BasePathMapping:
    Type: AWS::ApiGateway::BasePathMapping
    DependsOn:
      - ServlessAPI
    Properties:
      DomainName:
        Ref: Domain
      RestApiId:
        Ref: ServlessAPI
      Stage: !Ref ServlessAPI.Stage

  ServlessAPI:
    Type: AWS::Serverless::Api
    Properties:
      StageName: !Ref DeployEnv
      EndpointConfiguration: EDGE  

  Function:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri:
        Bucket: !Ref S3Bucket
        Key: !Ref S3ObjectKey
      Handler: <handler-package>
      MemorySize: 2560
      AutoPublishAlias: !Ref DeployEnv
      VpcConfig:
        SecurityGroupIds:
          - !Ref SecurityGroupID
        SubnetIds:
          - !Ref SubnetID
      Events:
        ProxyResource:
          Type: Api
          Properties:
            RestApiId:
              Ref: ServlessAPI
            Path: <api-path>
            Method: any

  Group:
    Type: AWS::Logs::LogGroup
    Properties:
      LogGroupName: !Sub "/aws/lambda/${Function}"
      RetentionInDays: 7

 

Learning from the Proof of Concept (POC)

The team’s previous POC of the migration played a significant role in my journey. By studying the POC codebase and documentation, I gained valuable insights into the intricacies of adapting Java applications to AWS Lambda using Spring Boot. The POC served as a practical example, showcasing the best practices and potential pitfalls that could arise during the migration process. It provided me with a reference point, enabling me to understand and replicate successful strategies.

The Proof of Concept (POC) included a Spring Boot template that consisted of the following components:

  • REST API endpoint:  The template contained a controller class to define a REST API endpoint.
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api")
public class HelloController {

    @GetMapping("/hello")
    public String hello() {
        return "Hello, World!";
    }

}

 

  • Lambda function: The POC featured a class named LambdaHandler that implemented the RequestStreamHandler interface provided by the AWS SDK.
import com.amazonaws.services.lambda.runtime.Context;
import com.amazonaws.services.lambda.runtime.RequestStreamHandler;
import org.springframework.cloud.function.adapter.aws.SpringBootRequestHandler;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;

public class LambdaHandler implements RequestStreamHandler {

    private final SpringBootRequestHandler<String, String> handler;

    public LambdaHandler() {
        handler = new SpringBootRequestHandler<>(LambdaConfig.class);

    }

    @Override
    public void handleRequest(InputStream inputStream, OutputStream outputStream, Context context) throws IOException {

        handler.handleRequest(inputStream, outputStream, context);

    }

}

Grasping AWS Lambda Concepts

Despite the advantages of the template and POC, AWS Lambda still presented a learning curve. Understanding the fundamentals of serverless computing, event-driven architecture, and the role of Lambda in the AWS ecosystem required dedicated study and exploration. I made use of AWS documentation, tutorials, and hands-on experiments to familiarize myself with Lambda’s core concepts and its integration with other AWS services.

 

Leveraging Team Code Reviews

Code reviews conducted by the team served as crucial checkpoints in ensuring the quality and correctness of my migration efforts. Their valuable feedback, suggestions, and best practices not only helped me improve my code but also enhanced my understanding of AWS Lambda and Spring Boot. These reviews fostered a collaborative environment where we collectively aimed for excellence and continuous improvement.

Customizing the Template for the Application

Once I grasped the underlying concepts and gained familiarity with Spring Boot, I began tailoring the provided template to suit the specific requirements of the Java applications being migrated. I extended the template’s functionality, implemented business logic, and integrated the application’s existing components. The template provided a solid foundation, saving valuable time by abstracting away repetitive boilerplate code and allowing me to focus on the application-specific logic.

Iterative Testing and Refinement

During the migration, I iteratively tested the Lambda functions using the template’s test harness and local development tools. This allowed me to identify and address any issues early in the process, ensuring a smoother deployment to AWS Lambda. I collaborated closely with the team, conducting thorough testing and incorporating their feedback to refine and optimize the application’s performance.

 

Conclusion:

My journey into AWS Lambda and Spring Boot, supported by the team’s template and previous POC, was a transformative experience. The template provided structure and guidance, allowing me to hit the ground running. The team’s previous POC served as a valuable learning resource, highlighting best practices and potential pitfalls.

In the next blog, we will delve into the challenges faced during the migration process and discuss the strategies and solutions that helped us overcome those obstacles. Stay tuned for our upcoming blog post, where we will share our firsthand experiences and lessons learned on this transformative journey.

Collaborative knowledge sharing, code reviews, and the team’s support accelerated my understanding and proficiency in AWS Lambda and Spring Boot. Their expertise, combined with my determination to learn and adapt, enabled us to overcome challenges and deliver a successful migration.

By acknowledging the significance of team collaboration and utilizing available resources, developers can embrace new technologies and efficiently migrate applications. The combination of AWS Lambda and Spring Boot presents an exciting opportunity for growth, innovation, and enhanced development processes.

Remember, with a supportive team and a solid starting point, any developer can embark on a transformative journey and successfully migrate Java applications to AWS Lambda using Spring Boot.