AWS Lambda vs Azure Functions: the free tier and pricing, compared

People ask which one is cheaper expecting a winner. For anything small the honest answer is: neither, in a way you will ever feel. The interesting difference is buried in how each one counts your milliseconds.

New to cloud? CAMPUX is a free, build-first course. Start here →

AWS Lambda and Azure Functions hand you almost the same free grant — roughly one million requests and 400,000 GB-seconds of compute free every month, and that grant resets monthly rather than expiring after a year. So for a side project or a light production workload, both are effectively free. The one real pricing difference is billing granularity: Lambda bills execution time in 1-millisecond increments, while Azure Functions' Consumption plan rounds each run up to the nearest 100 milliseconds — which makes very short, bursty functions cheaper on Lambda once you outrun the free tier.

That is the whole money story in two sentences, and most comparison articles bury it under a table of numbers that will be stale by the time you read them. I would rather tell you where the numbers stop mattering and where they start.

The free tier is the same, and it is genuinely free

Both platforms price serverless functions on two axes: how many times your function runs, and how much memory-time it burns while running. That second unit, the GB-second, is one gigabyte of allocated memory held for one second. A function set to 512 MB running for two seconds costs one GB-second. Get the shape of that unit in your head and serverless pricing stops being mysterious.

As of 2026, both AWS and Microsoft give you a perpetual monthly free grant of about 1,000,000 requests and 400,000 GB-seconds of execution. It resets every month, for the life of the account. This is not the 12-month new-account trial you get on virtual machines — the EC2 and Azure VM free windows expire; the functions grant does not. That distinction matters more than any per-request price. It means a cron job, a webhook receiver, a small API, or a scheduled cleanup can run for years and cost you nothing.

Do the arithmetic on 400,000 GB-seconds and you see how much room that is. A modest 128 MB function running for 300 milliseconds uses 0.0375 GB-seconds per call. The free grant covers roughly ten million such calls a month before the compute meter even starts. Most hobby projects never come close.

At side-project scale the price isn't a tie-breaker. It's a rounding error on both.

Where Lambda's 1ms billing wins

Now the one place the platforms genuinely diverge on money. Once you exhaust the free grant, both charge for compute by the GB-second — but they measure the duration differently before they multiply.

Lambda rounds your execution time to the nearest millisecond. Azure Functions on the default Consumption plan rounds each execution up to the nearest 100 milliseconds. If your function does its work in 12 milliseconds, Lambda bills you for 12 and Azure bills you as if it took 100. That is an eight-times overcount on that dimension — but only for functions short enough for the rounding to dominate.

So the pattern where Lambda pulls ahead on cost is specific: very short executions, called very often, past the free tier. Think a high-volume validation endpoint or a lightweight event transformer that finishes in single-digit or low-double-digit milliseconds, firing millions of times a day. There the 100ms floor is pure tax. For a function that runs 300ms, 800ms, or two seconds, the rounding is noise and the two platforms land within cents of each other.

The full comparison

Everything that differs between the two, side by side. Prices move constantly, so I have described the pricing model and the fixed facts rather than quoting per-request dollars that will be wrong next quarter — check each provider's calculator for live numbers before you commit.

The bindings are the Azure argument

The feature that pulls people toward Azure Functions is not price — the free tier already settled that — it is bindings. On Lambda, a trigger tells your function when to run; getting data out to another service is code you write with the SDK. Azure Functions gives you both an input and an output binding, declared as configuration. A function can be triggered by a new blob landing in Storage, receive that blob as a parameter, and write its result straight into a Cosmos DB container — with the plumbing declared, not hand-coded.

When your data, your identity, and your queues already live in Azure, that closeness is the whole point. A function reacting to a Blob Storage upload, a Cosmos DB change feed, or a Service Bus message sits inside the same resource group and authenticates with the same Entra identity as everything around it. You are not building a bridge between two clouds; you are wiring one box to the box beside it. That is the practical reason to reach for Functions, and it has nothing to do with which one shaves a fraction of a cent off a million requests.

So which one — honestly

If you are starting cold with no existing footprint, this is not a decision worth agonising over on price, because there is no price to speak of at the scale you will start at. Pick the cloud you want to build a career or a product in, and use its functions.

For a CAMPUX reader, that tilt is toward Azure, and the reason is honest: the value here is fluency in one ecosystem deep enough to be trusted with it, and Functions is where the rest of your Azure stack becomes reachable in a few lines. When the tie-breaker is "which one lives next to my data and my identity," Functions wins for anyone already in Azure. Reach for Lambda when your workload is genuinely the pathological case — millions of sub-20ms executions past the free tier where 100ms rounding turns into a real bill — or when the rest of your world is already AWS.

Either way, do not choose from a table. Build a small one on each, watch it bill nothing for a month, and let the triggers your app actually needs make the call. When you are ready to build the Azure side for real, Class 41 walks through Azure Functions end to end, and the code-practice sandbox lets you write and run one without leaving the browser.

Common questions