The question that starts almost every discussion about Azure Functions plans is “which one is cheaper?”. It’s the wrong question because it has an answer that helps no one: it depends.
The correct question is: from what traffic volume does pay-per-execution become more expensive than reserved capacity — and how much do I actually pay in real money to eliminate cold start? This has a numeric answer, and in most cases, the answer is surprising.
In the previous article, we talked about the three types of costs in a cloud architecture. Functions plans are the clearest example in Azure of the tension between variable cost and fixed cost, so it’s a good place to start.
The four options, briefly
The landscape has changed in the last two years and many still reason with the old map, where only Consumption and Premium existed.
Consumption (classic)
Serverless in the pure sense. Scales to zero, you pay per execution and per GB-second of memory consumed. Limitations: no VNet integration, maximum 10 minutes per execution, capped memory, cold starts of a few seconds.
Flex Consumption
Became generally available in 2024 and Microsoft’s default recommendation for new serverless workloads. Maintains scale to zero but adds exactly the things people were moving to Premium for: VNet integration, configurable always-ready instances (from 0 upwards), executions up to 60 minutes, more memory per instance, and a significantly higher scale-out limit.
Premium (Elastic Premium, EP1–EP3)
Reserved, pre-warmed capacity. Zero cold start, full VNet, deployment slots, practically unlimited execution duration. Billed per core-second and memory, for both the required and pre-warmed instances — at least one must remain warm permanently. In other words: you pay even at zero traffic.
Dedicated (App Service Plan)
You run functions on an existing App Service Plan. No separate billing. Makes sense in only one scenario, but there it makes a lot of sense — I’ll return to it below.
The breakeven formula
Let’s put numbers. The Consumption billing model has two terms, both with a permanent monthly free tier: 1,000,000 executions and 400,000 GB-seconds.
GB-seconds = (Memory_MB / 1024) × Duration_seconds × Executions
Execution_cost = max(0, Executions - 1,000,000) × $0.0000002
Compute_cost = max(0, GB-s - 400,000) × $0.000016
Total = Execution_cost + Compute_costA Premium EP1 plan running one instance permanently costs roughly somewhere around $150–170 per month, regardless of traffic. The breakeven point is the volume at which Consumption reaches this amount.
Scenario A: small API, fast functions
512 MB memory, 200 ms average duration.
Each execution consumes 0.1 GB-seconds. The marginal cost per execution is about $0.0000018. To reach $160 per month, you need almost 90 million executions monthly — that is over 30 requests per second, sustained, 24/7.
If you have that traffic, you probably are not reading an article about cost optimization. The conclusion for the vast majority of applications: Premium is never justified on cost grounds at this profile.
Scenario B: processing, heavy functions
1 GB memory, 2 seconds average duration.
Each execution consumes 2 GB-seconds. The marginal cost rises to about $0.0000322 per execution, and the breakeven drops dramatically: around 5 million executions per month, about 2 per second.
The difference between the two scenarios is almost twentyfold, and the variable causing it is not the number of executions — it’s the product of memory and duration. This is where all the optimization lies.
On Consumption you don’t pay for traffic. You pay for GB-seconds. Two architectures with the same number of requests can have completely different bills.
How much does it cost, in money, to eliminate cold start
This is the real decision, and rarely is it presented honestly.
On classic Consumption, a cold start on .NET realistically means a few seconds of latency for the first request after a period of inactivity. If the function serves a webhook, a nightly job, or a queue processor, it doesn’t matter at all. If it serves an endpoint called by the user interface, it matters a lot.
The old option was: accept cold start or pay about $160 per month for Premium. A jump from almost zero to a consistent fixed cost, to solve a problem that might occur 40 times a day.
Flex Consumption broke exactly this false binary. You configure a number of always-ready instances — it can be just one — and pay for them as reserved capacity, while the rest of the traffic scales elastically and is billed on consumption. In other words, you buy only the amount of “warmth” you need, not an entire plan.
For an internal API with modest but latency-sensitive traffic, this is almost always the right choice in 2026.
When Premium is still worth it
Premium remains the right answer in a few situations, none of which relate to volume:
- Memory beyond what Flex offers per instance — processing that really needs a lot of memory in a single process.
- Complete deployment slots — if your release strategy depends on slot swap with warm-up, Premium is the only one that gives it to you without compromises.
- Consolidation — a single Premium plan can host multiple function apps. If you have eight small apps all needing VNet and zero cold start, a shared EP1 can be cheaper than eight separate configurations.
- Contractual predictability — a known fixed cost can be preferable to a variable one even if the average is higher. It’s a valid business decision, not a technical one.
And the Dedicated case
If you already have an App Service Plan running 24/7 for a web API and it’s at 15% CPU, your background functions can run there without any additional cost. The capacity is already paid for. It’s the only situation where Dedicated is obviously correct — and it’s surprisingly frequent.
Three mistakes that make Functions bills expensive
1. Oversized memory “just to be safe”
Memory goes directly into the formula, linearly. A function configured at 1 GB but actually using 300 MB pays three times more than necessary for each execution, infinitely. It’s the cheapest optimization possible: look at metrics and adjust.
2. Duration that is actually waiting
This is the most costly coding mistake in serverless. If your function makes a synchronous HTTP call and blocks the thread for three seconds, you pay three seconds of GB-seconds to wait for a server that isn’t yours.
// Expensive: blocks the instance while I/O lasts
var response = httpClient.GetAsync(url).Result;
// Correct: frees the thread
var response = await httpClient.GetAsync(url);On Consumption, async/await is no longer just a scalability matter — it’s a direct line on the bill.
3. Triggers that don’t do batching
A function triggered by a queue that processes messages one by one pays the fixed cost per execution N times. The same function configured to receive batches pays once. For high-volume triggers, batchSize in host.json is one of the most efficient parameters in all of Azure:
{
"version": "2.0",
"extensions": {
"queues": {
"batchSize": 32,
"newBatchThreshold": 16
}
}
}Decision tree
Compressed to essentials, for a new project in 2026:
- Do you already have an underutilized App Service Plan? Run functions there. Marginal cost zero.
- Do you need VNet, private endpoints, or executions over 10 minutes? Flex Consumption. No need for Premium anymore for that.
- Does the latency of the first request matter to the user? Flex Consumption with one or two always-ready instances.
- Spiky traffic, background, webhooks, jobs? Flex Consumption with zero always-ready instances. Practically free under the monthly free tier.
- Special memory requirements, slots, or consolidation across many apps? Only here Premium.
Notice that “I have high traffic” does not appear anywhere as a reason for Premium. It’s not an omission.
Conclusion
The decision between Azure Functions plans is rarely about volume and almost always about three things: network requirements, tolerance for first-request latency, and the memory × duration profile of your code.
Before comparing plans, measure the third element. A function running in 200 ms with 256 MB has a completely different economic model than one running in 3 seconds with 1 GB — and, in most cases, code optimization brings more benefit than changing the plan.
In the next article, we move to containers: how scale-to-zero works in Azure Container Apps, why minReplicas is the most expensive parameter with a default value in Azure, and how to configure autoscale rules in App Service without paying for peaks that never come.
Note: the above figures are indicative, for the East US region, at the time of writing. Prices vary by region and are updated — always check in the Azure Pricing Calculator for your specific scenario.
