Lambda’s pricing isn’t just about how many times your function runs; it’s about how much time and memory you allocate for those runs, and it’s billed in 1ms increments.
Let’s see what that looks like in practice. Imagine you have a simple Lambda function that takes 50ms to execute and is configured with 128MB of memory.
{
"FunctionName": "my-processing-function",
"Configuration": {
"MemorySize": 128,
"Timeout": 30,
"Runtime": "python3.9",
"Handler": "index.handler"
},
"State": "Active",
"LastModified": "2023-10-27T10:00:00.000Z"
}
And it’s invoked 1 million times a month.
Here’s how AWS breaks down the cost:
-
Requests: You get 1 million free requests per month. After that, it’s $0.20 per 1 million requests. For our example, if we stay within the free tier, this part is $0.
-
Duration: This is where memory and execution time matter. Lambda bills for the duration your code executes, rounded up to the nearest 1ms. The price per GB-second depends on your region. Let’s assume
us-east-1for this example.- Your function runs for 50ms.
- It’s configured with 128MB of memory.
- The GB-second pricing in
us-east-1is $0.0000166667 per GB-second.
First, convert memory to GB: 128MB / 1024MB/GB = 0.125 GB. Next, convert execution time to seconds: 50ms / 1000ms/sec = 0.05 seconds.
The cost per invocation is:
0.125 GB * 0.05 seconds * $0.0000166667/GB-sec = $0.0000001041666(approximately).Now, multiply by your monthly invocations:
0.0000001041666/invocation * 1,000,000 invocations = $0.104.
So, for 1 million invocations of a 50ms, 128MB function, your duration cost is a mere 10.4 cents, assuming you’re within the free tier for requests.
The free tier for Lambda is quite generous: 1 million free requests per month and 400,000 GB-seconds of compute time per month. In our example, 1 million invocations * 0.125 GB * 0.05 seconds = 6,250 GB-seconds. This is well within the free tier, meaning the cost for this specific workload would be $0.
The real cost creeps in when your functions are larger (more memory allocated) or slower (take longer to execute), or when you have many more invocations that exceed the free tier.
Consider this configuration:
{
"FunctionName": "my-heavy-processing-function",
"Configuration": {
"MemorySize": 1024, // 1GB
"Timeout": 60, // 60 seconds
"Runtime": "python3.9",
"Handler": "index.handler"
},
"State": "Active",
"LastModified": "2023-10-27T10:00:00.000Z"
}
If this function, also invoked 1 million times, consistently takes 500ms to run:
- Memory in GB: 1024MB / 1024MB/GB = 1 GB
- Execution time in seconds: 500ms / 1000ms/sec = 0.5 seconds
- Cost per invocation:
1 GB * 0.5 seconds * $0.0000166667/GB-sec = $0.00000833335 - Total duration cost for 1 million invocations:
0.00000833335/invocation * 1,000,000 invocations = $8.33
This is still relatively cheap, but it highlights how memory allocation directly impacts cost, even if the CPU utilization is low. The price is for the provisioned memory, not the used memory.
The most surprising aspect of Lambda pricing is how a small increase in allocated memory can have a disproportionately larger impact on cost than a small increase in execution time, especially if your function isn’t CPU-bound. This is because the GB-second calculation is a multiplication of memory (in GB) and time (in seconds). Doubling your memory allocation always doubles the duration cost component, regardless of actual CPU usage. Conversely, doubling execution time only doubles that component.
The key levers you control for cost are MemorySize and Timeout in your function’s configuration, and understanding the actual execution duration of your code. AWS provides tools like AWS Cost Explorer and Lambda’s own monitoring metrics (invocations, duration, errors) to help you track and optimize spending.
The next rabbit hole to fall into is understanding how different compute resources (CPU, network, disk I/O) scale with memory allocation in Lambda, and how that can indirectly affect execution time and thus cost.