Synopsis: The ultimate purpose of this blog is to ascertain the AWS Lambda cost strategies and to prevent unexpectedly large AWS Lambda bills. Go ahead and check out how AWS stands apart from those rental virtual machines and the price changes that happen due to the API Gateway. After reading this blog you will be capable enough to determine the cost estimation of running a serverless application and also the inevitable cost optimization strategies.
Besides procurement, the study of the cost has become one of the most crucial factors of the software development life cycle. Every solution architect must understand the nuances of choosing any specific technology. Software architectures created on abstractions such as containers, orchestration, and with the current serverless (FaaS) amplifies the growth velocity and shrinks complications and costs.
The overall cost of running applications is based upon several factors such as database choice, application adoption, hosting, etc. Companies need experts who provide quick and practical decisions to handle the cost complexities that cannot be given completely to the development teams.
AWS Lambda Pricing is pretty direct and open. However, the cost of running a serverless application is much complex and challenging as compared to other aspects.
Table of Contents
What is AWS Lambda Pricing
AWS Lambda is one of the highly refined series of cloud technology products that you can purchase. Also renowned as serverless or function-as-a-service or FaaS. To make it simple, it is a piece of code that runs in an ephemeral container that gets terminated after serving its purpose. These are invocation tasks through which you pay only for what you use. Every single Lambda function is configured depending on the size of the memory in GB and the execution time in milliseconds.
The Pricing Model
Memory Size (GB)
From the AWS console, this will be the maximum memory size configuration that you can allocate to your function. The function does not use this memory always, as this memory is not the actual one. Even when you reduce the usage of function memory but do not tweak this configuration, you will be unable to have any cost reduction.
The actual time that a function takes to execute its code logic. For eg., if your function is making an outgoing call and awaits the response, the idle time also gets counted in the function’s execution time.
The overall duration of the executing functions gets calculated from the time your code begins execution. Unless it returns or gets terminated, and rounded up to the nearest 100ms.
The cost of each function is calculated by multiplying both these values together to produce a unit in GB-sec. Since GB-sec is dependant on several unpredictable factors. Here’s a chart that shows the execution cost of 100000 invocations of a Lambda function over varying time. You will observe that the execution time of the ,Lambda function depends on the language runtime and 3rd party dependencies.
Note: GB-sec is just a composite unit used to measure AWS Lambda offering. Nor does it showcase gigabyte nor a second. The current price of AWS Lambda is
- Compute charges: $0.00001667/invocation
- Request charges: $0.2/M <requests
AWS Lambda Pricing vs EC2
A brief comparison of the charges between the two varied use cases:
Low Compute Use Case
The following scenario can be taken for the application. The use cases can be such as CRON jobs, transform and upload, read/write to DynamoDB, etc.
- Allocated memory 512 MB
- No. of invocations: 20,000 times/month
- Execution duration: 1 sec
AWS Lambda Pricing Calculation
GB-sec = 20,000 * 512/1024 = 10,000 GB-sec
Compute charges = 10,000 * $0.00001667 = $0.1667
Request charges = (20,000/1,000,000) * $0.2/Million = $0.004
Total charges = $0.1667 + $0.004 = $0.1707
EC2 Pricing Calculation
Even if we consider the smallest available on-demand instance t2.nano, the monthly cost would be $5.832
High Compute Use Case
The following scenario can be taken for the application. The use cases can be ETL jobs, real-time data processing and video processing.
- Allocated memory 2496 MB
- No. of invocations: 30,000,000 times/month
- Execution duration: 500 sec
AWS Lambda Pricing Calculation
GB-sec = 30,000,000 * 0.5s * 2496/1024 = 36,562,500 GB-sec
Compute charges = 36,562,500 * $0.00001667 = $609.5
Request charges = (30,000,000/1,000,000) * $0.2/Million = $6
Total charges = $609.5 + $6 = $615.5
EC2 Pricing Calculation
Considering this as a high-end compute work, even if we consider m4.large with 8GB memory, the monthly cost would be $138.2424
- On-demand instances are suitable options. Lambda is designed for the functions that can be executed rapidly after being triggered by the events.
- You can avail of the on-demand EC2 instances by spinning up the container manually each time a function gets called.
- A high amount of processing overhead gets added up and makes the function slow.
- If at all you want to use EC2, you need your instance readily available and waiting for the triggering event. That means, a 100% instance usage per month.
- The real backbone behind Lambda’s pricing model is that your functions are not going to run 100%. Lambda remains at its best at around and below 3 million function executions per month.
- If your traffic gets ahead of 3 million, then it’s time to move to EC2. Before that, you can consider the next observation.
- From the viewpoint of use cases, AWS Lambda and EC2 have varied implications. AWS Lambda becomes a perfect fit for low compute use cases like serverless authentication, CRON jobs, Alexa skills, etc.
- High compute resources are used for use cases such as real-time audio/video transforming, ETL jobs, etc.
- No one size fits all use cases and so tried and tested approach becomes the best
Amazon API Gateway Pricing
Amazon API Gateway charges for used APIs without any upfront fees. Pay for the number of API calls you receive and the amount of data transferred and caching. As an example:
- Charges for API Calls: $3.50 per million API calls received.
- Data Transfer Costs: First 1 GB free then $0.09/GB for next 9.99 TB.
For example, a regional API received 5 million API calls per month and each API call returns responses of 3 KB in size without caching.
- Amazon API Gateway API Calls charge: 5 million * $3.5/million = $17.50
- Total size of data transfers: 3 KB * 5 million = 15 million/KB = 14.3 GB
- Data transfer charges: 14.3 GB * $0.09 = $1.29
- Total Amazon API Gateway charges: $17.5 + $1.29 = $18.79
API Gateway Significance in Serverless Apps
API provides a value-add to the serverless functions by taking care of normalizing access points for system function. This includes security and monitoring. In consideration of the viewpoint architecture, APIs assist in functioning bridge service modeling among the systems. This is done by acting as an HTTP of, an endpoint to trigger your functions.
API Gateway enables collection of function in a manner that they look like a single API developed to meet the specific application requirements. This approach enables tackling the load of security, orchestration, and transformation of the microservices. Moreover, it works as a gateway to forward requests only for those that are authenticated and authorized.
Price Calculation of Serverless App
The serverless costs exceed pay-per-trigger. Here we shall analyze the running cost of a demo serverless application and find out how much AWS Lambda and other services cost in actual sense. As a demo app, we will analyze the Voting App. The architecture is as below:
Taking you through the charges that are incurred for utilizing the below services:
- API Gateway
- AWS Lambda
- Amazon S3
- CloudWatch Logs
- Network Data Transfer
Voting App served almost 2 million requests per month.
1. API Gateway
The current API Gateway Pricing is $3.50 per million requests, plus data charges. Considering we have 1.5 GB of cache memory and 2 million requests/month, our total cost would be $34.36
2. AWS Lambda
Since most of the compute work is focused on the 60 lines of code that two of our Lambda function executes, this is where I was expecting huge costing. However, it isn’t. Here we have 2 Lambda functions with 256 MB compute memory, serving 2 million requests/month.
Lambda function 1 executes at 400 ms and Lambda function 2 executes at 500 ms. The total cost will be Lambda Function 1 ($0.20) + Lambda Function 2 ($0.20) = $0.40
The DynamoDB pricing includes permanent free tier up to 25 write units and 25 read units. This means we don’t have any charges for that. The only cost that we will have to incur is of 1 GB Dataset with strong data consistency. Hence, the overall cost will be $2.81
4. Amazon S3
This will be storing our static content like HTML, CSS and Java. The S3 cost for standard storage of 1 GB would be $0.02
5. CloudWatch Logs
The CloudWatch costs for the service coming from logs being sent to CloudWatch Logs and the storage of these logs. These logs are generated by the AWS Lambda function execution and by API Gateway execution. You can control how many logs you need to generate from AWS Lambda and hence optimize accordingly.
Our demo app ingests 200 MB of data every day which is monitored over 3 parameters with archival of logs. All this comes down to 3 GB * $0.50 = $1.5 Plus, storage cost of $0.03/GB = $0.09 Hence, total cost = $1.59
What is the actual cost of Serverless?
It comes down to a monthly cost of $50.14 approx. The most amazing thing is there is something more than just CPU and RAM. The majority of people opt for serverless and the main cost drivers would never be AWS Lambda, but API requests, storage, and network transfers.
And everything about the hidden costs is as below:
As discussed in the previous section, it is obvious that our serverless apps are going to be API heavy and its significance is undeniable. This will cost you around $3.50 per million executions.
If you’re sending data in/out, you need to carefully monitor the cost of this. At $0.50-$0.90 per GB-out and $0.1-$0.2 between VPCs/regions on AWS. This has a high chance of getting expensive.
The serverless coding is equal to the maximum code lines. With each new functionality add-on to the software system, the number of lines grows steeper as they are inevitable to maintain the software functionality. Every function has its own logic as the shared code is an antipattern.
Cold start increases the execution time. It is directly proportional to the costing.
AWS Lambda lures the users with its attractive low-cost solutions. This serves as one of the primary reasons behind its faster performance compared to competitors.
However, no matter how much the developers keep a keen eye on the maximum size limit and execution time, there are high chances of costs getting out of your control for an end number of reasons. Some of them are DDoS attacks, excess memory allocation, or a simple bug in your code bundle.
This necessitates the requirement of monitoring function efficiently. The three basic ways you can get started are as below:
Based on the number of functions, it takes from minutes to hours. For example, every single time your Lambda function gets executed, record prints:
Duration: 1000 ms Billed Duration: 500 ms Memory Size: 1024 MB Max Memory Used: 50 MB
The above record print depicts that the function you’ve executed is just using 50MB out of 1024MB. In such cases, you can save money by allocating 128MB. If you go allocating less memory than this, your function might not execute at all.
The development teams prefer higher memory allotment as more CPU means quicker executions and substantially lower costs. And so, the recommended solution is to test and iterate your function’s execution time on different memory sizes.
This approach is the most workable for the team as it has fewer functions since monitoring them becomes easy. Besides, this needs monitoring of functions on regular basis. However, it takes considerable time if you have many functions.
AWS Console provides AWS Cost Explorer. Through this explorer, you can monitor the pricing of various AWS services over a week, month, and quarter. You can also classify based on the region, usage type, tag, name, etc.
If you have tagged your Lambda functions properly, this will ease your monitoring up to a great extent. Also, you can tally the pricing of your Lambda functions and iterate the changes accordingly.
Besides, if you haven’t tagged your function properly, AWS Cost Explorer won’t help much. In such cases, you can leverage CloudWatch Alarms to get a notification when a function exceeds the configured limit.
Even though it helps in monitoring the cost of Lambdas, it doesn’t give you insight into what is wrong and where. This helps only in figuring out whether Lambda costs have increased or not whenever an issue occurs.
3rd Party Tools
Several third-party tools come in handy. They help you with cost optimization indirectly by efficient and accurate monitoring of your AWS Lambda functions. Some of them are:
If you tune your executing time and memory size you will save a lot on computing resources and costs. With that, it becomes equally critical to keep a sharp eye on those functions that can be optimized by tracking its costs in real-time.
AWS Lambda Cost Optimization Strategies
A series of combinations of usage and configuration affects the entire pricing game of Lambda functions. This creates problems often. To avoid such scenarios, a few strategies are recommended below to keep your Lamdba cost in control.
Optimizing Function Frequency
Various factors influence the invocation frequency of the Lambda function. This is completely dependable on triggers. You need to monitor your triggers and find what can you do to deduct the number of invocations over time.
Writing Efficient Code
Those functions that execute in half of the entire time is the one that costs half the money. Execution direction is directly proportional to the amount of money you will be charged. So it becomes very important to keep a watch on the Duration metric inside the CloudWatch. Also, modify and iterate your function if is taking a long time to execute.
Monitoring Data Transfer
While you consider the Lambda charges, most of the time, it gets out of our site that there are charges for data transfer at standard EC2 data transfer rates. So, here you must keep a watch on the amount of data you are transferring out to the internet and other regions of AWS.
The internal data transfer and for the Cloudwatch, you cannot do much about it. For such cases, what we can do is:
- Keenly monitor your AWS Cost & Usage Report. Filter it by Resource (your Lambda function) and find different values in the Transfer Type column. Further, get the usage amount. This might come off as slightly time-consuming.
- Log the size of data transfer operations in your Lambda code and then configure a CloudWatch Metric Filter as a reference that becomes a CloudWatch Metric.
To conclude, tracing your requirements and finding how much it will cost to bring forth your idea into reality, this first step is very crucial towards getting started with serverless architecture.
Remember, No one size fits all! Some organizations mean serverless as the helping hand in cutting down the costs with a huge margin. And some other organizations are probably looking for more integrated options that can help you find the hidden costs of serverless.
Every serverless provider will offer you free tiers that are more than sufficient for you to have a smaller workload. But, serverless can offer a huge potential in cost and time saving if is known how to do it right.
Stay away from surprises and get enough knowledge of the potential of your serverless application. We would love to hear from you about your experiences with serverless costs. Write to us or contact us to share your thoughts.