Azure Functions pricing has three hosting plans — Consumption, Premium (Elastic Premium), and Dedicated (App Service Plan) — each with a different cost curve and a different operational profile. Consumption is metered per-execution and per-GB-second of memory used; Premium is per-hour like an App Service plan plus per-execution overage; Dedicated reuses your existing App Service Plan tier. The cost-decision boils down to call volume and cold-start tolerance: low or bursty volume = Consumption, predictable high volume with VNet integration or warm instances required = Premium, already paying for under-used App Service Plans = Dedicated. The four decisions that govern azure functions pricing: pick the right plan per function app, batch low-frequency triggers to amortise execution count, use Premium pre-warmed instance counts only as needed, and consolidate multiple function apps onto a single Premium plan.
The three hosting plans
Azure Functions pricing is one of the few Azure surfaces where the same code can land at three radically different cost points depending on plan choice.
| Plan | Pricing model | Cold start | VNet integration |
|---|---|---|---|
| Consumption | Per-execution + per-GB-s; 1M free/mo | Yes | No |
| Premium (EP1/EP2/EP3) | Per-hour like App Service + execution overage | No (always warm) | Yes |
| Dedicated (App Service Plan) | Shared plan rate; no separate function billing | No | Yes (if VNet-integrated plan) |
The per-execution model is generous on Consumption: 1M executions free per month, then $0.20 per million executions plus $0.000016 per GB-second of memory. For low-volume event-driven workloads (queue triggers firing dozens of times per minute), Consumption is essentially free. For high-volume workloads (HTTP triggers serving steady 100+ req/sec), Consumption compounds into thousands per month and Premium becomes cheaper above ~50–100 executions per second.
Consumption plan — when it's the right answer
Consumption fits four patterns dominantly:
- Event-driven low-volume: queue / topic / event grid triggers firing under 100K executions/month.
- Bursty workloads: scheduled batch processing where the function runs for minutes then sleeps for hours.
- Internal admin functions: timer-triggered cleanup, log rotation, user provisioning.
- Dev/test environments: any non-production environment where cold-start latency is acceptable.
Consumption breaks down at three thresholds: when execution count exceeds ~2M/month consistently (Premium is then cheaper); when cold-start latency is user-visible (a public HTTP endpoint where the first request takes 2–4 seconds is unacceptable); and when VNet integration is required (Consumption does not support it).
Premium plan — when it's the right answer
Premium (Elastic Premium) is the answer for production functions that need:
- No cold start: pre-warmed instances always available, eliminates first-request latency.
- VNet integration: private endpoint access to back-end services (SQL, Cosmos DB, Storage with Private Link).
- Predictable cost: per-hour rate is fixed, easier to budget than per-execution.
- Longer execution duration: 60-minute max (vs Consumption's 10 minutes).
- Larger instance sizes: EP1/EP2/EP3 give more memory and cores per instance.
The cost trap on Premium: minimum 1 pre-warmed instance always-on at ~$170/month (EP1). If you spin up 12 Function Apps each on its own Premium plan, that's $2,040/month minimum before any function ever runs.
Microsoft positions Premium as "the production tier" in architecture sessions. For most event-driven enterprise workloads, Consumption is the correct production tier; Premium is justified only when the cold-start, VNet, or duration constraints actually bite. The Azure portal does not surface comparative cost; it lets you pick Premium and bill you. Always model both before committing.
Consolidating function apps onto fewer Premium plans
Like App Service, multiple Function Apps can share a single Premium plan. Consolidation pattern: group function apps by workload type and lifetime onto shared plans. We routinely find tenants with 30+ Premium plans each running 1–2 function apps at <25% utilisation. Consolidation typically reduces Premium plan count 60–70% and total Functions spend 40–55%.
Reserved Instances on Premium
Premium plan Reserved Instances exist and follow the App Service RI model: 1-year ~37% off, 3-year ~55% off. Available on EP1/EP2/EP3. For any steady-state production Premium footprint, the RI capture is the largest single saving. Combine plan consolidation first (so you reserve fewer larger plans), then apply RIs.
Dedicated plan — when it's the right answer
Dedicated (App Service Plan) hosts Functions on an existing App Service Plan. Cost is zero incremental if the plan is already paid for and has spare capacity. The pattern: enterprises with under-used App Service Plans (which we encourage you to consolidate per the App Service guide) can stack Functions onto those plans at no marginal cost. This is the single cheapest Functions hosting model when the conditions align.
Anonymised case study: $190K Functions reduction
A logistics client ran 47 Function Apps, all on Premium EP1 plans, each at <15% utilisation. Annual Functions spend: $310K. The audit: 22 of the function apps were low-volume internal admin tasks that could run on Consumption with no impact (cold-start of 1–3 seconds was acceptable); 18 were event-driven workloads needing VNet integration but with low call counts, suitable for consolidation onto 4 shared Premium plans; 7 were genuinely high-volume HTTP functions justifying their own Premium plans. Remediation: 22 to Consumption (~$2,000/year run rate); 18 consolidated onto 4 Premium plans; 7 kept on Premium with 3-year RIs. Annual saving: $190K, no behaviour change.
The Microsoft Licensing Briefing — 3 minutes, every Friday
Independent analysis of Microsoft commercial moves, with implications for your EA and Azure commit. No vendor spin.
No spam. Unsubscribe any time.
Where to take this from here
Functions sits inside the broader Azure compute optimisation picture. Sequence: plan-by-app review first, Consumption migration where viable, Premium plan consolidation third, Reserved Instance capture fourth, Dedicated plan stacking onto under-used App Service Plans fifth. Pair the work with the App Service licensing guide for the Dedicated-plan stacking opportunity, the Savings Plans vs Reserved Instances guide for broader commitment strategy, and the governance baseline for the policy enforcement that prevents Premium-by-default. For the complete picture, the Azure cost optimisation guide. For commitment design, the MACC explainer. For renewal leverage from disciplined Functions consumption, the EA tier collapse playbook. For end-to-end advisory, our Azure & MACC Advisory. Request a discovery call to benchmark.