Most enterprise architecture teams made a decision about Azure Functions somewhere around 2020 and have not revisited it since. The Consumption plan was cheap and scaled to zero, but it could not join a virtual network and it cold started unpredictably, which ruled it out for anything on a synchronous request path or anything that needed to reach a private database. So the workloads went to Premium plans, App Service plans, or containers, all of which meant paying for capacity that sat idle most of the day. That was the correct call at the time. It is worth checking whether it is still the correct call, because the Flex Consumption plan removed both of the constraints that drove it.
Flex Consumption keeps scale to zero and execution based billing, then adds the two things the enterprise objection was built on. Virtual network integration is supported, so a function can sit behind private endpoints and reach internal data stores without traversing the public internet. Always ready instances let you pin a configurable number of hosts that stay running and take requests first, so the cold start question becomes a dial rather than a gamble. Maximum scale out also moved from 200 instances to 1,000, which matters more than it sounds for burst driven event processing.
The part that gets overlooked is per function scaling and per instance concurrency. Each function in the app scales on its own workload rather than dragging the whole app with it, and concurrency per instance is configurable rather than fixed. The default is tied to instance size, and a 512 MB instance defaults to a single concurrent HTTP request, which catches teams off guard when they see instance counts climb under modest load. Concurrency and instance size have become genuine capacity planning levers, not settings you accept and forget.
The economics are what make this worth a second look. A Premium plan sets a monthly floor whether the workload runs or not. Flex bills execution time plus whatever always ready instances you choose to keep, so two warm instances cost real money but usually far less than an always on plan sized for peak. Any workload parked on Premium purely to get network isolation is a candidate for review.
There are real constraints. Flex is Linux only, so Windows dependencies and older runtime versions stay where they are, and the resource definition introduces a new configuration section that replaces several legacy app settings, which means your Bicep or Terraform modules need reworking rather than a plan name swap. Microsoft has been clear that Flex is the recommended plan for new serverless work and that Consumption is the legacy path, so new capability lands here first.
The action is not migrating one function app. It is scheduling a review of the architectural rule that sent every event driven workload to dedicated compute, because the assumption underneath it expired. If your platform team has not audited that decision this year, that is the meeting worth booking.
