Azure Functions Flex Consumption: Serverless Done Right

Why the Original Consumption Plan Hit Its Limits

Azure Functions on the original Consumption plan delivered on the serverless promise for simple workloads: deploy a function, pay only when it runs, and let the platform handle scaling. But production teams quickly discovered the boundaries. No virtual network integration meant sensitive workloads could not access private resources. Fixed instance sizes wasted memory on lightweight functions and starved memory-intensive ones. Cold starts added unpredictable latency that made the plan unsuitable for latency-sensitive APIs.

These limitations pushed many teams toward the Premium plan or dedicated App Service plans — effectively paying for always-on infrastructure and losing the economic benefit that made serverless attractive in the first place. Azure Functions Flex Consumption closes this gap by combining pay-per-execution billing with the enterprise features that production workloads require.

What Flex Consumption Changes

Flex Consumption is now the recommended serverless hosting plan for Azure Functions. It runs on Linux and introduces three capabilities that the original Consumption plan lacked:

• Virtual network integration. Function apps can run inside a VNet, connecting to private databases, storage accounts, and internal services without exposing them to the public internet. This is the single most requested feature that previously required the Premium plan.
• Configurable instance memory. Teams choose between 512 MB, 2,048 MB, or 4,096 MB instance sizes at app creation time. A lightweight HTTP trigger no longer shares the same memory profile as a function that processes large files or runs ML inference.
• Always-ready instances. An optional configuration that keeps a specified number of instances warm, eliminating cold starts for critical paths. Unlike the Premium plan's minimum instance count, always-ready instances in Flex Consumption are scoped to specific triggers and functions rather than the entire app.

The billing model preserves the serverless economics. On-demand instances scale based on configured per-instance concurrency and are billed only during execution. Always-ready instances are billed continuously but cost less than equivalent Premium plan minimums because they can be targeted to specific functions rather than the entire app.

Migration from Legacy Consumption

Microsoft has set a clear timeline: after September 30, 2028, Linux Consumption plan hosting will be retired. Teams currently running Linux Consumption apps should begin evaluating Flex Consumption now rather than treating migration as a deadline-driven scramble.

The migration is not a lift-and-shift. Flex Consumption uses a different deployment model, and some runtime behaviors differ from the original plan. Key considerations include:

1. Deployment artifact format. Flex Consumption expects a deployment package rather than the Kudu-based deployment that some teams use with Consumption. Verify your CI/CD pipeline produces a compatible artifact.
2. Concurrency configuration matters. Flex Consumption scales based on per-instance concurrency settings. If your functions are I/O-bound (HTTP calls, database queries), higher concurrency per instance reduces cost. If they are CPU-bound, lower concurrency avoids contention. Measure before configuring.
3. VNet planning. If you enable VNet integration, ensure your subnet has sufficient address space for the maximum scale your app might reach. Address exhaustion during a traffic spike is harder to debug than a cold start.
4. Test cold start behavior. Even with always-ready instances for critical functions, secondary functions will still experience cold starts. Profile your startup time and optimize function initialization to reduce the impact.

When to Choose Flex Consumption

Flex Consumption is the right choice for teams that need serverless economics with enterprise networking. If your functions access private resources, process variable workloads, or serve as API backends where occasional cold starts are acceptable, Flex Consumption delivers better cost efficiency than the Premium plan while providing the same network isolation.

Teams running CPU-intensive or GPU-accelerated workloads should still evaluate dedicated compute. Flex Consumption instance sizes cap at 4 GB, which is insufficient for large ML models or video processing. For those use cases, Azure Container Apps or dedicated App Service plans remain more appropriate.

The broader signal from Microsoft is clear: serverless on Azure is converging on Flex Consumption as the default hosting model. Teams that adopt it now build operational familiarity before the Consumption plan retirement creates urgency.

Sources

• Azure Functions Flex Consumption Plan Hosting — Microsoft Learn
• Azure Flex Consumption: The FinOps Game-Changer — FinOps Weekly
• Cracking the Code of Serverless Design Patterns — Visual Studio Magazine