Lambda vs Azure Functions vs Cloud Functions pricing

By Rohit Athaide · Published 4 Nov 2026

Short answer: function services charge for work done, not for a server sitting idle. All four clouds bill the same two things, which are the number of requests and the run time scaled by memory, with a monthly free allowance. The details differ, and for a small app the free allowance can cover the whole function bill.

Key points

• Cost has two parts: requests, and gigabyte-seconds.
• A gigabyte-second is memory (GB) multiplied by run time (seconds).
• Waiting on a database or API is billed as run time.
• Gateways, logging and data transfer are billed on top.
• Compare pay-per-use functions with pay-per-use functions, not with always-on plans.

How are functions billed?

1. Per request. A small charge for each invocation, usually quoted per million.
2. Per run time and memory. You pay for how long the code runs, scaled by the memory you give it. The unit is the gigabyte-second.

They are equivalent as event-driven, pay-per-use code runners. A plan that reserves always-on capacity is a different product and should not be compared with these.

What does a worked example look like?

Made-up round numbers to show the method, not real prices. A function gets 10 million requests a month. Each run takes 200 ms with 512 MB of memory.

1. GB-seconds: 10,000,000 x 0.2 s x 0.5 GB = 1,000,000 GB-seconds.
2. Free allowance (made up): 400,000 GB-seconds and 1 million requests.
3. Billable GB-seconds: 1,000,000 - 400,000 = 600,000.
4. Billable requests: 10,000,000 - 1,000,000 = 9,000,000 = 9 million.
5. Compute charge at 0.00002 per GB-second (made up): 600,000 x 0.00002 = 12.00.
6. Request charge at 0.25 per million (made up): 9 x 0.25 = 2.25.
7. Total: 14.25 per month.

Now double the run time to 400 ms. GB-seconds become 2,000,000, billable 1,600,000, and compute becomes 32.00. The request charge does not move. Run time and memory drive the bill, not the request count. Swap in real rates from the serverless estimator and the functions compare page.

What changes the total?

• Memory setting. More memory costs more per second, but may finish faster. Test it.
• Run time. Billing is rounded to a small step. Slow calls to other services are billed as run time.
• Free allowance. Each cloud gives a monthly allowance of requests and gigabyte-seconds. See free tiers explained.
• Extras around the function. API gateway requests, logging, network and data transfer are separate. See API gateway pricing and logging and monitoring costs.

When do servers win?

At steady high load, a function can cost more than a server that is always busy. The break-even depends on request rate and run time. A function with a long run time and heavy memory use is the first to lose. Serverless or servers shows how to compare them fairly.

Which mistakes are common?

• Leaving the memory at the default without testing.
• Calling a slow database from inside a function, and paying for the wait.
• Logging every request at full detail.
• Forgetting the gateway charge for every public call.
• Comparing a pay-per-use function with an always-on plan.

Decision checklist

• Is traffic spiky or low? Functions fit well.
• Is the load steady and heavy all day? Price a server too.
• Have I measured run time and memory, not guessed?
• Did I add the gateway, logs and data out?

Next steps

The serverless estimator takes requests per month, run time and memory and prices the same workload on each cloud with its free allowance applied. For the whole application, read what a web app costs.