200 million serverless requests: Lambda, Azure Functions and Cloud Run priced

The request line is not what decides 200 million

Two hundred million invocations a month sounds like a request-billing problem. It is not. At the published rate of $0.20 per million requests, Lambda bills $40 for the request dimension once the one-million free tier is used, and Azure Functions Consumption bills the same $0.20 per million on the same basis. Cloud Run's published request rate is $0.40 per million, which doubles that line to $80. Against any of those, the duration charge is where the invoice is made.

The arithmetic is worth doing once in front of the reader. A function that runs 200 milliseconds at 512 MB consumes 0.1 GB-seconds per call, so 200 million calls is 20 million GB-seconds a month. At Lambda's $0.0000166667 per GB-second that is roughly $333 of compute, and at Azure Functions' $0.000016 it is $320. The request fee is a rounding error beside it, which is why a team that optimises request count and not memory tier saves almost nothing.

That is the first thing the 200-million figure changes. It moves the decision away from per-call pricing, which is nearly identical across the three platforms, and onto the two variables the buyer controls: how much memory each function is given and how long each call runs. Both are engineering choices, and both are visible in the bill.

Lambda and Azure Functions bill the same shape

Lambda meters two dimensions: requests at $0.20 per million and duration in GB-seconds at $0.0000166667, with a free tier of one million requests and 400,000 GB-seconds a month. Memory can be set anywhere between 128 MB and 10,240 MB in 1 MB increments, and CPU is allocated proportionally, so the memory dial is also the CPU dial. The published per-millisecond examples run from 128 MB to 10,240 MB, and the tiering applies to aggregate monthly duration per architecture and region within an account.

Azure Functions on the Consumption plan mirrors that structure: $0.20 per million executions and $0.000016 per GB-second, with the same one-million-request and 400,000 GB-second free allowance. For a 200-million-request workload the two land within a few percent of each other on compute and are identical on requests, so the choice between them is not settled by price at this volume. It is settled by which estate the function already lives in.

The lever both platforms share is the memory tier. Because CPU scales with memory, a function given more memory can finish sooner and consume fewer GB-seconds even at a higher per-millisecond rate. The published guidance is to sweep a few memory tiers under real traffic and compare total cost rather than per-invocation cost, which is the only way to find the point where a larger allocation pays for itself.

Cloud Run prices CPU and memory separately

Cloud Run is a container service, and its meter reflects that. Requests are $0.40 per million, double the function platforms, and compute is billed per 100 milliseconds at $0.000024 per vCPU-second. CPU and memory are set independently rather than through a single memory dial, which matters for a workload that is CPU-bound or memory-heavy but not both.

The structural difference is what the reader pays for. Lambda and Azure Functions charge for memory-weighted duration, so an idle wait inside a function still costs. Cloud Run charges for allocated CPU and memory for the lifetime of a request, with an option to keep instances warm, and warm instances are billed as capacity held rather than work done. A team that keeps a minimum instance count to avoid cold starts is buying idle time on Cloud Run in a way the function platforms express differently.

For 200 million short requests the request line is $80 rather than $40, and the compute line depends entirely on the CPU allocation per request. A short, CPU-light call can come out cheaper than the GB-second model; a long one usually does not. The published rate is per vCPU-second, so the model needs the CPU setting, not just the memory setting, before any comparison is honest.

The cold-start workaround is a paid line on every platform

Every one of the three platforms sells a way around cold starts, and none of them includes it in the base rate. Lambda SnapStart is documented as initialising the function when a version is published, taking a snapshot of the initialised execution environment and resuming new environments from that snapshot, with startup as low as sub-second in optimal cases. AWS documents it as addressing latency variability from one-time initialisation, and it has its own pricing section.

The documentation is explicit that SnapStart works best with invocations at scale and that infrequently invoked functions might not see the same improvement. For a 200-million-request workload that is the favourable case. The cost of the feature is not stated in the material here, which is a finding rather than a gap: the buyer should ask AWS for the SnapStart line item on the specific function profile before treating it as free.

Cloud Run's equivalent is the warm-instance option, which holds capacity and is billed for it. Azure Functions has its own cold-start mitigations on the Consumption plan, and the published per-execution and per-GB-second rates do not describe them. The practical consequence is that a comparison built only on the headline request and duration rates understates the bill for any workload that has decided cold starts are unacceptable.

Where the model breaks at this volume

The crossover between serverless and containers is the number a buyer wants and the one the pages disagree on. One analysis puts the crossover at around one million requests per day for most workloads, with the exact point depending on duration, memory allocation and which line items are counted. At 200 million a month, roughly 6.6 million a day, that analysis places the workload well past the point where a single always-on container typically beats per-invocation pricing.

The same analysis warns that hidden line items add 30 to 60 percent to the raw compute number: API Gateway at $3.50 per million calls, CloudWatch Logs at $0.50 per GB ingested, and retries caused by cold starts. None of those appear in the per-request or per-GB-second rate, and all of them land on the invoice of a team running 200 million calls through an API front door.

That is the honest limit of this comparison. The three platforms are close enough on the published compute rates that the surrounding services, not the function meter, decide the total. A buyer who prices only the function is pricing perhaps two thirds of the bill.

What to ask before signing at 200 million

Ask each vendor for the total monthly figure on a named request profile: 200 million invocations, a stated duration, a stated memory or CPU allocation, and the cold-start mitigation switched on. Lambda and Azure Functions can be modelled from the published GB-second rates once the memory tier is fixed, and the memory sweep is the work that produces the number. Cloud Run needs the vCPU allocation per request before the $0.000024 per vCPU-second rate means anything.

Ask for the cold-start feature priced separately. SnapStart has a pricing section in the AWS documentation and the figure is not in the material here; the warm-instance charge on Cloud Run is likewise a line the buyer should see rather than infer. Ask too for the egress and logging charges that sit outside the function meter, because those are the items the crossover analysis says add 30 to 60 percent.

Then compare against a container. At 200 million requests a month the workload is past the point where per-invocation pricing is obviously right, and a single always-on instance is the benchmark the serverless bill has to beat. The decision rule follows from that: choose Lambda if the workload already lives in an AWS estate and the memory sweep shows a tier where GB-seconds stay low, because the request line is $40 and the integration is the saving. Choose Azure Functions if the estate is Microsoft-centred, since the compute rate of $0.000016 per GB-second is marginally below Lambda's and the request rate is identical. Choose Cloud Run if the workload is CPU-bound and container-shaped, because setting CPU independently of memory is the control the other two do not offer, and accept the $80 request line as the price of it. Price a container first if the profile is steady rather than spiky, because 200 million calls a month is the volume at which the always-on option stops being the expensive one.