Azure Functions Premium Plan vs Consumption

Azure Functions offers three hosting plans: Consumption, Premium, and Dedicated (App Service). This chapter focuses on Consumption vs. Premium, as these are the serverless options. The Dedicated plan runs functions on reserved VMs (like a standard App Service) and is not serverless.

The Consumption plan is the default, truly serverless option. You are charged only for the time your code runs (per execution and per GB-second). Scaling is automatic – Azure adds function host instances based on the number of incoming events. The plan has a 5-minute timeout for all triggers except HTTP triggers, which have a 2.5-minute timeout by default (configurable up to 10 minutes for HTTP triggers via functionTimeout in host.json). The maximum execution duration for all functions is 10 minutes (configurable up to 10 minutes).

Key characteristics: - Scaling: Scale out from zero to many instances based on trigger events. For Azure Functions, scaling is controlled by the Scale Controller, which monitors trigger queue lengths, event hub partitions, etc. The maximum number of instances is 200 (default) but can be increased via support request. - Cold start: When a function app is idle for about 20 minutes, the instance is deallocated. The next request triggers a cold start – loading the function host and your code, which adds latency (typically 1-10 seconds). - No VNet integration: Functions in the Consumption plan cannot access resources inside a Virtual Network (VNet) unless you use the Regional VNet Integration feature (which is limited and doesn't allow access to on-premises resources via VPN or ExpressRoute). - No always-ready instances: All instances are spun up on demand. - Billing: Pay per execution ($0.20 per million executions) and per GB-second ($0.000016/GB-s). The first 1 million executions and 400,000 GB-s are free each month.

The Premium plan (also called Elastic Premium) provides enhanced performance and features while maintaining serverless billing (pay per execution and per GB-second, but with a base cost for always-ready instances). It is designed for applications that need: - No cold starts: With always-ready instances (configurable from 1 to 20), you can keep a minimum number of instances warm. - Unlimited execution duration: The default timeout is 30 minutes for HTTP triggers, and you can set functionTimeout to unlimited (0:00:00) in host.json for non-HTTP triggers, allowing functions to run up to the maximum of the plan (10 minutes for Consumption, unlimited for Premium). - VNet integration: Premium plan functions can connect to a VNet via VNet Integration (regional or gateway-required) and can access resources inside the VNet and on-premises via VPN/ExpressRoute. - More powerful instances: Premium plan uses more CPU and memory (minimum 1.75 GB RAM vs. 1 GB for Consumption). - Predictable scaling: You can set a maximum number of instances (default 100, up to 1000 with support).

Key characteristics: - Always-ready instances: You specify a minimum number of instances (cost is incurred even when idle). This eliminates cold starts for the first requests. - Scaling: The Scale Controller still scales automatically, but it can scale more aggressively because the plan has reserved capacity. Premium instances also have pre-warmed workers that are kept ready to handle bursts. - Billing: In addition to execution and GB-second costs (same rates as Consumption), you pay a base cost per always-ready instance (e.g., ~$0.00015/sec per instance). This base cost is incurred even if the function is idle. - Dedicated instances: Each function app runs on its own set of instances (no sharing with other apps in the same plan unless you deploy multiple apps to the same plan).

Scale Controller: A background process that monitors trigger events and decides how many instances are needed. For both plans, the Scale Controller uses a threshold-based algorithm:

The Scale Controller also considers instance health and load balancing. In Premium, the Scale Controller can scale faster because it has pre-warmed workers available.

Instance warm-up: When a Premium plan function app is created, the Scale Controller immediately provisions the configured number of always-ready instances. These instances load the function host and your code, so they are ready to serve requests instantly. In Consumption, instances are provisioned only when events arrive.

Timeout configuration: In both plans, the functionTimeout property in host.json controls the maximum duration for function executions. For Consumption, the maximum is 00:10:00 (10 minutes). For Premium, you can set it to 00:00:00 for unlimited (but the actual maximum is bounded by the runtime, which is essentially unlimited; however, the function must complete within the lifetime of the instance – instances are recycled periodically).

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

az functionapp create --resource-group myRG --consumption-plan-location westus --name myFuncApp --storage-account mystorage --functions-version 4 --plan-type Premium --sku EP1

To check the current plan type:

az functionapp list --query "[?name=='myFuncApp'].{plan:appServicePlanId}" --output tsv

To set the always-ready instance count:

az functionapp update --resource-group myRG --name myFuncApp --set siteConfig.alwaysReadyInstances=2

To view the current timeout setting in host.json:

{
  "version": "2.0",
  "functionTimeout": "00:30:00"
}

A financial company needs to process sensitive data from an on-premises SQL Server. They use Azure Functions to trigger ETL jobs when new blobs appear in a storage account. The function must access the SQL Server via a VPN-connected VNet. The Consumption plan cannot meet this requirement because it lacks VNet integration. The Premium plan is chosen, with always-ready instances set to 2 to avoid cold starts during business hours. The function timeout is set to unlimited because some ETL jobs may run longer than 10 minutes. In production, they configure Regional VNet Integration and route all outbound traffic through the VNet. A common misconfiguration is using gateway-required VNet Integration, which is not supported for Premium; instead, Regional VNet Integration is used. They also set a maximum burst of 50 instances to control costs. When misconfigured (e.g., no VNet integration), the function fails to connect to SQL Server, causing timeouts and retries.

An e-commerce platform exposes an HTTP-triggered function behind Azure API Management to handle product search. The function must respond in under 100ms. In the Consumption plan, cold starts cause occasional delays of 2-5 seconds, which degrades user experience. They switch to Premium plan with 3 always-ready instances, ensuring sub-100ms response times. The function timeout is set to 30 seconds (default). They also enable Application Insights to monitor performance. Scaling is automatic based on request rate; they set maximum burst to 200 instances. A common mistake is setting always-ready instances too high, incurring unnecessary cost. They monitor the minimum required instances during peak hours and adjust accordingly.

A logistics company uses Durable Functions to orchestrate a multi-step process that includes human approval with a 24-hour timeout. The Consumption plan's 10-minute execution limit forces the orchestration to fail. They migrate to Premium plan with unlimited timeout. The function app is configured with 1 always-ready instance to keep the orchestrator warm. They also use VNet integration to access an on-premises database. In production, they set the maxConcurrentActivityFunctions to 10 to limit parallelism. A common pitfall is forgetting to set functionTimeout to unlimited, causing functions to time out after 30 minutes (Premium default).