Azure Functions Flex Consumption Plan

The Flex Consumption Plan is a hosting option for Azure Functions that was announced at Microsoft Build 2024 and is currently in preview. It is designed to address the limitations of the existing Consumption and Premium plans by offering a serverless model with more control over scaling and deployment. Unlike the Consumption Plan, which runs on a single shared instance for all functions in a function app, Flex Consumption allows each function to run on its own instance, enabling independent scaling. This means that a function app with multiple functions can have each function scale out based on its own load, rather than scaling the entire app together.

The traditional Consumption Plan has a major drawback: all functions in the same function app share the same instance. If one function is CPU-intensive, it can starve other functions. Also, the Consumption Plan has a maximum execution timeout of 10 minutes (for HTTP triggers) and 5 minutes for all other triggers (default 5, configurable up to 10). The Premium Plan solves these issues but requires always-on instances and incurs a base cost even when idle. Flex Consumption eliminates the shared instance problem and the idle cost while maintaining serverless scaling. It also supports virtual network integration (outbound only) and can use larger instance sizes (e.g., 4 GB memory instead of 1.5 GB in Consumption).

Flex Consumption uses a new runtime sandbox architecture. When a function is triggered, the Functions host allocates a dedicated instance for that function invocation. The instance is a lightweight container that runs only that function's code. The instance is created on-demand and destroyed after the function completes. Each instance has its own memory and CPU allocation, configurable per function app (not per function) from 512 MB to 4 GB. The default memory size is 2 GB.

Scaling is managed by the Azure Functions scale controller, which is similar to the Consumption Plan but with per-function scaling. The scale controller monitors trigger events and decides how many instances to create for each function. The number of instances is limited by the total instance count per function app, which defaults to 100 but can be increased up to 1000 by requesting a quota increase. The scale controller uses a target-based scaling model: it tries to maintain a target number of outstanding events per instance. For example, for a queue-triggered function, the target might be 10 messages per instance. If the queue grows, new instances are added.

To create a function app in the Flex Consumption plan using Azure CLI:

az functionapp create --name <app-name> --resource-group <rg> --storage-account <storage> --runtime <runtime> --runtime-version <version> --functions-version 4 --flex-consumption-plan <plan-name>

The --flex-consumption-plan parameter specifies the Flex Consumption plan. If the plan does not exist, it is created automatically with default settings.

To configure memory size:

az functionapp config appsettings set --name <app-name> --resource-group <rg> --settings FUNCTIONS_FLEX_MEMORY_SIZE=2048

To set always-ready instances for a function:

az functionapp function config set --name <app-name> --resource-group <rg> --function-name <function-name> --function-app-scale-limit 5

To verify scaling behavior, use Application Insights to monitor live metrics such as FunctionExecutionCount, FunctionExecutionUnits, and ScaleControllerScaleUpCount.

Flex Consumption integrates with Azure Storage for triggers (blob, queue), Event Hubs, Service Bus, and Cosmos DB. It does not support Durable Functions (because Durable Functions require a fixed instance affinity). It also does not support Linux containers (only Windows containers or code). The plan is available in select regions only; currently, it is rolling out to West Europe, East US, and Southeast Asia.

When a trigger fires, the scale controller evaluates the load per function. If the current number of instances for that function is insufficient to handle the backlog, it provisions a new instance. The instance is a container running the function host with only that function loaded. The instance is allocated from a shared pool of resources (the Flex Consumption plan's underlying infrastructure). The instance's lifetime is tied to the function execution; after the function returns (or times out), the instance is deallocated. The plan charges based on the memory size and execution time (in GB-seconds). The pricing is similar to Consumption but with a per-instance granularity. The cost per GB-second is the same as Consumption, but because each function has its own instance, the total cost may be higher if multiple functions are idle (since each idle instance incurs no cost, but the overhead of instance creation may increase execution time).

A large e-commerce platform processes orders from multiple sources: web, mobile, and third-party APIs. They use Azure Functions to validate orders, check inventory, and send confirmation emails. Previously, they used the Consumption Plan, but during flash sales, the single-instance bottleneck caused timeouts and order loss. They migrated to Flex Consumption. Each function (ValidateOrder, CheckInventory, SendEmail) now scales independently. The ValidateOrder function has a high request rate but short execution time, so it scales out quickly. CheckInventory has a longer execution time but lower rate. With Flex Consumption, they set a memory size of 1 GB for ValidateOrder and 2 GB for CheckInventory (via separate function apps, since memory is per app). They configured always-ready instances for ValidateOrder to 10 to handle sudden spikes. The result: zero order loss during peak sales, and cost savings compared to Premium Plan because they only pay for execution time. Misconfiguration: initially, they set the same memory size for all functions, causing over-provisioning for simple validations. They corrected by splitting functions into separate apps.

A manufacturing company collects sensor data from thousands of IoT devices. Each device sends a message to an Event Hub every minute. An Azure Function processes each message, transforms it, and stores it in Cosmos DB. The processing is lightweight but must handle bursts when devices reconnect after a power outage. They chose Flex Consumption because of its per-function scaling and lower cost than Premium. They set the memory size to 512 MB (minimum) to reduce cost. They noticed that during reconnection bursts, the scale controller took about 30 seconds to spin up new instances, causing a backlog. They mitigated by setting always-ready instances to 5 for that function. They also enabled outbound VNet integration to connect to a private Cosmos DB endpoint. The key learning: Flex Consumption cold start can be managed with always-ready instances, but the cost of keeping instances warm must be weighed against latency requirements.

A SaaS company runs a set of microservices as Azure Functions. One service is a REST API (HTTP trigger) with unpredictable traffic, another is a background processor (Service Bus trigger) that runs continuously with a steady load. In the Consumption Plan, the background processor would cause the entire app to stay warm, increasing cost. With Flex Consumption, they separated the HTTP and Service Bus functions into different function apps within the same Flex Consumption plan. The HTTP function scales rapidly on demand, while the Service Bus function maintains a steady number of instances. They configured the HTTP function with a higher memory size (2 GB) for complex JSON parsing, and the Service Bus function with 512 MB. They also set a maximum instance count of 50 for the HTTP function to prevent runaway scaling. This architecture reduced costs by 40% compared to Premium Plan.