Azure Functions hosting plans: Flex Consumption, Premium or Consumption, and leaving Linux Consumption by 2028

Azure Functions has five ways to host an app, and the one most tutorials still show, the Consumption plan, is now the legacy option. Microsoft's current advice is simple: new serverless apps go on Flex Consumption, and existing Consumption apps should move there. Behind that advice are dates and limits that matter: the Linux Consumption plan retires on 30 September 2028, .NET 10 won't run on it, and a Flex Consumption app can't be created by converting an old one. This guide compares the plans on the things that actually decide the choice, then walks through the migration.

The five plans compared

Flex Consumption has no Windows version and no containers; Premium and Dedicated have both; Container Apps is containers only.

The limits that decide it

Two notes that catch people out. First, however long the timeout, an HTTP-triggered function has 230 seconds to respond, because of Azure Load Balancer's idle timeout; longer work belongs in a queue or a Durable Functions orchestration. Second, Flex Consumption apps in one subscription and region share a compute quota of 250 cores (15 for Free Trial and Student subscriptions); a 2 GB instance is one core, so one app at 250 instances fills it. The Flex Consumption Quota tool under Diagnose and solve problems shows usage, and support can raise it.

Flex Consumption in more detail

• Per-function scaling. HTTP triggers scale together as a group, Event Grid blob triggers as another, Durable Functions as a third; every other trigger scales on its own instances. The maximum instance count applies per group.
• Always-ready instances are billed as a baseline whether busy or not, process requests first, and sit outside the on-demand maximum and the scale-out rate. Set them for the HTTP group when cold starts matter.
• Memory size defaults to 2,048 MB; 512 MB suits small, highly concurrent work and 4,096 MB heavy processing. You can change it at any time, and the default HTTP concurrency per instance follows it.
• Deployment is one path: a zip package in blob storage that the app loads at start. No deployment slots; rolling updates (preview) are the zero-downtime option, and there's a rollback procedure for a bad deployment.
• Constraints: one app per plan; app start-up times out at 30 seconds; the blob trigger must use the Event Grid source; Durable Functions supports only the Azure Storage and Durable Task Scheduler providers; no PowerShell managed dependencies; no WEBSITE_TIME_ZONE; only the .NET isolated worker model; SMB file shares only; not every region yet.

The dates

There's a quieter consequence already: .NET 10 can't run on Linux Consumption, so a Linux Consumption app that wants the current .NET has to move now rather than in 2028.

Migrate a Consumption app to Flex Consumption

There's no in-place conversion: Flex Consumption is a different kind of plan, so you create a new app and redeploy. For most apps the code doesn't change. You need Owner or Contributor on the resource group, and Azure CLI 2.77.0 or later for the automated route.

1. Assess. az functionapp flex-migration list sorts your Consumption apps into eligible and ineligible, with the reason: an unsupported region or language, or a blob trigger without an Event Grid source, which Flex Consumption doesn't support. Convert such triggers (source: EventGrid, an event subscription on the container) and redeploy before you continue. A Windows app also needs to be a Linux app from here on, and .NET apps must already be on the isolated worker model.
2. Create the new app. On Linux, az functionapp flex-migration start --source-name <old> --source-resource-group <rg> --name <new> --resource-group <rg> creates it and copies app settings, identities, storage mounts, CORS, custom domains and access restrictions; options skip any of those. On Windows there's no automated command: create a Linux Flex Consumption app and carry the settings over by hand, leaving out the settings Flex Consumption deprecates. GitHub Copilot's Azure skills can drive the Linux migration interactively.
3. Bring over what the command can't: TLS certificates (as site-scoped certificates), built-in authentication (Easy Auth) through az webapp auth update, and anything that relied on deployment slots.
4. Get the code. Redeploy from source control, with the pipeline pointed at the new app. If you only have the deployed package, Linux Consumption keeps it in the scm-releases container of the host storage account (or at your WEBSITE_RUN_FROM_PACKAGE URL), compressed as squashfs.
5. Plan the cut-over per trigger. The moment you deploy, the new app's triggers start processing. For queues, Service Bus and Event Hubs, decide how to avoid double processing or lost messages while both apps exist; Microsoft's migration article lists mitigations by trigger type.
6. Deploy, verify, and retire the old app once the new one has handled real traffic.

If you'd rather move once, consider going straight to the right plan: a Windows-only dependency means Premium or Dedicated, not Flex Consumption, and a containerised app may be happier on Container Apps.

Sources

• Azure Functions hosting options, Microsoft Learn (the comparison tables and limits)
• Azure Functions Flex Consumption plan hosting, Microsoft Learn
• Azure Functions Consumption plan hosting (legacy), Microsoft Learn (the retirement dates)
• Migrate Consumption plan apps to the Flex Consumption plan, Microsoft Learn
• Guide for running C# Azure Functions in the isolated worker model, Microsoft Learn (.NET 10 and Linux Consumption)