Breaking down AWS Lambda pricing structure : You have a great idea, you need to implement it and bring it to life? You have to pay the costs of the software development life cycle. But to select and proceed with a technology or a solution architect, it is important that you understand the cost (visible and hidden) involved. The architectures designed on abstractions like containers, orchestration and serverless (FaaS), the most recent one, increase the development velocity and reduce complexity and cost, which is the main motivation to pursue a serverless architecture. It’s most important in the initial stages of application growth, where the user base is still expanding and the app’s resource usage is markedly lower than any fully-mature app.
Why serverless? It’s a great choice because you only pay for what you use and there are no pre-set packages of which you need to pay for something that you might not use at all. Leveraging serverless will free up previous resources which allow you to add additional value, growing your user base more quickly and reaching product-market fit. Though, the cost of running the application depends on many factors like the choice of database, hosting, app adoption, etc. As your app scales, your operational costs will scale with it. Which means, the complexity of the cost of an application implies that the companies cannot rely on their development teams to make that decision and need a hands-on decision maker. However, with AWS Lambda you can somewhat control the costs and make your product see the light of the day without the costs snowballing.
In this blog, we will help you get an understanding of AWS Lambda pricing and how it’s calculated. We will discuss the pricing structure of AWS Lambda, the cost of its infrastructure and help you get a better understanding of the relationships between configuration and cost to help you build strategies to optimize both performance and cost.
AWS Lambda is a computing platform that lets you run codes without provisioning or managing servers. It’s serverless, so there’s no cost incurred when the code is running. It’s basically a code that runs in a temporary container which terminates when its purpose is served. Based on these invocations, you pay only for what you use. That is, when the code starts running in response to an event, the request is counted and the cost is determined on the total number of requests across all the functions used. Each one of the Lambda functions is configured based on the memory size (GB) and the execution time (which is measured in milliseconds)
AWS Lambda contains 263 separate billable line items, in which each item has its own price. The configuration of a Lambda function is quite simple and consists of specific memory allocation and a timeout value. The allocation of CPU capacity is done proportionally to the amount of memory allocated. Thus, increasing memory allocation means increasing CPU allocation, which improves the performance of a processing-intensive function. Let’s see the general AWS Lambda pricing model:
This is the maximum memory size configuration which you allocate to the function from the AWS console. It’s not the actual memory, which means you can reduce the function’s memory but it’s suggested to not tweak this configuration as there won’t be any noticeable cost reduction.
AWS charges $0.20 per 1 million requests after a free buffer gets consumed and the usage cost is billed GB/seconds i.e., number of GBs of memory allocated to a task per the seconds it runs. The first 400,000 GB-seconds of activity is provided for free and a small aggregated price is charged afterwards.
This is the actual time that your function takes to execute its code logic. For instance, if a function is making an ongoing call and is waiting for a response, the time spent idle will be counted as well in the execution time. The overall duration of the function is calculated from the time the code begins executing, until it terminates or returns, rounded up to the nearest 100ms. The larger the memory size, the more each 100-millisecond block will cost. Up to 3.2 million seconds are free and you get charged after you have used this time.
The cost of each function is calculated by multiplying both of these values together, which produces a unit GB-sec. Where the current AWS Lambda pricing –
Note that each invocation might have to start a language runtime and load third-party libraries before getting to the user code and all of that adds to the function’s billable runtime for every invocation.
Look at the chart demonstrating the cost of executing 100,000 invocations over the varying time.
Let’s say you allocate 3008 MB of memory with the limit of 136,170 seconds/month in your free tier provided by AWS. You would need to pay $0.000004897 (USD) per 100ms.
Yes, there are some extra charges involved in the AWS Lambda pricing model that you need to be aware of. You will be charged regardless of the tier you choose. For instance, if a function is reading and writing the data to or from Amazon S3, you’ll be charged for those read/write requests alongside all the data that gets stored within Amazon S3. And if your function starts the external data transfer i.e., outside the region, you’ll be billed at the EC2 data transfer rate.
Now let’s say you allocate 512 MB of memory to the function and execute it 3 million times during a month. In this case, considering that the code ran for 1 second every time, you would be billed on a monthly compute time i.e., $18.34 and the monthly requests $0.40. So, the total bill would be $18.74 / month.
By now, you must get the basic idea of how the AWS Lambda pricing works. Now let’s compare the charges with EC2. The setup costs of Lambda is comparatively easy but let us examine both for two different cases –
Let’s say there are 10,000 hits per day (over 24 hours)
And the execution time is 200ms per hit
Memory’s 512 GB
Which will result in 432,000 requests/month and 2160 GB-sec of execution time/month.
Considering this case, the total cost would be $0.31 per month.
But this is the 1/10th cost of what the smallest EC2 instance t2.nano would charge you. Higher EC2 prices occur due to the running time for 24 hours and the cost is multiplied by 24 in EC2 billing.
Let’s say you’re running 2 nano instances –
$0.0059 * 24 * 30.5 = $4.31
$0.05 * 8 GB = $0.40
The total cost for each of these would be $9.42 ($4.71 each). Autoscaling group needs Elastic Load Balancer, which would cost $0.0225 * 24 * 30.5 = $16.47
What would be the cost for Lambda?
Since the call cost is $0.20/million requests. It means there would be 0.4 requests per month and the cost would be $0.00001667/GB-sec.
API Gateway is what ties serverless functions and API definitions together within the serverless ecosystem. It’s important because it triggers the execution of the function directly in response to the request, enabling a true serverless architecture for the applications. API Gateway facilitates normalizing access points for the system functions, including monitoring and security. This brings more scalability to the serverless model, it involves low maintenance and low cost.
With this aggregated service, you can tackle security, orchestration and transformation of microservices. Moreover, it forwards requests only that are authorized and authenticated.
Amazon API Gateway charges you for only the APIs which are in use and there is no upfront fee.
Costs –
Here’s what you might be charged for, apart from Lambda function costs i.e. the resources you might occupy for your project –
The current pricing of API Gateway is $3.50 per million requests, plus the data charges.
The pricing for DynamoDB includes permanent free tier up to 25 write units and 25 read units, which means you don’t have any charges for that. The only cost you’ll be paying is a 1 GB database with strong data consistency.
S3 will be storing the static content like HTML, CSS and Java and the cost for standard storage of S3 is $0.02 for 1 GB.
The CloudWatch bills you for service coming from logs being sent to CloudWatch Logs & the storage of the logs. These logs get generated by the Lambda function execution and by API Gateway execution. You can optimize and control the logs you need to generate from the Lambda function.
The major cost drivers for the serverless would not be AWS Lambda, rather are from API Requests, Storage and the network transfers.
Let’s look at the hidden costs!
As discussed earlier, API is significant for the application and it will cost you around $3.50 per million executions.
If you are sending data in or out, you need to carefully monitor its cost. At $0.50 – $0.90 per GB-out and $0.1 – $0.2 between VPCs or regions on AWS.
For each new functionality that’s added to the software system, the number of lines of each function that are needed to maintain the software’s functionality grows.
Cold start increases the compute time so it is directly proportional to the costing. There’s an added latency of 100 milliseconds.
Your serverless application would include databases, storages, network cost, APIs, data processing systems and more. Considering the percentage of Lambda cost to the overall app’s cost, you’ll have to see whether it’s worth running cost optimisation.
One of the greatest benefits of the serverless architecture is its resiliency while scaling. AWS manages the complexities of allocating and deploying on your behalf, keeping the application responsive and maintaining its performance. Though it impacts the bill so you need to know how your Lambda functions are being used and by which triggers. Each function’s response has information about its statistics, execution that is also pushed to CloudWatch. You can use this information to predict traffic levels and react to cost-incurring events as they occur. You can build a predictive model which allows you to set thresholds and alerting for execution data of function’s responses.
When it comes to optimizing the execution costs, you can gain another benefit with the flexibility of a serverless app. You can optimize the application’s resources usage and here’s how you can reduce the infrastructure cost –
Move your Lambda function to the same region as the resources that they depend on to reduce the data transfer costs.
With the information of individual function calls costs, you can identify the financial pain points, refactor them and optimize the Lambda cost. You can combine the groups of independent Lambda functions into larger modules and reduce the duplicated effort, centralizing the costs.
You can reduce costs by adding caching to your functions, or performing client-side caching in your front end code. Perform less work if the operations are atomic/well-defined.
There are some advantages that weigh people into choosing a FaaS (Function-as-a-Service) architecture i.e., AWS Lambda over traditional approaches and while there’s flexibility which gives you the option to optimize the app’s resource expenditure, we cannot ignore the challenges you’d face with Lambda. Let’s look at both –
If your usage falls within the free usage tier provided by AWS Lambda, it can be really cheap. And if you don’t rely upon a specific OS in an atomic function, you can eliminate the extra configuration efforts and simply, deploy the code and go.
You get a pre-execution view of the resources used by Lambda functions and can use the data to predict the costs and optimize them as you develop an understanding of your app’s behaviour.
You can implement the cost-driven logic in your app. With the report of resources used, you can postpone or redirect the expensive operations to more cost-effective resources dynamically.
It allows you to ensure you are being appropriately paid for the efforts your app performs, instead of relying upon the monthly fee blanket that’s only profitable for a percentage of your customer/user base.
Finding out how many resources the app consumes is not easy and as each app’s path can include an indeterminate number of invocations. This adds confusion to the infrastructure budgeting by complicating cost forecasting.
There can be several scenarios where the costs can go through the roof with very little warning. Moreover, development bugs can inflate the costs too. Even with good development practices and security, your bills can be higher due to the configuration of Lambda functions.
To build a robust app, you need additional resources for development and maintenance etc., each of which can increase your costs. Data storage with AWS Lambda, for instance, you need to pay for data transfer to other regions and then pay storage costs as well.
AWS Lambda is a powerful tool to help you get your application on its feet early and when compared to traditional client-server architectures, you’ll realize that there’s a significant cost saving in the software development cycle and launching stage, with AWS Lambda, simply because it lets you restrict the charges only to the resources you’re using. Serverless provides a huge potential in time and cost saving if done right. There are ultimate scalability and pay-as-you-go pricing models and with careful analytics, you can more effectively optimize your app’s running costs, respond to cost increases more quickly and minimize the organization’s infrastructure budget.
aTeam Soft Solutions can help you migrate to Serverless, build Serverless applications, and train your team on the best practices in Serverless. We offer customized, scalable, robust and highly secure AWS (Amazon Web Services) development services to carve the future of your business.
With the right guidance and an experienced software developing partner, you can bring your envisioned ideas into existence and we are here to provide you just what you need to turn your idea into a refined product.
We look forward to serving your requirements. Contact our team today!
