Serverless Architecture Cost Calculator
Estimate monthly serverless spending with realistic inputs
Serverless pricing looks simple at first glance: pay only for what you use. The catch is that monthly bills depend on two kinds of usage that grow in different ways. One part of the bill comes from how many times your function runs. The other part comes from how much memory the function has and how long each invocation runs. This calculator brings those pieces together so you can estimate the cost of a Lambda style or cloud function style workload without building a spreadsheet every time you want to test a scenario.
The most useful way to think about this tool is as a planning model rather than an oracle. You are not trying to predict the future down to the cent. You are answering practical questions such as whether a traffic increase will still fit your budget, whether a higher memory tier is justified by a lower runtime, or whether a batch workflow that runs millions of times per month is cheap enough to keep as serverless compute. When those questions are framed in numbers, architecture decisions get easier to compare and easier to explain to teammates.
What the calculator includes
This page estimates the two core charges that appear in many serverless compute pricing models: a request fee and a compute fee based on GB-seconds. Request pricing is the simple part. More invocations mean a higher request charge. Compute pricing multiplies three things together: the number of invocations, the billed runtime of each invocation, and the memory size allocated to the function. Because memory is converted into gigabytes and duration is converted into seconds, the combined usage is measured in GB-seconds. That usage is then multiplied by the GB-second rate you enter.
That means the calculator is especially helpful when you already know, or can reasonably estimate, your monthly invocation count. If you are still benchmarking code, the right approach is not to wait for perfect data. Run one optimistic scenario, one baseline scenario, and one conservative scenario. The range tells you far more than a single best guess, especially when you are comparing alternative implementations or deciding whether an optimization project is worth the effort.
How the monthly cost is calculated
The form below converts the raw inputs into billable units, then applies the pricing formula. Milliseconds are turned into seconds. Megabytes are turned into gigabytes. The calculator multiplies requests, duration, and memory to get total GB-seconds for the month. That compute usage becomes the monthly compute charge after applying your GB-second rate, and the request fee is added on top. The result area shows those parts separately so you can see what is actually driving the total.
If you like to see the general shape of the model, the serverless total is still just a function of a handful of inputs. The two generic MathML expressions below were already part of this page, and they still describe the calculator correctly: the result is a function of the variables, and the total can be viewed as the sum of weighted components.
How to choose each input
Monthly Requests should represent total function invocations for the month, not just end user visits. If one page load triggers several functions, enter the function count, not the page count. If your architecture retries failed invocations, fans out a queue message into multiple workers, or runs scheduled background jobs in addition to user triggered calls, include that behavior in the estimate. This input is often the cleanest lever for scenario planning because request charges scale linearly with traffic.
Average Duration (ms) should be your billed runtime per invocation, not the fastest number you saw in a quick test. A common mistake is to enter a median or best case number from performance dashboards even though a meaningful portion of traffic runs longer. For budgeting, a weighted or observed average is usually safer. If your provider rounds duration upward for billing increments, use the effective billed value rather than raw application timing so the estimate tracks the real bill more closely.
Memory Allocation (MB) is the configured memory size of the function. This matters because compute cost is not based on CPU time alone. It is based on memory multiplied by duration. Higher memory can still be a good decision if it makes the function finish fast enough to offset the larger memory size, but that tradeoff has to be modeled honestly. If you test a different memory tier, update both memory and expected duration, because real workloads often run faster when more memory also unlocks more CPU.
GB-Second Rate ($) should match the provider, region, and architecture you are pricing. The default value is a familiar example rate often used in introductory comparisons, but it is not a universal recommendation. Some providers publish different prices for x86 versus ARM, different regions, or different execution products. Treat the input as a pricing assumption you can swap for your own contract or published rate card.
Request Rate per 1M ($) is the fee charged per million invocations. This number can look small enough to ignore, but it becomes meaningful at very high traffic volumes or when each invocation is so short that compute cost is tiny. Seeing request cost and compute cost separately is useful because it tells you whether to focus on fewer invocations, shorter runtimes, or a different memory configuration.
Worked example using the default values
Suppose you expect 5,000,000 invocations per month, an average billed duration of 300 ms, and a memory allocation of 512 MB. First convert duration and memory into billable units. Three hundred milliseconds is 0.3 seconds, and 512 MB is 0.5 GB. Multiply those by the request volume and you get the monthly compute usage.
Monthly GB-seconds = 5,000,000 × 0.3 × 0.5 = 750,000 GB-seconds.
With the default GB-second rate of $0.0000166667, the compute portion is about $12.50. The request fee is 5 million requests divided by 1 million, then multiplied by $0.20, which gives $1.00. Add the two pieces and the estimated monthly total is about $13.50. That is the kind of mental cross-check you should always do after the calculator updates. If you can explain where the number came from in plain language, you are much less likely to trust a bad input by accident.
The same example also reveals a subtle optimization point. If you doubled memory to 1024 MB but cut runtime from 300 ms to 150 ms, the GB-second total would stay almost unchanged because one factor doubled while the other was halved. In practice, that means some more memory changes may improve latency without materially changing cost, while other changes simply increase spending. The calculator is useful precisely because it lets you test those tradeoffs explicitly instead of relying on instinct.
Scenario comparison
The table below keeps duration, memory, and pricing constant while changing only the number of requests. This is the cleanest way to see how monthly traffic affects the result. Notice how both the request charge and compute charge rise proportionally because each invocation carries both kinds of cost.
| Scenario | Monthly Requests | Compute Cost | Request Cost | Total Monthly Cost |
|---|---|---|---|---|
| Conservative | 4,000,000 | $10.00 | $0.80 | $10.80 |
| Baseline | 5,000,000 | $12.50 | $1.00 | $13.50 |
| Growth case | 6,000,000 | $15.00 | $1.20 | $16.20 |
When you run your own scenarios, change one assumption at a time first. That makes it obvious whether traffic, memory choice, or duration is driving the difference. After that, create combined scenarios such as traffic up 30 percent and duration down 20 percent after optimization to see the net effect. That second step is where the calculator becomes a decision tool rather than a mere arithmetic helper.
How to interpret the result panel
The results area shows Monthly Compute Cost, Request Cost, and Total Monthly Cost separately because those numbers answer different questions. If compute cost dominates, focus on runtime efficiency, memory right sizing, and architecture changes that reduce execution time. If request cost dominates, you may gain more from reducing invocation count, batching work, or moving tiny high frequency operations into a different service.
A reliable sanity check is to ask how the total should move when you change one input. Double the requests and the total should roughly double. Double memory while keeping duration constant and compute cost should roughly double. Cut duration in half while keeping memory constant and compute cost should roughly halve. If the output moves in a way you did not expect, the issue is usually not mysterious math. It is usually a unit mismatch, a pricing rate from the wrong region, or an assumption that belongs outside this simplified model.
Assumptions and costs not included
This calculator intentionally focuses on the core compute and request math. Real serverless bills often include other services that may matter just as much in production: API gateway charges, data transfer, storage, logs, secret retrieval, durable queues, workflow orchestration, provisioned concurrency, and free tier credits. Those items can be layered on separately, but they are not part of the simple formula here unless you deliberately fold them into your rates or usage before entering values.
It is also important to remember that averages can hide burstiness. A workload with sharp spikes may experience concurrency behavior, cold starts, or retry patterns that change the true bill. Use this page as a clean baseline estimate, then compare it with observed provider billing once the system is live. That workflow is usually stronger than waiting for perfect information before modeling anything at all, because it gives you a consistent way to learn from the difference between forecast and reality.
- Free tiers: not subtracted automatically. If you want a net estimate after credits, lower the effective rates or reduce billable usage before entering values.
- Billing increments: if your provider rounds duration up, use the billed average rather than raw runtime.
- Memory and performance: raising memory may lower duration, so update both inputs when you benchmark a new memory size.
- Retries and downstream triggers: include them if they create extra invocations, because they directly affect both request and compute charges.
- Regional pricing: always confirm current provider pricing before using the estimate for procurement or budgeting.
Practical ways teams use this page
Teams commonly use a calculator like this during architecture reviews, capacity planning, and optimization work. A product manager may use it to turn forecasted user growth into a monthly budget range. A developer may use it to compare two implementations of the same function after a performance test. An operations team may use it to understand whether a spike in cost is coming mostly from more requests or from slower executions. Because the inputs are explicit and the math is simple, the page works well as a shared reference point in those discussions.
The defaults in the form are illustrative rather than prescriptive. They are there so the calculator produces an immediate result and so the worked example on the page has concrete numbers. Replace them with your own invocation count, billed duration, configured memory, and provider pricing before you rely on the estimate. The most valuable habit is not merely pressing Calculate. It is documenting the assumptions behind each run so that a teammate can reproduce the same scenario later and understand why the result changed.
Mini-game: Right-Size the Invocation Router
This optional arcade mini-game teaches the same cost instinct as the calculator. Requests stream into a routing point, and your job is to send each invocation into the smallest memory tier that can handle it. Exact fits score the most because they avoid waste. Oversized routes still work, but they burn extra budget. Undersized routes trigger retry storms and end the run faster. It is quick to understand, fun to replay, and directly tied to the memory and duration tradeoffs that drive serverless compute cost.
Educational takeaway: the cheapest successful route is usually the smallest memory tier that still completes the work. That is the same right size and benchmark mindset behind the calculator above.