AWS Lambda vs Google Cloud Functions: the pricing, compared

Two clouds, one billing model, almost the same free grant. People go looking for the cheaper one and come back with a spreadsheet that misses the point — the money question was answered before they opened the calculator.

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

AWS Lambda and Google Cloud Functions price almost identically. Both bill on two axes — a charge per request plus compute measured in GB-seconds — and both hand you a large perpetual monthly free grant, on the order of one to two million requests and around 400,000 GB-seconds of compute. Below that grant you pay nothing on either. Above it, the per-unit rates are close enough that for most workloads the bill is a wash, and the real choice comes down to ecosystem, cold-start behaviour, and which languages and runtimes you want.

That is the whole money story, and I would rather spend the rest of this note on where the numbers stop deciding anything and what should decide instead. This is a comparison of the two non-Azure serverless platforms — if you are already weighing Azure, the Lambda vs Azure Functions deep-dive is the one to read, and I tie the Azure thread back in at the end here too.

The billing model is the same on both

Both platforms charge for serverless functions the same way: how many times your function runs, and how much memory-time it burns while running. That second unit is the GB-second — one gigabyte of allocated memory held for one second of execution. 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 on any cloud.

Google Cloud Functions in its current generation — the 2nd-gen product, which runs on Cloud Run underneath — adds one wrinkle: it can bill a small vCPU-second charge alongside memory, because you can allocate CPU somewhat independently of memory. Lambda folds CPU allocation into the memory setting; you pick a memory size and get proportional CPU with it. In practice both still resolve to "requests plus compute-time," and both meter compute finely enough that the model, not the rounding, is what you plan around.

You are not choosing a cheaper cloud. You are choosing which one your app already wants to live next to.

The free grant is real, and it is perpetual on both

As of 2026, both AWS and Google give you a monthly free grant that resets every month for the life of the account — not a 12-month new-account trial. The figures sit in the same ballpark: on the order of one to two million requests and roughly 400,000 GB-seconds of compute per month, with Google historically also quoting a separate vCPU-second allowance. Exact figures shift, so confirm on each provider's pricing page before you plan a budget around them.

The important part is the word perpetual. This is not the 12-month EC2 or Compute Engine VM free window, which expires and then bills you. The functions grant resets forever. A cron job, a webhook receiver, a small API, or a scheduled cleanup can run for years and cost nothing on either cloud. Do the arithmetic on 400,000 GB-seconds: a modest 128 MB function running for 300 milliseconds uses 0.0375 GB-seconds per call, so the grant covers on the order of ten million such calls a month before the compute meter even starts. Most side projects never come close.

The comparison, side by side

Everything that differs, laid out. 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 — this table is the shape, not the invoice.

What the pricing page makes you forget

Here is the honest gap. A pricing page is built to make you feel like you are optimising pennies — per-request rates quoted to six decimal places, free-tier counts in the millions, a calculator with sliders. It trains you to compare the wrong thing. At any real scale, two decisions in your architecture move the bill far more than the gap between the two providers ever will.

The first is how often you invoke. A function you call once per user action costs a fraction of one you call in a tight loop or on every page render. Chatty designs — a function per item in a list, a function that another function calls synchronously — multiply your request and compute lines regardless of whose cloud they run on. The second is memory sizing. Because compute is memory multiplied by time, a function set to 1 GB when it needs 256 MB pays four times the compute cost per invocation for nothing. Over-provisioned memory is the single most common serverless overspend I see, and it is entirely within your control.

Put numbers on it. Right-sizing one busy function from 1 GB down to 256 MB cuts its compute cost by roughly three-quarters. No provider switch gives you that. The per-GB-second difference between Lambda and Google Cloud Functions, whatever it is this quarter, is a low-single-digit-percent effect — noise next to a 75% cut you make by reading your own memory graph. That is why "which is cheaper" is the wrong opening question. The right one is "which is cheaper for the way I am going to build it," and the answer to that is mostly up to you.

So where the decision actually lives

With price off the table, the real differentiators are the ones the calculator does not show:

• Ecosystem. If your data, queues, and identity already live in one cloud, put the function next to them. A Cloud Functions handler on a Cloud Storage or Pub/Sub event, or a Lambda on an S3 or DynamoDB event, sits inside the same identity and network as the thing it reacts to. Crossing clouds to save a fraction of a cent is a bad trade.
• Cold starts. Both scale to zero and both cold-start on the cheapest path. Time depends on runtime and package size — a small Node or Python function is quick on either; a heavy JVM or .NET one is slower on both. Each sells a warm path: Lambda's Provisioned Concurrency, Google's minimum-instances setting. Both cost money, and both defeat the point of scale-to-zero if you leave them on for a trickle of traffic.
• Language and runtime fit. Lambda's runtime list is broad and its container-image path lets you run almost anything. Google's 2nd-gen functions run on Cloud Run, so you inherit that flexibility too. If a specific runtime version or a container is a hard requirement, check it on both before you assume parity.

Where Azure Functions fits

Since this is a CAMPUX note, the Azure comparison is the one most of my readers need. Azure Functions uses the same fundamental model — per request plus compute in GB-seconds — and its Consumption plan free grant sits in the same neighbourhood, about a million requests and 400,000 GB-seconds a month. So the "it is a wash at small scale" conclusion holds across all three.

The one pricing quirk worth knowing: Azure's Consumption plan rounds each execution up to the nearest 100 milliseconds, where Lambda bills to the nearest 1 millisecond. That only bites for very short, very frequent functions past the free tier, and Azure's newer Flex Consumption plan revised the model — but it is the kind of detail that matters if your workload is millions of sub-20ms invocations. Azure's real pull, like Google's and AWS's, is ecosystem: its declarative input and output bindings let a function react to a Blob Storage upload or a Service Bus message and write its result to another Azure service with almost no glue code. The full breakdown, including that 1ms-vs-100ms line and the bindings argument, is in the Lambda vs Azure Functions deep-dive.

If you want the ground under all three — where serverless sits relative to VMs and containers, and how the three big clouds line up on more than functions — Class 6 compares AWS, Azure, and GCP head to head, and Class 41 builds an Azure Function end to end. When you want to stop paying by accident, Class 32 on cost management and FinOps is where memory sizing and invocation counts turn into a bill you can read.

The short version

Lambda and Google Cloud Functions cost effectively the same. Both are free for anything small and both bill the same way when you outgrow that. Do not choose from a pricing table — pick the cloud your app already belongs in, size your function's memory honestly, and watch how often you call it. Those three decisions set your bill. The provider logo barely moves it.

Common questions