Azure Functions

About Azure Functions

Azure Functions is Microsoft's event-driven serverless compute service in Azure. It runs application code in response to HTTP requests, timers, queues, events, storage changes and other triggers without requiring teams to manage the underlying server fleet. Azure Functions supports several hosting models, including Flex Consumption, Premium, Dedicated App Service plans, Azure Container Apps and the legacy Consumption plan. The best option depends on scaling behavior, networking, cold-start tolerance, execution duration, runtime support, container needs, concurrency and how predictable the workload is.

What is Azure Functions used for?

Azure Functions fits workloads that naturally respond to events or can be split into independent units of code. Common use cases include APIs, scheduled jobs, queue processing, file and blob processing, event handling, automation, background tasks, data transformation and integration workflows. Triggers and bindings connect functions to supported services so developers can react to events without writing all of the surrounding integration code themselves.

Functions is strongest when a workload can scale independently and does not need a continuously running application server. It can also be one part of a larger system, such as processing messages from a queue while a web front end runs on Azure App Service. Buyers should evaluate the execution pattern rather than move a monolithic application into functions unchanged.

Which Azure Functions hosting plan should you choose?

Microsoft currently recommends Flex Consumption for new serverless function apps. Flex Consumption is Linux-only, code-only hosting with fast event-driven scaling, virtual network integration, pay-as-you-go billing, configurable memory sizes and optional always-ready instances to reduce startup latency. Microsoft documents scale-out of up to 1,000 instances for supported Flex workloads.

Premium is aimed at workloads that need prewarmed workers, longer execution times, virtual network integration and more predictable performance. Dedicated hosting runs Functions on App Service plan capacity and can fit teams that already operate dedicated App Service resources. Azure Container Apps can host containerized function apps. The Consumption plan remains available for supported Windows scenarios, but Microsoft now describes Linux Consumption as a legacy path and recommends Flex Consumption for new Linux serverless apps.

How should buyers size Flex Consumption instances?

Microsoft currently defines three Flex Consumption instance memory sizes: 512 MB, 2,048 MB and 4,096 MB. The typical CPU allocation is 0.25 core, 1 core and 2 cores respectively. Microsoft recommends 2,048 MB as the default for most scenarios, while 512 MB and 4,096 MB should be selected when the application's concurrency, CPU or memory profile makes them a better fit.

Function code and the Functions host share the configured instance resources. Larger instances can handle more concurrent work or more CPU and memory intensive execution, while available CPU and network bandwidth also rise with the instance size. The instance memory setting can be changed later, so teams should load test realistic traffic rather than assuming the largest size is automatically the best value.

What scale and quota limits matter on Flex Consumption?

A headline maximum of 1,000 Flex Consumption instances does not mean every subscription can immediately use 1,000 instances at every memory size. Microsoft applies a regional subscription quota across all Flex Consumption apps in a region. The current default quota is 250 cores, equivalent to 512,000 MB across active Flex instances, and always-ready instances count against that quota.

At the default quota, 1,000 active 512 MB instances consume 250 cores, 250 active 2,048 MB instances consume 250 cores, and 125 active 4,096 MB instances consume 250 cores. Customers can request higher quota, subject to Microsoft capacity review. Apps scaled to zero do not count against the quota. Buyers planning bursty production workloads should therefore validate both per-app scale settings and regional subscription quota.

What lifecycle deadlines matter in 2026?

Several Azure Functions lifecycle dates matter for existing deployments. Microsoft states that Azure Functions runtime version 1.x reaches end of support on September 14, 2026. Runtime versions 2.x and 3.x are already retired, and Microsoft currently supports version 4.x of the Functions runtime host.

A separate risk applies to apps that still run the end-of-life v3 runtime on Linux in a Consumption plan. Microsoft says those apps stop running after September 30, 2026 unless they are migrated to runtime v4. Teams operating older function apps should identify runtime versions now rather than wait for a service interruption.

What is changing for Linux Consumption and .NET apps?

Microsoft is retiring Linux hosting in the legacy Consumption plan on September 30, 2028. Linux Consumption is not receiving new features or language versions, while Windows Consumption is not currently affected by that retirement. Microsoft recommends moving applicable Linux workloads to Flex Consumption before the retirement date.

For C# applications, support for the .NET in-process execution model ends on November 10, 2026. Microsoft's current migration guidance recommends the isolated worker model for continued full support. The isolated worker model currently supports .NET 10, .NET 9 and .NET 8 on Functions 4.x, while the in-process model is limited to .NET 8 and reaches its support deadline in November 2026.

Which languages are currently supported?

Azure Functions supports several language stacks, but support status varies by runtime, version and hosting plan. Microsoft currently documents C#, Java, JavaScript and TypeScript, PowerShell, Python and Go-related support. Buyers should not assume every language has the same maturity or plan availability.

Go support is currently preview rather than generally available and Microsoft documents it for Flex Consumption function apps. Language lifecycle dates can differ from the Functions host runtime, so teams should check the current supported-languages matrix before selecting or upgrading a production runtime.

How do scaling, timeouts and cold starts work?

Dynamic hosting plans can add or remove function instances in response to incoming events. Flex Consumption scales on a per-function basis and can scale to zero when no work is present, while optional always-ready instances keep capacity warm for workloads sensitive to startup delay. Premium uses prewarmed workers and is designed to reduce idle-start latency further.

Microsoft currently documents a default function timeout of 30 minutes for Flex Consumption and Premium, with no enforced maximum execution timeout in those plans, although platform scale-in and update grace periods still apply. The legacy Consumption plan has a five-minute default and a ten-minute maximum. Long-running HTTP work should use an asynchronous design rather than hold a request open.

How does Azure Functions pricing work?

Azure Functions does not have one fixed monthly price. On Flex Consumption, Microsoft bills on-demand execution based on provisioned memory, execution time and execution counts. Optional always-ready instances have baseline memory charges while idle plus execution charges when they run functions. Microsoft's current pricing page includes a monthly free grant for eligible pay-as-you-go Flex on-demand usage of 250,000 executions and 100,000 GB-s per subscription.

The legacy Consumption plan has a separate eligible monthly free grant of 1 million executions and 400,000 GB-s. Premium is billed for provisioned vCPU and memory capacity, while Dedicated follows App Service plan pricing. Storage accounts, networking, monitoring and related Azure services can add separate charges. Pricing was rechecked on September 4, 2026. Buyers should still use Microsoft's current regional pricing or calculator for their own architecture.

What migration limitation should Flex buyers know about?

Flex Consumption is Microsoft's preferred serverless plan for new function apps, but moving an existing app to it is not an in-place plan switch. Microsoft currently states that direct in-place migration from another hosting plan to Flex Consumption is not supported, and an app also cannot be migrated directly from Flex Consumption to another plan.

Microsoft provides migration guidance and assessment tooling for eligible Linux Consumption apps, but the target still requires a new Flex Consumption function app and redeployment. Teams should plan for identity, networking, application settings, storage, monitoring, deployment pipelines, bindings, DNS and cutover instead of treating the change as a billing-plan toggle.

What are the main limitations and operational tradeoffs?

Serverless does not mean zero operations. Teams still own application code, dependency security, identity, secrets, configuration, data handling, monitoring, retry behavior and downstream service reliability. Event-driven systems can also be harder to troubleshoot because one business process may span several functions, queues, databases and external services.

Execution limits, networking behavior, cold starts, regional availability, supported operating systems and deployment methods vary by hosting plan. Flex Consumption also has plan-specific restrictions, including no PowerShell managed dependencies, no support for the WEBSITE_TIME_ZONE or TZ app settings, and no Azure Functions proxies. Teams should validate application assumptions against current Microsoft documentation before migrating production workloads.

Who should choose something else?

Teams building a conventional long-running web application may find Azure App Service simpler because it provides a managed application host without requiring the workload to be divided into event-driven functions. Organizations that need Kubernetes scheduling, portable container orchestration, operators or cluster-level control should compare Azure Kubernetes Service. Workloads that need full operating-system access or specialized server software may fit Azure Virtual Machines better.

Azure Functions is strongest when the workload is event-driven, bursty, automation-heavy or naturally decomposed into independent execution units. Buyers should choose it because the execution model fits the application, not simply because serverless is attractive as a billing concept. The useful comparison is total development and operational complexity across Functions and the managed platform or infrastructure alternative.