Azure Functions hosting plans: Flex Consumption, Premium and cold start

The hosting plan decides scaling, instance resources, networking, container support and cost, and it can’t be changed in place for Flex Consumption.

The Consumption plan is legacy: new serverless apps should use Flex Consumption. Linux Consumption gets no new features or language versions and retires on 30 September 2028; apps still on the end-of-life v3 runtime on Linux Consumption stopped running after 30 September 2026.

Timeouts

functionTimeout is set in host.json in [d.]hh:mm:ss format (-1 means unbounded). The 230-second HTTP response limit applies on every plan.

Flex Consumption

• Instance memory of 512 MB (0.25 cores), 2,048 MB (1 core, the recommended default) or 4,096 MB (2 cores); changeable at any time.
• Per-function scaling: HTTP triggers scale together, Blob (Event Grid) triggers scale together, Durable Functions triggers scale together, and every other function scales on its own instances.
• Always ready instances (default 0) remove cold starts for chosen groups or functions and are billed as a baseline; they don’t count toward the maximum instance count but do count toward the regional quota.
• Regional subscription quota of 250 cores by default for all Flex apps (15 cores for Free Trial and Azure for Students).
• Virtual network integration, private endpoints and Azure Files (SMB) mounts are supported.
• One app per plan, Linux only, no containers, no deployment slots (zero-downtime rolling updates are in preview), and no in-place migration to or from other plans.
• Minimum billable execution is 1,000 ms, then rounded up to 100 ms.

az functionapp create --resource-group <RG> --name <APP> \
  --storage-account <STORAGE> --flexconsumption-location <REGION> \
  --runtime python --runtime-version 3.12 \
  --instance-memory 2048 --maximum-instance-count 100

Premium plan

• SKUs EP1 (1 core, 3.5 GB), EP2 (2 cores, 7 GB) and EP3 (4 cores, 14 GB). An SKU starting with P (such as P1V2) is a Dedicated plan and doesn’t scale elastically.
• At least one instance is always running and billed; there’s no per-execution charge.
• Always ready instances (up to 20 per app) run continuously; prewarmed instances (default 1) are a buffer that becomes active during HTTP scale-out.
• Several function apps can share one plan (same OS), and Linux custom containers are supported.

Dedicated and Container Apps

The Dedicated plan runs on App Service plan instances at App Service rates, suiting predictable billing, existing underused plans or very large compute; Always On must be enabled for unbounded timeouts and to keep non-HTTP triggers running. Container Apps hosting runs a containerised function app with the Functions programming model alongside other microservices, with GPU options; it uses revisions rather than slots (see Chapter 3, Azure Container Apps: environments, revisions and secrets).

Cold start

Consumption and Flex apps can scale to zero, so the first request after idle pays a start-up delay. Flex reduces this and adds always ready instances; Premium avoids it with always ready plus prewarmed instances; Dedicated runs continuously; Container Apps avoids it when minimum replicas is one or more.

Common trap: Choosing the Consumption plan for a new Linux or Python serverless app - Consumption is legacy and Linux Consumption is retiring; Flex Consumption is the recommended serverless plan and adds virtual network support and always ready instances.

Common trap: Creating a P1V2 plan to get Premium Functions features - SKUs starting with P are Dedicated App Service plans with no elastic scale; Elastic Premium plans use EP1-EP3.

Get the whole book

This note is one section of Ultra Transcenders AI-200: Developing AI Cloud Solutions on Azure, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.

About the book · AI-200 terms in the glossary · All AI-200 study notes