One of the key motivators in pursuing a serverless architecture with AWS Lambda is reducing infrastructure costs. In the early stages of your application, leveraging a serverless architecture to reduce costs can free up precious resources that allow you to add additional value, more quickly growing your user base and reaching product-market fit.
However, as your Lambda application scales your operational costs will scale with it – potentially eclipsing the cost of maintaining a traditional web application entirely. This gives rise to a basic question – how much does an AWS Lambda application cost, in comparison to a traditional client-server model? What about when compared with a container-based microservice application? Read on to find out.
In this article
Here are the key elements that affect AWS Lambda pricing:
Learn more about AWS Lambda in our guides:
Here are the primary details of AWS Lambda pricing. Prices below reflect the charges in the US East (N. Virginia) region and are correct as of the time of this writing. For up-to-date pricing and additional details see the official pricing page.
AWS Lambda pricing is structured to reflect the resources consumed by your functions. Here’s a detailed breakdown:
Request charges
AWS Lambda charges a flat rate of $0.20 per 1 million requests. This fee applies after a monthly free tier of 1 million requests has been exhausted. The charge is consistent regardless of the architecture or region.
Duration charges
Duration costs are calculated based on the amount of memory allocated to your function and the length of time it runs. AWS measures duration from the time your code begins executing until it returns or terminates. The duration is rounded up to the nearest 1 millisecond, with a minimum execution time of 1 millisecond.
AWS offers different pricing tiers for the duration based on the total monthly usage and the architecture (x86 or Arm). For example:
x86 architecture:
Arm architecture:
Memory allocation
Memory allocation for AWS Lambda functions ranges from 128 MB to 10,240 MB, adjustable in 1 MB increments. The cost per millisecond increases with higher memory allocation. Here are a few examples of the pricing per 1 millisecond for different memory sizes within the first pricing tier (up to 6 billion GB-seconds per month in the US East (Ohio) region):
Consolidated billing
When using consolidated billing in AWS Organizations, the pricing tiers are applied to the aggregate monthly duration of functions running on the same architecture, in the same region, across all accounts in the organization.
Ephemeral storage in AWS Lambda is billed based on the amount of storage allocated and the duration of the function’s execution, measured in milliseconds. Each Lambda function receives 512 MB of ephemeral storage at no additional cost. Additional storage can be configured between 512 MB and 10,240 MB in 1 MB increments.
Pricing breakdown
Ephemeral storage is priced at $0.0000000309 per GB-second. This means you pay for the storage multiplied by the execution time.
Provisioned concurrency enables AWS Lambda functions to initialize and remain ready to respond with minimal latency. This feature incurs additional costs based on the concurrency level and duration for which it is configured. Here’s a detailed breakdown:
Pricing model
Provisioned concurrency costs are calculated from the time it is enabled until it is disabled, rounded to the nearest five minutes. The cost depends on both the memory allocated and the concurrency level specified.
x86 Architecture:
Arm Architecture:
Note that the free tier does not apply to functions with provisioned concurrency enabled.
AWS Lambda functions can return an HTTP response stream when invoked via the InvokeWithResponseStream API or through a function URL using the ResponseStream invoke mode. This feature improves Time to First Byte performance and supports payloads larger than 6 MB.
Charges for using HTTP response streaming are based on the amount of data written to the response stream by your function. The first 6 MB per request are provided at no cost.
Pricing
$0.008000 per GB processed.
Lambda@Edge is an extension of AWS Lambda that runs code closer to the end users of an application. This feature improves performance by reducing latency, as the code executes in response to Amazon CloudFront events across various global locations. Here’s a detailed breakdown of Lambda@Edge pricing:
Request charges
Lambda@Edge counts each execution as a request, with a rate of $0.60 per 1 million requests. This pricing is consistent regardless of the AWS region where the request is processed.
Duration charges
The duration charge for Lambda@Edge functions is $0.00005001 per GB-second. This is calculated based on the amount of memory allocated to your function and the execution time.
Memory allocation can be configured, and costs are measured in 1 millisecond increments.
For example, if your Lambda@Edge function has 128 MB of memory allocated, the duration charge will be $0.00000625125 for every 128 MB-second used.
Amazon EC2 usage is billed in one of four different ways:
Depending on your application’s needs, EC2 can either provide stability that your developers can leverage to create robust web applications, or it can provide on-demand usage billed primarily on computing resources used instead of on the simple presence of a dedicated server.
When comparing with AWS Lambda pricing, it’s important to know the characteristics of your application. While Lambda is billed based upon the GB-seconds your functions use during their execution, EC2 requires you to put more thought into machine design as the costs scale with the specifications of the machine you choose. If you can confidently predict your work loads, as well as your hardware requirements, you can likely optimize the costs of EC2 in a significant way.
However, while the actual resource costs could potentially be lower, your development costs are likely to be higher. With an EC2 instance, you need to fully develop your machine’s content, from selecting a web server to spinning up an application instance via middleware in response to user requests. Compare this to AWS Lambda, where you simply need to write your application’s functionality at the most granular level. The time spent on this by your developers can be significant, as can the associated costs.
Comparing a dedicated machine instance to an ephemeral resource like AWS Lambda will always be very situationally-dependent, but there are a few advantages at the conceptual level that can lend weight to choosing a Function-as-a-Service architecture over a more traditional approach:
For low workloads, AWS Lambda is simply cheaper – particularly if your usage falls within the fairly generous free usage tier. Depending on your specific use case, the reduced infrastructure of a Lambda function can be far superior to an equivalent EC2 instance, which would require additional development and configuration. If you’re not reliant upon a specific operating system in an atomic Lambda function, you can eliminate all of the extraneous configuration effort required to make your code functional – simply deploy the code and go!
AWS Lambda gives you far more granular ways to measure your costs than EC2, which bills based on time instead of based on resource usage. You get a per-execution view into the resources used by your Lambda functions, and can use that data to more accurately predict the cost of future executions. This can allow you to react more quickly to increased demand, allowing you to optimize costs as you develop a complete picture of your application’s behavior.
Building upon the granularity of AWS Lambda functions, you can use the data provided to implement cost-driven logic in your application. Each response includes a report on the resources used, giving you the opportunity to leverage this information to postpone or redirect the more expensive operations in your application to more cost-effective resources dynamically. With some clever arbitrage, you can increase your margins while keeping your execution costs low.
With every execution, you get a clear view into what charges your organization incurred. This data, if fed into pricing models, can be used to mitigate the costs of each request. Coupling this with a dynamic pricing engine allows you to change how much you charge your users based upon their actual resource usage. This cost-based pricing allows you to ensure you’re being appropriately paid for the effort your application performs, instead of relying upon a blanket monthly fee that is only profitable for a percentage of your user base.
While the flexibility of Lambda over EC2 gives you a lot of leeway in optimizing your application’s resource expenditures, the serverless approach introduces some unique challenges to gauging your infrastructure expense levels. These disadvantages can add unpredictability to your application’s running costs if not carefully monitored and managed.
One of the hardest parts of optimizing an application is finding out exactly how many resources your application consumes. This is doubly challenging in a serverless environment, as each application path can include an indeterminate number of Lambda invocations. This complicates cost forecasting, adding confusion to infrastructure budgeting.
Cost Explosions
Lambda can be very susceptible to cost increases due to heightened usage. While ideally this heightened usage can result from an increasing user-base, lending some predictability to the growth, there are several scenarios where you can end up with a large bill with very little warning. DDoS attacks, for example, can very quickly drive your AWS Lambda bills through the roof, since each individual request involved in the attack costs you additional money.
Setting aside the potential for nefarious actors, simple development bugs can result in greatly inflated costs if your developers, for example, add an infinite loop or fail to make use of caching. Even with good development practices and solid application security, you can also end up with inflated costs due to the configuration of your Lambda functions – allocate too much memory to your function, for example, and your costs can scale very quickly.
Building a robust serverless application doesn’t stop at the invocation of your Lambda functions. You need services to store user data, additional development and maintenance load for the disparate functions of your application, and so on. Each of these elements has the potential to increase your costs in a way that wouldn’t necessarily be present in a more traditional EC2-based application.
Take, for example, data storage – with an EC2 instance you could potentially co-locate your database server with your web server using a tool like Docker. With AWS Lambda, however, you’ll need to pay for any data transfer to different AWS regions, and then pay for the storage costs on top of the pure data transmission expenses.
Microsoft Azure Functions are billed at a very similar level to their AWS Lambda counterparts. Both services grant you one million free requests per month, and charge $.20 per additional million requests. However, Azure gives you a slight cost advantage for aggregate resource usage. AWS Lambda bills at $0.0000166667 per GB-second, while Microsoft Azure Functions are billed at a flat $0.000016. This difference is indeed small, but over time adds up to a price savings of $0.67 per million GB-seconds of execution.
Google Cloud Functions have some unique billing considerations when compared against AWS Lambda. Where AWS Lambda gives you one million free requests, Google Cloud Functions are given two million. Once you’ve exceeded this free tier, Google Cloud Functions will cost twice as much as AWS Lambda ($.40 per million for GCF, compared to $.20 per million for AWS Lambda). In terms of resource usage, Google takes a unique approach in splitting out processor and memory usage into separate cost categories.
OpenFaaS takes a markedly different approach to AWS Lambda, making it difficult to compare costs. Where AWS Lambda provides you with all the infrastructure you need to execute your functions, OpenFaaS focuses on giving you the execution infrastructure in a hosting-independent fashion. This means that you have to pay to host your functions yourself, rather than relying on the pure usage-based pricing offered by AWS and other providers.
Ultimately this will become a similar comparison to our earlier EC2 vs AWS Lambda section. However, for this extra cost you are gaining a provider-independent platform for your serverless functions. This helps you avoid the vendor lock-in that would be inherent in choosing a provider like AWS, and gives you the ability to more easily transition your serverless framework to a new hosting provider if the costs make more sense.
One of the great benefits of a serverless architecture is its general resiliency when scaling. Instead of needing to allocate and deploy additional servers, the serverless provider manages that complexity on your behalf. While this is a significant benefit for application responsiveness and performance, it has the potential to create a severe impact with your next month’s AWS bill. It’s important to recognize how your lambda functions are being used, and by which triggers in the AWS ecosystem. Services that issue a lot of triggers will lead to a lot of invocations of your functions, increasing compute usage and, eventually, your infrastructure bill.
Predicting and responding to these changes in pricing is crucial to ensuring you can get ahead of significant resource usage before it occurs. Each Lambda function response includes information about its execution, statistics which are also pushed to CloudWatch. This information can be used to predict traffic levels and allow you to react to cost-incurring events as they occur. An automated approach is highly-recommended, as predicting sudden bursts of activity in an application is nearly impossible – by writing a script to automatically parse execution data out of your application’s function responses, you can build a predictive model that allows you to set thresholds and alerting. Some open-source projects already exist to provide this information – Concurrency Labs offers a couple in their GitHub repo, for example.
With the flexibility of a serverless application, you gain another benefit over a traditional application when it comes to optimizing your execution costs. The granularity of AWS Lambda billing – and the frequency with which you are given the relevant information – gives you a lot of flexibility in optimizing your application’s resource usage. Below are a few strategies you can use to reduce your infrastructure costs and increase your serverless application’s profit margins.
One of the oft-ignored costs in AWS Lambda development is the cost in data transfer between AWS regions. If your application relies upon AWS resources spread across multiple regions, you’re paying for the data transfer between those services. Moving your Lambda functions to the same region as the resources they depend upon can greatly reduce your data transfer costs, allowing you to focus on the cost of execution alone.
The granularity of Lambda billing gives you great visibility into how much individual function calls are costing your organization. This information is invaluable in optimizing your Lambda costs, as it allows you to quickly identify the financial pain points in your call stack. By using this billing data as a driver, you can accurately identify functions in your stack that seem to be doing more work than necessary, giving you a refactoring opportunity that has significant cost advantages. Additionally, using this approach you can combine groups of independent functions into larger modules, reducing duplicated effort and centralizing costs.
Simply put – if your code is not executing, you aren’t being charged. A solid caching approach can also have a significant effect on your AWS Lambda execution costs.By adding caching to your serverless functions, or performing client-side caching in your front end code, you can reduce your costs simply by performing less work – particularly if your operations are atomic and well-defined.
Lumigo is a serverless monitoring platform that lets developers effortlessly find Lambda cold starts, understand their impact, and fix them.
Lumigo can help you:
Get a free account with Lumigo resolve Lambda issues in seconds
