AWS Lambda: How to Improve Performance & Reduce Cost

April 16, 2018 |

Many organizations struggle to achieve both cost savings and improved performance using AWS Lambda. By the time they have implemented their functionality using Lambda, they are faced with unforeseen AWS Service costs. While AWS Lambda services can be advantageous, there are certain aspects of Lambda functions that should be considered early before implementing production code using this service.

Let’s start by addressing the most cost-efficient functionality from a use case perspective. We consider two scenarios:

  1. Customers who want to migrate to the cloud (Migration Use Case)
  2. Customers who want to build in the cloud (Development Use Case)

Our recommendations are applicable to both scenarios and can be readily applied for refactoring as well as (re)development.

Under the Migration Use Case, the traditional approach of “lift and shift” migration doesn’t work. Lifting the code currently executing in data center machines and executing it as a Lambda function requires a different development methodology that includes code refactoring.  The difference stems from the manner a Lambda function needs to be designed, not the use of a different programming language.

Migration & Deployment Options

Apart from AWS’ published best practices, there are a few recommendations to note while refactoring or developing AWS Lambda functions:

  • No global state: Developers struggle with the concept of no global state maintained between two invocations of a Lambda function.  A useful avoidance tactic is to divide code into its smallest unit and then implement it. Design principles like Single Responsibility Principle and Keep It Simple Stupid can offer insight in achieving this objective.
  • Execution Model: Under the hood, AWS Lambda uses containers to satisfy the compute and memory requirements of a Lambda function. These containers are efficiently re-used for multiple Lambda function invocations, in turn allowing the re-use of certain memory variables. For example, the ‘/tmp’ location present under the container OS can be accessed over multiple invocations of a Lambda function. For further details see AWS Lambda Programming Model and AWS Lambda Execution Model.
  • Function Invocations: An AWS Lambda function can be called upon multiple times in parallel, making it a popular choice for concurrent invocations. As the number of functions used concurrently is often high, it’s important to understand the way a Lambda function is invoked and how (if at all!) AWS Lambda handles the errors in case of failures. Indeed during a recent proof of concept we noticed that a Lambda function was invoked more than a million times a day without generating any successful output. Refer to the Invoking Lambda Functions page for details on when and how Lambda functions are getting invoked.
  • Virtual Environment: Using virtual development environments like PythonLambda, NodeLambda, etc. to locally develop and test AWS Lambda functions can help to reduce costs. These (or any similar) development environments allow implementation of AWS Lambda functions without actually deploying them to the AWS Lambda Service in the Cloud.
  • Unit testing: Having a good set of unit test cases with approximately 80% coverage is considered normal for software development, but with AWS Lambda functions, it is equally important to have test cases written for negative scenarios as well. tests for failure scenarios, which if not addressed could obviously result in additional cost. Refer to the Invoking Lambda Functions page for details on how failed executions of a Lambda function are handled in individual invocation types.

For additional information on developing AWS Lambda functions, check out these blogs:

Despite our recommendations above, AWS Lambda still might not be suitable for certain deployments. Before fully implementing a requirement as an AWS Lambda function, it is always a good idea to consider and compare the deployment using a traditional approach, e.g. using EC2. The AWS Simple Monthly Calculator is also a helpful tool that can be used to determine the potential costs for deployments.

Here are few articles we suggest to further your understanding on saving costs and improving performance in the AWS Cloud:

Other Blog Posts

Blog

Top 5 Reasons to Utilize Cloud Computing in Financial Services
Read More
Blog

Is Migrating to the Cloud Safe for Financial Sector Companies?
Read More
Blog

REAN Cloud is one of the few AWS Premier Partners to achieve both AWS DevOps Competency and MSP Designation
Read More
Blog

7 Ways DevOps Can Save Your Company…Time and Money
Read More
Request Consultation
close slider