Tag: AWS Lambda

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.

Execution Time

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

Observations

• 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
• DynamoDB
• 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

3. DynamoDB

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:

API Requests

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.

Networking

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.

Code Maintenance

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 Starts

Cold start increases the execution time. It is directly proportional to the costing.

Function Monitoring

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:

Manual Approach

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.

Cost Explorer

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:

• Epsagon
• Thundra
• Dashbird
• Stackery
• IOpipe

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.