Java Cold Starts in AWS Lambda

Java Cold Starts in AWS Lambda

Java is one of the most popular programming languages and with increased usage of AWS and its various services and platforms, its popularity has increased manifold.

AWS Lambda, introduced in Nov 2014 is an event-driven, serverless computing platform provided by Amazon as a part of Amazon Web Services. It is a computing service that runs code in response to events and automatically manages the computing resources required by that code. It is the main aim is to simplify building smaller, on-demand applications that are responsive to events and new information.

While developing apps with Java and AWS lambda, developers might face certain challenges, and AWS Lambda and Cold Start issues are one of the most frustrating ones that rears its head at critical times.

What is Cold Start?

A latency experienced when you trigger a lambda function is known as “Cold Start”. A cold start is triggered when an AWS Lambda function is invoked after not being used for an extended period of time resulting in increased invocation latency. A serverless application initialization adds extra latency to the execution of the request since it needs to be done before handling the request.

Reasons and Scenarios That Cause Cold Starts in the AWS Lambda Platform:

  • There is no container that is alive
  • There are containers alive, but none of them are available as all of them are busy with handling other requests
  • A new application was deployed so new containers must start with the newer version of the application
  • Changes in the Configuration (environment variable, security groups, memory limit, etc.), so new containers must start with new configurations

Factors Which Increase the Cold Start Time:

  • The language choice
  • VPC
  • HTTPS calls
  • Memory Size
  • Code Size
  • Things that require classpath scan (Java)

Solutions to Improve Cold Start Performance:

  • Use a dynamic programming language like Python, Ruby, or Pearl instead of a statically typed programming language C++ or Java.
  • Don’t use a virtual private cloud (VPC). A VPC will add a lot of time to your AWS Lambda that causing a cold start.
  • Memory size improves cold start time linearly but is expensive. Analysis: It takes approx. 2sec to sign up call on providing 3008 MB Memory whereas, 7sec on providing 704 MB memory and 4sec on 2048 MB memory.
  • If you want Java for your AWS Lambda functions, you should definitely avoid dependencies that scan classpath, like Spring. It is an open invitation to a cold start.
  • HTTP based communication has less cold start overheads than HTTPS-based communication as HTTPS-based communication needs TLS handshake, loading (read, parse and verify) tons of security-related classes, initialization of security components (ciphers, etc.).
  • Keeping your containers warm. One of the strategies to keep AWS Lambda warm is by using CloudWatch. Just ping your Lambda function every 5–15 minutes to keep it warm.

Analysis: By keeping Lambda warm using CloudWatch with the scheduler of every 5 min, it takes only 300ms for a sign-up API during cold start, though keeping Lambda warm increases the cost of AWS service as it hits each lambda function in every 5 min.

Cold starts can be optimized by cutting down the duration, increasing the memory settings for the function, keeping the containers warm, and minimizing the duration and the number of times they occur. This will help in solving the issue which might become a deal-breaker in certain use-cases and apps.


Leave a Reply

Your email address will not be published. Required fields are marked *