Azure Functions and App Service pricing

Azure Functions pricing depends on the hosting plan: the Consumption and Flex Consumption plans bill executions and gigabyte-seconds of active instances, the Premium plan bills vCPU-hours and GiB-hours of allocated instances, and a Dedicated plan is an App Service plan that bills per instance and hour whether functions run in it or not. On most teams' bills it is not the executions that dominate but the instances that keep running without load: always-ready instances, the minimum instance of a Premium plan, and App Service plans left with one small app inside.

Pricing dimensions

Microsoft calls the Consumption plan a legacy plan: for new serverless apps it recommends Flex Consumption, Linux apps on the Consumption plan are already retired, and Linux hosting on that plan ends on 2028-09-30. Flex Consumption bills the configured memory rather than the measured one: choose the 2,048 MB instance size and you pay 2 GB per second of active execution even if the code needs less; the platform's 272 MB buffer is not billed. In on-demand mode there is a monthly free grant of GB-seconds and executions; always-ready instances have none. Idle time between executions costs nothing in on-demand mode, because only active time counts.

The Premium plan has no execution charge. It bills the allocated instances by vCPU and memory in the sizes EP1 (1 vCPU, 3.5 GB), EP2 (2 vCPU, 7 GB) and EP3 (4 vCPU, 14 GB), for every instance as long as it is allocated: the plan's minimum instances follow the highest always-ready setting among its apps, and the prewarmed instance is billed as soon as it is provisioned. Several function apps share the instances of one Premium plan.

A Dedicated plan is an ordinary App Service plan. On Basic and above, Azure bills each VM instance of the plan, however many apps and slots run on it; on the Shared plan each app is billed for its CPU quota, and the Free plan costs nothing. Functions does not support Free and Shared, and a plan without Always On lets the Functions runtime go idle after a few minutes. The logic across providers is in serverless functions; Container Apps is the fifth hosting path for Functions, billed by the rules of Container Apps.

How it appears in your billing data

In the cost export Functions sits under MeterCategory Functions. MeterSubCategory names the plan: Functions for the Consumption plan with the meters Standard Execution Time per 1 GB Second and Standard Total Executions per 10; Flex Consumption with On Demand Execution Time, On Demand Total Executions, Always Ready Baseline, Always Ready Execution Time and Always Ready Total Executions; Premium Functions with Premium vCPU Duration per 1 Hour and Premium Memory Duration per 1 GiB Hour. The free grants appear as rows at price 0 with a filled Quantity; only the quantity above the grant carries a price. ConsumedService is Microsoft.Web, and ResourceId ends in sites/ and the function app's name; on the Premium and Dedicated plans the row points at serverfarms/ and the plan, not at the app.

A Dedicated plan sits under MeterCategory Azure App Service with a MeterSubCategory such as Azure App Service Premium v3 Plan - Linux and a MeterName such as P1 v3 App per 1 Hour; Windows plans carry no Linux in the name. Static Web Apps sit under the same category with MeterSubCategory Static Web Apps and the meters Standard App per 1/Month and Standard Bandwidth Usage per 1 GB, of which the first 100 GB stand at price 0. The function app's storage account and its telemetry in Application Insights sit under Storage and Log Analytics, not under Functions. The export's structure is in Azure cost exports.

In the FOCUS export all of these rows become ChargeCategory Usage with PricingCategory Standard, or Committed for reserved App Service plans; MeterName lands in SkuMeter, and Microsoft derives ServiceName from ConsumedService and the resource type, so function apps, web apps and App Service plans are told apart by resource type (FOCUS columns).

Levers

Configuration: on Flex Consumption the instance size sets the price per second and the concurrency per instance sets how many instances a load needs; an I/O-bound function with high concurrency needs one instance where a CPU-bound one with concurrency 1 needs ten. Always-ready instances pay off only where the cold start measurably hurts, because they create a baseline around the clock with no free grant. On the Premium plan the minimum instances and the size are the levers; on an App Service plan the tier, the instance count and whether the apps of several plans can share one (rightsizing). Autoscale rules and schedules for plans with no load at night are in scheduling and auto-scaling.

Purchase option: Premium v3 and Isolated v2 App Service plans can be reserved, and the savings plan for compute covers Functions Premium plans and App Service plans; Consumption and Flex Consumption have no commitment, so only instance size and run time lower their price (commitment strategy).

Architecture: serverless in on-demand mode is the cheapest shape for sporadic load, because idle costs nothing; steady load around the clock is cheaper on a Premium plan or a shared App Service plan, because the execution charge disappears. Durable Functions do not bill the waits in orchestrations, while long synchronous waits bill in full. Many small apps belong in one plan, not in many (architecture choices and cost).

Where it goes wrong

• The plan runs, the app does not. An App Service plan bills its instances even when every app in it is deleted or stopped. Look for serverfarms resources without running sites (idle and orphaned resources).
• Premium chosen instead of Flex. A plan with SKU P1v2 or P1v3 is a Dedicated plan without elastic scale, not a Functions Premium plan; those are EP1 to EP3. The rows sit under Azure App Service, not under Functions.
• Always ready without load. Always-ready instances on Flex Consumption create a baseline in GB-seconds around the clock with no free grant. Compare Always Ready Baseline with Always Ready Execution Time; a wide gap means the instances mostly wait.
• The Premium plan's minimum instance. Every Premium plan bills at least one instance even with no executions, and the always-ready setting of its largest app sets the minimum for the whole plan.
• The instance size does not fit the load. Flex Consumption bills the configured size, not the consumption; a 4,096 MB instance for a function that needs 300 MB costs twice the 2,048 MB size per second.
• The side costs sit elsewhere. Storage account, Application Insights and bandwidth are billed apart; on small apps the telemetry in Log Analytics often exceeds the execution cost.
• Linux Consumption apps on borrowed time. Apps on the Linux Consumption plan get no new language versions and must move to Flex Consumption by 2028-09-30; the move means a new function app, because in-place migration is not supported.

Example

List prices from the Azure Retail Prices API for Germany West Central, read on 2026-10-21. In EUR: the Premium plan costs EUR 0.1487 per vCPU-hour and EUR 0.0106 per GiB-hour, so an EP1 instance with 1 vCPU and 3.5 GB costs EUR 0.1858 per hour. An App Service plan on Linux costs EUR 0.0159 per hour for B1, EUR 0.0836 for S1, EUR 0.0783 for P0v3 and EUR 0.1566 for P1 v3; on Windows EUR 0.066 for B1 and EUR 0.2974 for P1 v3; the Shared plan EUR 0.0114 per app and hour, Free 0. Static Web Apps cost EUR 9.5037 per app and month on the Standard plan and EUR 0.2112 per GB of bandwidth above 100 GB. The API returns the execution time and execution meters in EUR to four decimals only, so they show as 0; the same query in USD gives, for Flex Consumption, USD 0.000037 per GB-second above 100,000 free GB-seconds and USD 0.40 per million executions above 250,000 free ones, for always ready USD 0.000005 per baseline GB-second and USD 0.000019 per active GB-second, and for the Consumption plan USD 0.000016 per GB-second above 400,000 free and USD 0.20 per million executions above one million free. The figures show that a small Linux App Service plan costs less per hour than a tenth of an EP1 instance, and that the always-ready baseline rate is a seventh of the on-demand price per GB-second but accrues every second.

Sources

Read on 2026-10-21. Prices: Azure Retail Prices API, Functions in Germany West Central in EUR, the same query in USD, App Service plans in EUR, Static Web Apps in EUR, P1 v3 with reservation and savings plan prices, Premium plan with savings plan prices, Azure Retail Prices API reference. Billing data: Cost details fields, Convert Cost Management data to FOCUS, Estimating consumption-based costs. Service: Azure Functions hosting options, Flex Consumption plan, Premium plan, Dedicated plan, App Service plans, Static Web Apps hosting plans.