TL
The short answer

Azure Functions cost is driven first by the hosting plan and second by the code: on the Consumption plan you pay per execution plus GB seconds with no idle cost, which is cheapest for spiky low volume work, while steady high volume or latency sensitive functions are often cheaper on a Premium plan where pre warmed instances remove cold starts and per execution premiums at scale. Within whichever plan, the bill falls when you right size memory, cut execution time, and stop functions waiting synchronously on slow downstream calls, because GB seconds are memory multiplied by duration. The largest single lever is usually matching each function's plan to its traffic shape, not micro optimizing code on the wrong plan.

Here is how each plan bills, when to switch, and the code level levers that compound the saving.

How do the Azure Functions plans bill?

The Consumption plan charges per execution and per GB second, the memory a function uses multiplied by how long it runs, with a monthly free grant, and it scales to zero so idle functions cost nothing. Its trade off is cold starts, the latency when a new instance spins up after idle. The Premium plan keeps a set of pre warmed instances always ready, billed per second whether busy or not, removing cold starts and adding virtual network integration and longer run durations. Dedicated, on an App Service plan, runs functions on infrastructure you already pay for, useful when you have spare capacity. The newer Flex Consumption blends elastic scale with always ready instances. The point is that two functions with identical code can cost very differently depending on which plan hosts them.

Which plan fits which function?

PlanBills forBest for
ConsumptionPer execution plus GB seconds, scales to zeroSpiky, low or moderate volume, cold start tolerant
PremiumPre warmed instances per second, plus usageSteady high volume, latency sensitive, needs networking
Dedicated (App Service)The App Service plan you already runReusing spare capacity on an existing plan
Flex ConsumptionElastic plus optional always ready instancesBursty traffic that still needs warm starts

Plan capabilities and pricing evolve; verify against current Azure Functions pricing before switching. The guidance here is indicative.

What code level levers compound the saving?

Once the plan fits, attack GB seconds. Right size memory so a function is not over allocated, and cut execution time, the larger lever, by trimming dependencies and cold start weight, reusing database and HTTP connections across invocations, and caching values that do not change per call. Never hold a function open waiting synchronously on a slow downstream service, since you pay for that idle wait time; use durable or asynchronous patterns instead. Tame noisy triggers by batching and debouncing, so a flood of events does not become a flood of billable executions. And move long running or constantly busy work off per execution pricing entirely, because beyond a certain sustained volume a Premium plan or a container is simply cheaper than paying per invocation.

A worked example

Worked example

A scaling fintech ran a high volume event processing function on the Consumption plan, where it had quietly become a large line as traffic grew, with per execution charges mounting and cold starts hurting latency. Because the function now ran near continuously, we moved it to a Premium plan with a small set of pre warmed instances, which removed the per execution premium at that volume and fixed the latency, while genuinely spiky functions stayed on Consumption. We also batched a noisy trigger and reused connections to cut execution time. The combined effect lowered both cost and latency on the busiest function, part of the program that left the company 41 percent lighter on cloud spend. Figures are verified against billing data and anonymised.

Frequently asked questions

How is Azure Functions priced?
On the Consumption plan, Azure Functions bills per execution plus GB seconds, the memory used multiplied by execution time, with a monthly free grant. The Premium plan bills for pre warmed instances by the second to remove cold starts and add networking, and the Dedicated and Flex Consumption options change the trade between idle cost and scale. The plan choice, not just the code, drives the bill.
Which Azure Functions plan is cheapest?
Consumption is cheapest for spiky or low volume workloads because you pay only per execution with no idle cost, but cold starts apply. Premium is cheaper in effect for steady high volume or latency sensitive functions because pre warmed instances avoid cold start penalties and per execution premiums at scale. The cheapest plan depends on volume and latency needs, so match the plan to the traffic shape.
How do you cut Azure Functions cost?
Right size memory and cut execution time, since both drive GB seconds, move steady high volume functions off Consumption to a Premium or Dedicated plan, batch and debounce noisy triggers, and avoid long running synchronous waits inside a function. Choosing the right hosting plan for each function's traffic shape is usually the largest single lever.

Put each function on the right plan

We match Azure Functions workloads to the right hosting plan and tune the code that drives GB seconds, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the Azure MACC guide, read the deeper Azure cost optimization guide, and pair it with VM rightsizing that engineers accept.

Independent · buyer-side

Put a defensible number on your cloud spend.

No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.

Buyer-side intelligence, monthly.

The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.