AWS Lambda pricing and optimization guide

AWS Lambda is a classic example for serverless cloud technology, or function as a service (FaaS). This technology allows users to run their applications without any provision or management of servers.

In this article, we’ll walk through the pricing structure of AWS Lambda and discuss how we can efficiently manage and optimize its costs—without having to compromise on the performance and operational excellence of Lambda functions.

About AWS Lambda

AWS Lambda is an Amazon service used for serverless computing. It has gained massive popularity due to its many benefits, such as low-cost hosting charges, better code maintenance, automatic scaling, and optimized performance. Owing to these features, more and more organizations are moving their production code to serverless architecture using AWS Lambda. However, if not handled and maintained properly, Lambda can become a very expensive choice for a project.

Lambda is one of the most popular options for serverless functions hosted and maintained on the cloud. These single-purpose, programmatic functions help achieve near-perfect runtime performance and optimal scaling to any number of requests.

Lambda can be adapted to various use cases across established enterprises and startups alike. It can be used to run any type of mobile or web-based application, build efficient machine learning models, process data while scaling, or build event-driven applications. It offers users all this without the need to worry about the provision and management of servers.

For each account, AWS also specifies the limits for compute and storage resources to run and store Lambda functions. These limits apply to various resources, including the storage for uploaded functions; the number of concurrent executions; quotas for function configuration and deployment; and execution parameters like timeout, Lambda layers, environment variables, and burst concurrency.

Understanding the pricing structure of AWS Lambda

A Lambda function request begins when its code starts to execute in response to an event triggered from a source like AWS SNS, calls from AWS API Gateway, or AWS SDK.

The cost of each of these requests is calculated based on various configurations of your account and the Lambda function itself.

AWS offers its customers three main pricing options:

• Free tier: Like other AWS services, using AWS Lambda is free to a certain point. This tier allows up to a million free requests and 400,000 GB-seconds compute time every month, which can be utilized by functions powered by both x86 and Gravitation2 processors.
• Lambda on-demand: This option follows Amazon's pay-as-you-go pricing model, where users pay for actual AWS Lambda usage only.
• AWS Lambda Savings Plans: These plans offer lower prices on AWS Lambda usage, provided that you make a commitment to consistent use over a one- or two-year term. These plans can reduce Lambda costs by up to 17%.

The Lambda on-demand pricing plan is the most popular option and the one that fits the needs of the majority of customers, therefore we’ll use it as the basis for this article.

Being a serverless function, Lambda runs only when triggered. The three core contributors to the cost of running a Lambda function are:

• Total executions or invocations in a month
• Execution duration in milliseconds
• Lambda functions allocated with memory that ranges from 128 MB to 10,240 MB

You can also set the maximum memory size and maximum execution time of function for each of your Lambda to have better control over costs. The more memory is provisioned, the more CPU the function gets.

Apart from the above three factors, another one that affects the cost of a Lambda function is a feature called Provisioned Concurrency, which AWS introduced to have greater control over start-up latency when Lambda functions are triggered. Provisioned Concurrency helps solve the problem of cold starts and works great for applications and workloads requiring low latency, such as games, mobile backends, and complex transactions.

Before we move on to discuss the price that each aspect of a Lambda adds toward the overall costs, we need to understand the GB-seconds unit, as this is the main unit AWS uses to compute Lambda costs. GB-seconds are defined by the following formula:

Fig. 1: Calculating Lambda GB-seconds

The amount of memory that is allocated to the Lambda function will be a deciding factor for the duration cost. For more detailed pricing according to the memory allocated, refer to this pricing guide.

Note that the free-tier pricing is not applicable to Lambdas with Provisioned Concurrency enabled. If you have Provisioned Concurrency enabled, then prices would change as follows:

Apart from the above, you may incur data transfer fees for Lambda. The pricing for these will be charged according to AWS EC2 data transfer rates.

Calculating AWS Lambda costs

AWS provides an easy-to-use pricing calculator for estimating Lambda costs. It contains all configurations that contribute toward Lambda costs. To start calculating costs, it requires the following basic information:

• Region: the geographical region where the Lambda is configured
• Include or exclude Lambda free tier: in other words, whether to include or exclude Lambda free-tier limits in cost calculations. This decision can depend on various factors, such as account type, AWS account configuration, or existing Lambda functions. Users can make this decision according to their individual use case.

The next section of the calculator covers basic service settings. Here you’ll need to enter the below information:

• Architecture: x86 or Arm architecture
• The number of requests: Select the appropriate metric, for example per minute, per second, or per day—basically any metric that helps closely approximate the total number of requests in a month.
• Duration of each request (in ms): the average duration of each request (no need for an exact value, but the closer the better)
• Amount of memory allocated: the memory allocated for your Lambda to work. Enter a value between 128 MB to 10 GB.
• Amount of ephemeral storage allocated: This is extra storage you may need for your Lambda function to work. The first 512 MB are free. You can enter any amount between 512 MB to 10,240 MB.

The example in Fig. 2 uses the following parameters to estimate Lambda costs:

• Architecture: x86
• Number of requests: 1 million/minute
• Request duration: 10 ms
• Memory allocated: 512 MB
• Ephemeral storage allocated: 512 MB

Fig. 2: AWS Lambda price calculator

In the above output, the calculator shows that the total cost of our Lambda is $12,410.01. Moreover, it also shows the exact steps taken to arrive at this calculation based on the given parameters.

Optimization

The flexibility of Lambda applications over traditional ones provides multiple options for optimizing an application’s execution costs and resource expenditures. In this section, we’ll cover some common methods for optimizing AWS Lambda costs.

Minimizing Lambda usage

We can make sure not to use Lambda functions for basic transformations. For example, when building an application with API Gateway, we can simply leverage the Velocity Tempting Language (VTL) supported by API Gateway instead of unnecessarily exploiting the full power of Lambda. VTL isn’t straightforward and has limitations when compared to Lambda functions, but it doesn’t incur extra costs like Lambda does.

Writing concise Lambda functions

The time it takes to execute a Lambda function is directly proportional to the amount being charged for it. So the goal here is to make Lambda functions small and purpose-centric. A Lambda function that executes in half the time will cost you only half the money. For example, if a Lambda function is created to get some code from S3 when the application starts, Lambda will take much more time to download 1 GB of data than to download 1 MB of data. This waiting time will create unnecessary costs.

Caching Lambda response

Lambda functions are charged as per use—the Lambda function should only be called when it’s needed. There are various caching methods for Lambda functions that can have a significant impact on AWS Lambda pricing. We can add caching on the server-side in Lambda functions or on the client-side in the front-end to reduce cost. There is one more benefit of caching in addition to cost-cutting: We’ll get faster responses, because now the request doesn’t have to travel through the Lambda function all over again.

Optimizing memory allocation

It is important that the right amount of memory is allotted to Lambda functions. AWS doesn’t allow customizing the CPU for Lambda functions, but you can customize the computing power by setting the memory allocation. This means that with single-processing applications, we can cut the memory short for cost saving.

Using CloudSpend to optimize Lambda costs

CloudSpend is a ManageEngine tool that helps organizations efficiently manage their cloud resources. Its IT Automation feature allows auto-stop idle or non-productive cloud resources, or some user-defined actions to be triggered for them.

CloudSpend also provides a feature called Forecasting for right-sizing resources and improving the performance of the cloud infrastructure based on historical usage trends. And with CloudSpend’s Spend Analysis tool, you can get the cost split up based on service, region, account, resource, or instance type, as well as gain insight into minimum and maximum spending amounts.