We’ve shown in detail how complicated AWS pricing can be. From S3 pricing to AWS Redshift and EC2 instance pricing, it’s all too easy to lose yourself in the details, especially when Amazon’s own documentation is so murky.

That’s why we’re here to pull back the curtain on another key element of AWS - AWS Lambda pricing.

Whether you’re operating a serverless website or automating your backups, AWS Lambda is a fantastic way to deal with any of your serverless needs. However, like any other AWS product, it’s vital to stay on top of your costs to avoid getting hit with a nasty surprise bill.

So, in this post we’ll be covering:

• How AWS Lambda pricing works
• AWS Lambda pricing tiers and plans
• Calculating your AWS Lambda costs
• How to manage your AWS Lambda costs

Note that all prices in this article are based on being in the US East (Ohio) region.

How AWS Lambda pricing works

While AWS Lambda pricing isn’t quite the same mind-boggling beast as the rest of AWS, it’s still easy to get lost and miscalculate if you’re not paying careful attention, understand what you’re paying for, and accurately forecast what you’ll be using.

That’s why we’re covering the basics in this section, from what exactly you’re paying for when using AWS Lambda to the sneaky extra charges which can take you off-guard.

The basics of AWS Lambda pricing

Put simply, AWS Lambda pricing makes you pay for what you use. More specifically, you pay for each request you make and for how long it takes to execute your code. The fewer requests and the less time it takes to execute your code, the less you pay.

The key here is that you’re not reserving a set number of requests to be made, or a number of servers to use. You’re paying for your requests as and when they’re carried out, which also means that you aren’t tied into paying for an ongoing amount.

Think of it as paying only for the compute time you consume, with a small charge for each request made.

In terms of paying for that compute time, it’s calculated from the time your code starts executing to the moment it returns or terminates. This is measured to the nearest millisecond, so it’s all very accurate automatically.

Your AWS Lambda pricing also depends on the architecture you use and the amount of memory you allocate to your code.

You have the choice of using either x86 or Arm architecture. Generally speaking, we’d recommend using Arm (it’s faster and cheaper) unless you’re already set up on x86, you’re working in Rust or Golang, and you don’t have the resources to dedicate any extra time to migration. If you’re using any other languages, all you have to do to migrate to Arm is add a new field in CF/SAM script.

In terms of choosing your memory allocation, there are 13 options ranging from 128 MB for $0.0000000017 per 1ms to 10240 MB for $0.0000001333 per 1ms. Note that these are prices for Arm architecture allocation - x86 is slightly more expensive, but for both you get a slightly better deal when allocating more memory.

Basically, pay for the extra memory if you can afford it and need it, as it’ll save you money compared to letting a request run for longer on a lower memory band.

Additional charges

While it’s not in-depth as, say, EC2 instance pricing, AWS Lambda still incurs additional costs under certain circumstances that you should be aware of. These can easily catch you off guard if you’re not paying careful attention when setting up your account and calculating your AWS budget.

Additional charges apply if your AWS Lambda function uses other AWS services and/or transfers data to or from them. These charges are calculated according to the pricing of whatever services you use.

For example, if you transfer data into or out of the Region your AWS Lambda function executed in you’ll be charged according to the EC2 data transfer on-demand pricing rates. Similarly, if your functions read or write data to or from Amazon S3, you’ll be billed for those requests and any data stored in S3.

In short, if your AWS Lambda requests interact in any way with another AWS service, you’ll have to pay for both services. Paying for one doesn’t circumvent the bill for the other.

AWS Lambda pricing tiers and plans

Now we’re getting into the more complex sections of AWS Lambda pricing - the details of how much everything costs.

To make this easier to follow we’ve split this section into three:

• Free tier
• On-demand
• Savings plans

Free tier

AWS Lambda’s free tier allows you to submit up to 1 million requests per month and take up 400,000 GB-seconds of compute time per month. However, it’s worth bearing in mind that this limit is only true if you allocate 1 GB of memory to your requests - if you allocate less or more, the GB-second allowance will decrease or increase accordingly.

So, let’s say that you submit 1 million requests per month, each of which takes exactly 1 second to execute with 1 GB of memory allocated to them. Since you receive 400,000 GB-seconds free per month, you’ll only have to pay for the other 600,000 seconds it takes to execute your requests. This is where the on-demand AWS Lambda pricing kicks in, but we’ll cover that below.

Now let’s say that you still have 1 million requests per month. They still all take precisely 1 second to execute, but this time they only have 128 MB of memory allocated. Here’s where the scaling of the free tier kicks in.

128 MB is one-eighth of a GB, so at that allocation you have 8 times 400,000 seconds available for free, which is 3,200,000. In other words, you’ll get all of your 1 million requests executed for free that month, because they only take 1 million seconds to execute.

On-demand

Once you’ve exhausted your free tier allowance AWS Lambda’s on-demand pricing kicks in. This is where things look a little intimidating at first glance, but don't worry, we’ll teach you everything you need to know!

First up, know that your free allowance always applies before you start paying. There’s no way to stop qualifying for that free allowance, so you’ll always be subtracting 400,000 GB-seconds and 1 million requests from your final bill calculations.

After your first 1 million requests there is a flat charge of $0.20 per 1 million requests per month which remains constant. So, if you made 3.5 million requests in a month you’d pay $0.60 (3.5M - 1M = 2.5M at $0.20 per 1M).

It doesn’t matter if you don’t use a whole 1 million extra requests. If you go beyond the next million breakpoint, you pay an extra $0.20.

You also pay for the GB-seconds you use per month beyond the first free 400,000. These prices differ slightly depending on whether you’re using x86 or Arm architecture, but we’ll list the prices for both below.

x86 prices:

• $0.0000166667 per GB-second for the first 6 Billion GB-seconds per month
• $0.000015 per GB-second for the next 9 Billion GB-seconds per month
• $0.0000133334 per GB-second for all GB-seconds beyond the first 15 million

Arm prices:

• $0.0000133334 per GB-second for the first 7.5 Billion GB-seconds per month
• $0.0000120001 per GB-second for the next 11.25 Billion GB-seconds per month
• $0.0000106667 per GB-second for all GB-seconds beyond the first 18.75 million

Much like the free limit of 400,000 GB-seconds, all of these prices are calculated as the price for 1 second of executing functions with 1 GB of memory allocated (hence “per GB-second”). If you allocate more or less than 1 GB the price will scale accordingly, so you’ll first want to convert your real-time usage into GB-seconds to calculate your cost.

For example, if you use 8.4 million GB-seconds per month on x86 architecture, you’ll get 400,000 for free, then pay $0.0000166667 per GB-second for the next 6 million, and $0.000015 per GB-second for the final 2 million.

Unlike the flat $0.20 per 1 million requests, you only pay for the exact number of GB-seconds you use.

Savings plans

AWS Lambda has an AWS Compute Savings Plan specific to it, through which you can make savings by committing to a specific amount of usage over a 1-or-3-year period. The amount that you save depends on your Lambda usage type, the AWS region, whether you’re committing to 1 or 3 years, and whether you pay wholly, partially, or not at all upfront.

Check out Amazon’s Compute Savings page for more information and a full rundown, but here are a few general bits of advice.

Don’t pay upfront if you can help it. While it will simplify things a little for dealing with your costs all at once, you’ll also get much lower savings by doing so. There are no extra savings for committing to 3 years as opposed to 1 either, so unless you’re already committed to another savings plan for, say, EC2 instances for 3 years and want to tie them together, there’s not much benefit to doing so.

Finally, take careful note of what your common Lambda usage types are, as some are more expensive on a Compute Savings PLan as opposed to on-demand pricing!

Calculating your AWS Lambda costs

As you can see, AWS Lambda still has plenty of elements that you can easily get confused about when trying to calculate your bill or forecast future spending. So let’s run through an example.

Let’s say that you have 3.5 million requests in any given month. You use Arm because it’s generally faster and cheaper, and allocate 1536 MB of memory to them. It takes on average 150 milliseconds to execute each function.

We’ll also say that, for the sake of simplicity, your functions don’t interact with any other AWS products or services, so there are no extra costs incurred on that front.

To calculate the cost, you first need to know how many GB-seconds (seconds at 1 GB of memory) your requests use to execute. To do this, take your 1536 MB and divide by 1024 MB (1 GB), which tells you that you’re using 1.5 GB-seconds for each second your requests take in real-time. Next calculate the total real time it takes for your functions to execute, which is 3.5 million times 150 ms (0.15 seconds), totaling 525,000 seconds.

Multiply your real time by the number of GB-seconds you’re using per real second (525000 x 1.5) to get 787,500 GB-seconds. Take away the 400,000 free GB-seconds and you’re left with the total billable 387,500 GB-seconds at a cost of $0.0000133334 per GB-second, which is $5.1666925, or $5.17 rounded. Add the $0.60 to cover the 2.5 million requests beyond the 1 million free tier, and your total AWS Lambda bill comes to $5.17.

The main thing to remember when trying to forecast your bill as opposed to calculating the cost of your current operations is that you need to have reliable historical data for your AWS LAmbda account. This should let you accurately predict what you’ll be using in the future, even if you have to adjust slightly for an ever-expanding workload.

How to manage your AWS Lambda costs

There are a few easy ways to reduce your AWS Lambda costs, some of which we’ve already mentioned.

Using Arm instead of x86 architecture will make your operations cheaper and faster. Committing to a savings pricing plan could reduce your costs further, and you won’t lose out if you don’t commit to a full 3 years.

The only other way (short of reducing the number of requests you make) to reduce your costs is to optimize the memory allocation for your requests. As shown above, AWS Lambda Power Tuning allows you to test for the optimal setup automatically.

You’ll also need to carefully track your costs to make sure that you’re not incurring any additional unexpected fees. This will let you more accurately forecast what your future bills will look like, and combine them with your other AWS costs to give a coherent summary to your finance department and CEO.

To do this, try using Aimably’s AWS Spend Transparency Software. With it you can see a detailed breakdown of every element of your AWS bill and activity, including your AWS Lambda requests.

After all, wouldn’t it be nice to spend your time on more important tasks than figuring out your total GB-second usage?